Closed EmilioPeJu closed 2 years ago
As background: we had this backend as a quick way to test our IPMI implementation. Performance optimization was not a requirement for us. If we have a backend that works the way you suggest, that could certainly be an improvement. I don't mind including a new interface (e.g. ipmitool-shell). So if it is important for you feel free to make a PR.
Thanks for the information, I didn't know it was focused on testing, I'll try other interfaces to see how that affects performance. I'm closing this as it is not so important. Though any performance improvement would be nice, currently my polling loop takes around 4 seconds to get all the sensor's values in a test mTCA crate.
what interface connection do you use? is it plain rmcp? than you could try the native rmcp implemenation in this lib
Yes, it is, I'll give it a try, thanks again
This is more a question than an issue. Currently, the ipmitool interface is based on executing ipmitool on every request, however, creating a new process is costly. The question is: is it worth changing it to run 'ipmitool shell' from start and send the request to that process (instead of creating a new processes every time)? The downside is that we might need to keep 4 processes running (one for each possible lun value), but that shouldn't be a problem.