Michael S. Tsirkin wrote: > Would keeping around MADs in the done list consume significant extra memory > resources?
For kernel clients, it shouldn't consume any additional memory. For userspace clients, it would continue to consume memory until a response were generated. Currently, that memory is freed once the userspace application retrieves the MAD from the kernel > What limits this memory? That's part of the discussion. Today, there is NO limit on how much memory a userspace application can consume. It will continue to consume memory as long as it doesn't call to receive a MAD. > Would a small client that would normally > just send RMPP, get a response and exit will be slowed down significantly > while > the agent learns? Clients that send requests are unaffected. Clients that use one of the pre-defined classes or known methods would also be unaffected. The learning only affects new methods, and would typically be limited to the receiving one MAD for each method. > Would a buggy application confuse the umad module, corrupting > the agent learns? Would a buggy application confuse the umad module, > corrupting > MAD processing for all other applications? A buggy application would only affect itself, plus whoever it was trying to communicate with. We can't really fix the latter though. > The original approach by Jack of detecting, and dropping, duplicate responses > instead of duplicate requests seemed much easier to me. The only disadvantage > it has that I'm aware of is a slight performance hit for duplicate processing > of > each request. But all the done_list scans proposed seem even more CPU > intensive. Jack's approach results in scanning a list, plus has the overhead of of duplicating the processing. The other problem is that DS RMPP requires maintaining state between receiving a request and the generation of a response. This approach provides a mechanism that can be used to maintain that state (i.e. the received request). By applying Jack's patch, I'll end up having to invent another way to store and retrieve the state. - Sean _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
