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.
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
