[ofa-general] Re: [Query] ib add path record cache

Hal Rosenstock halr at voltaire.com
Tue Jun 5 14:37:51 PDT 2007


On Tue, 2007-06-05 at 15:39, Sean Hefty wrote:
> > You'd need to use a vendor class 2 if you wanted to use RMPP as the SA
> > does. However, there is some rearranging you would need to do if you
> > compare the relevant MAD formats.
> 
> Reading into the spec more, it seems our current choice is limited to 
> using a vendor class.  Application classes are controlled by the IBTA. 

One could ask the IBTA for this if it is the right thing to do.

> Of the two vendor classes, class 2 clearly defines that RMPP is used, 
> but also adds the OUI field to the MAD.  This throws off using the SA 
> MAD class format.  I see a few possibilities:
> 
> Use vendor class 1:
> There's no restriction on the MAD data.  This would allow us to match 
> the SA MAD class format exactly.  The drawback is that we need to modify 
> the MAD layer to identify the class as using RMPP.

Are you saying to make the RMPP header as the first part of Data ?

Vendor class 1 are not RMPP MADs so I think this is nonconformant.
That's one reason vendor class 2 was added. In addition, there is no way
to detect one "vendor" from another "vendor" (which is why OUI was
added) if the same class is used so these need to be unique across all
vendors.

> Use vendor class 2:
> Reading the spec, it looks like a reserved field in the MAD header is 
> reserved even if using a vendor defined class.  If this is the proper 
> interpretation,

It is.

> then we either need to shift the SA data down 4-8 bytes, 
> or we drop the first 4 bytes of the SM_Key.

I don't think the weakening the SM_Key is acceptable.

> If we ever want to do more than simple path record caching, I think 
> we'll want the full SM_Key.  Between the remaining choices, my 
> preference would be to adapt a class 1 for our purpose.  Anyone else 
> have thoughts on this?

The only choice seems to me to be reformatting using vendor class 2 and
dealing with the data copying.

-- Hal

> - Sean




More information about the general mailing list