[openib-general] Some Missing Features from mthca/userMADaccess

[Sean Hefty]

Hal Rosenstock wrote:

>>>[SHAHAR] Attributes filtering can be done with O(1). First you don't
>>>have to support the entire theoretical range. Currently less then
>>>256 attributes are used per class.
>>
>>You can't make this assumption for vendor defined classes.
> 
> Are you referring to IDs or number of attributes used per vendor defined
> class ? 

Either really.

>>>But even more important then that, what is the use
>>>for methods filtering?
>>
>>It should allow creation of a trap handler, or other more modular code. 
>>  If there are no clients using method filtering, then I'm all for 
>>removing it.
> 
> CM (at least currently) appears to be registering this way. I think it
> is needed to support CM.
> 
> BTW, I don't think the response method should be set in the mask (line
> 336):
> set_bit(IB_MGMT_METHOD_GET_RESP, reg_req.method_mask);

Thanks, I changed the CM to only register for SENDs, which is all I 
care about at the moment.

>>> Do you see a way to handle the different SA client registrations
>>>for events (InformInfo) where an incoming Report could go to
>>>multiple clients with the current approach ?
>>
>>I think that more complex filtering should be done above the MAD layer.
> 
> Including inside the kernel ?

Just to be clear, I think complex filtering should be done in the 
kernel, but for user-mode clients.  This would avoid copying the MAD 
except when needed.  I would try to get kernel-mode clients to make use 
of the snooping functionality.

If a kernel client needs to actually own the MAD (e.g. to generate a 
response), then I would look at layering that filtering above the MAD 
layer.  Of course, I wouldn't make a blanket statement about where the 
filtering is done, but would want to examine it on a case by case basis.

>>I think a reasonable API would be to let user's specify a mask over the 
>>entire MAD (or at least the header).
> 
> Do you see this as the direction to provide this support if this is
> needed (for incoming traps and reports) ?

This approach seems the most flexible, so I would see if it would meet 
everyone's needs.  I'm hesitant to put this sort of filtering into the 
kernel MAD code, since the check would be more expensive than what's 
needed for most MADs.