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

[Devesh Sharma]

Hi all,
Sorry for late reply as I was not in the office.

Please anybody just tell me about the idea of _distributed SA_ in
short. Is it a pre-planed activity which is yet to be implemented with
the OFED? or its just an extension of the sa cache pre-loading
discussion?
And again distributed SA is going to solve what purpose?

On 06 Jun 2007 05:45:12 -0400, Hal Rosenstock <halr at voltaire.com> wrote:
> 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
>
>