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

[shaharf]

Hi Sean,

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

In fact you may handle vendor classed using special un-optimized paths.
But I would just implement the attribute filtering using a hash table
mechanism and it will perform O(1) in the average case, O(n) in the
worst case which it very very unlikely in this case (assuming common
open hash implementation and dissent hash function and Hal, this is
memory and CPU analysis ;-)

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

Sorry, but I missed the bottom-line here, is there any specific need for
method filtering or not? It there isn't, I would "clean" it out.

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

I would not complicate the kernel code anymore, unless there is a known
specific issue that is important enough to justify it. Remember, this is
management code; the data throughput is not the first critical factor
here. Simplicity and clarity are far more important as I see it.
Broadcast management events and messages are not common in UNIX style
networking. TCP/UDP/IP ports are not shared in the common
implementations even though they might be copy-full within the kernel.
Shared handling of such events significantly complicates the kernel
mechanism. I think this is a clear case for usermode mechanism. Snooping
is an exception not the rule! I would not overlay the snooping mechanism
for additional tasks.

I know that this is not necessarily the IB way, but simple interfaces
and mechanism survive much longer than complicated ones. For example,
The socket interface is relatively simple and even if it is not flawless
it survived many years and many changes. I would follow that way.

Shahar