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

[Hal Rosenstock]

On Wed, 2007-06-06 at 00:06, Sean Hefty wrote:
> >One could ask the IBTA for this if it is the right thing to do.
> 
> Checking with the IBTA makes sense.  Longer term, adding a distributed SA
> application class, or expanding the existing SA class may be useful, if the IBTA
> wants to define SA implementation at this level of detail.  However, I was
> trying to focus on what could be done now.  If the IBTA would like to
> standardize the communication, that'd be great.

> One issue that isn't clear to me is what exactly is meant by the statement:
> "Vendor-specific classes will never be used to define management operations that
> are encompassed by the Infiniband Architecture."

I'm not sure pf the intent of this but that is informative rather than
normative (compliance) text.

> For example, suppose that
> there were a small number of SA caches available in the subnet.  Is it compliant
> for a node to issue a PR query to one of the caches using a vendor-defined PR
> query?  Or must this be done using an SA PR query with possible redirection?

I think this example falls would fall "on the line" and seems somewhat
debatable as to whether there is a management operation for this or not.
It does go back to the intent of the original statement you cited.

> >Are you saying to make the RMPP header as the first part of Data ?
> 
> Yes.
> 
> >Vendor class 1 are not RMPP MADs so I think this is nonconformant.
> 
> I didn't see any restriction on the vendor class 1 data - at least in section
> 16.5.

True but I'm not sure that was the intent which again was why vendor
class 2 was created. Also, there is the problem of knowing that this
vendor class 1 is using RMPP. That sounds proprietary to me (and affects
the kernel in the OpenIB implementation).

>   If I'm mistaken on this, then I agree that vendor class 2 seems to be our
> only current option.
> 
> >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.
> 
> Yes - all vendor class 1 MADs suffer from this issue.  In practice, it seems
> that there can only be a single vendor for a given class on a subnet.

That's one way of putting it but limits the use; in fact, if this were
done, all subnets would use at least two different vendors. Another way
is that all vendors who want to use this class range need to coordinate
such use (e.g. class allocation).

> >The only choice seems to me to be reformatting using vendor class 2 and
> >dealing with the data copying.
> 
> >From an implementation viewpoint, this just seems less desirable.  Adding the
> offset means that single-segment SA MAD may become our multi-segment vendor MAD,
> and dealing with two MAD formats will be troublesome.  If we're only caching
> PRs, this may not be a big deal, but if we ever want to create a truly
> distributed SA, I think it will be.

Are you referring to the performance hit ?

-- Hal

> - Sean