[openib-general] Questions about SMI

Wed Oct 13 10:04:01 PDT 2004

On Wed, 2004-10-13 at 11:14, Roland Dreier wrote:
>     Hal> It seems like the thread ended with an unanswered
>     Hal> question. The answer appears to be that process_mad was
>     Hal> used. Is that what we want to do for OpenIB ?
> 
> That seems simplest to me but I'm not opposed to adding another driver
> entry point if that makes things simpler.

>     Hal> Is this to be done for all MADs, all SMPs, or only certain
>     Hal> ones ? If certain ones, is there a flag to indicate which
>     Hal> ones need to be fed to the driver ?
> 
> Again, all MADs seems simplest but I'm not opposed to another method.

A separate driver entry point (which would be NULL in other device
cases) seems slightly cleaner to me. How about:

int snoop_mad(struct ib_device *ibdev,
              u8 port_num,
              u16 slid,
              struct ib_mad *mad);

> We need to do more than just SMPs because Tavor also generates
> Baseboard Management traps that need to be forwarded.

Got it: it's any locally generated traps. Do they all show up on QP0 
regardless of the class of the trap ?

> If we want to limit which MADs to give to the low-level driver 
> we could add a flag to ib_driver.flags, like "IB_MAD_TRAP_FORWARDING" 
> or something.

This seems to be adding more device specific knowledge (although
somewhat abstracted) into the MAD layer receive handler so letting the
device driver see them all and decide which it wants is probably better.

>     Hal> Does that avoid the issue of more than 1 consumer for a
>     Hal> particular MAD ?  That was another "rule" that I thought we
>     Hal> achieved consensus on. It looks like the consumed flag takes
>     Hal> care of this.
> 
> Right, if you don't count the low-level driver seeing the MAD first.
> We can get by with one agent per MAD other than that.

I'm counting the low level driver :-) It depends on what the driver will
do with the MAD. There are "ownership" issues on the MAD.

>     Hal> Would there also need to be a send routine provided (by the
>     Hal> MAD layer) which does not require an agent registration ? If
>     Hal> so, is there a way to ensure that the driver is the only
>     Hal> component to use this routine ?
> 
> I don't see any reason why the driver needs a special send routine --
> it should work fine for the driver to create a couple of MAD agents
> for each port and use them to send MADs.  

Right. a MAD registration without a supplied ib_mad_reg_req structure
should work. You will need to pick up the latest ib_mad.c to have a shot
at this working. I will work on testing this useage in the meantime.

> If I'm wrong about this and we need a special send routine, I don't think 
> we have to do anything
> to prevent other code from using the routine beyond marking it "for
> low-level driver use only" in a comment -- this is the kernel so we
> can trust other code not to be malicious.
> 
> I'm not that concerned about the details of how we do this for now.
> We can always fix it up later, so I suggest you implement whatever
> seems easiest to you and I will fix up mthca to match.

OK. It shouldn't take long to code this up. Testing will take a little
longer. Is there any easy way to cause one of these traps to be
generated ?

Thanks.

-- Hal