[openib-general] RFC: detecting duplicate MAD requests

[Sean Hefty]

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