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

[Hal Rosenstock]

On Thu, 2005-01-13 at 12:20, Sean Hefty wrote:
> shaharf 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 ? 

> > 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);

> >  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 ?

> The purpose of the snoop functionality is to let a client register to 
> view all MADs and then apply their own filter on which MADs they want 
> to make a copy of.  This is more flexible than any API that we could 
> define that tried to do the filtering in the MAD layer, and I believe 
> is sufficient for kernel-mode clients.
> 
> For user-mode clients, I would recommend that the snooping be done in 
> the kernel for performance reasons.  There would need to be a yet to be 
> defined API defined for user-mode clients to set the snooping parameters.
> 
> 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) ?

-- Hal