[openib-general] RE: osmtest/OpenSM: ServiceGID and busy status

[Eitan Zahavi]

> On Fri, 2005-09-09 at 13:29, Eitan Zahavi wrote:
> > Hal Rosenstock wrote:
> > > Hi,
> > >
> > > A couple of things about osmtest (and one is related to OpenSM):
> > >
> > > 1. It appears that osmt_service.c sets ServiceRecords with the subnet
> > > prefix of the ServiceGID set to 0 ? Is that the correct thing to do
> > > (from an osmtest perspective) ?
> > >
> > >
ServiceGID..............0x0000000000000000 : 0x0008f10403960559
> > Well, I could not find where the spec require the validation of the
provided GID
> field for
> > ServiceRecords. The fact we allow non valid or unknown GIDs to be
registered
> might become useful.
> 
> I may be wrong but:
> ServiceGID says port GID for service. A port GID must meet the
> requirements in the addressing section.
[EZ] I think the spec intentionally leaves this open. The intent is to use
this as GID but no check is defined. According to your interpretation no
"proxy" - where node A publish services of node B - is allowed
> 
> > > More importantly, should the SM allow this (is this a valid GID) ?
> > > Shouldn't it match one of the GIDs for that port that is setting the
> > > ServiceRecord ?
> > As I said - I did not see anywhere in the spec a specific requirement
for that.
> > Why do you see this as an issue?
> 
> See above.
> 
> > > 2. In general in osmtest (and other SA client code using the vendor
> > > layer), when a remote error is indicated (MAD status != success), this
> > > is indicated as a remote error. It appears that the various
> > > clients/applications (osmtest is one) is not dealing with BUSY which
can
> > > be returned by an SM.
> > This is a big hole! Thanks for bringing it up. I think we should enhance
the
> > SA client code to recognize this and re-issue the MAD. Can this be done
in the
> > lowest possible layer?
> 
> For busy, it might be possible but is there one timeout retry strategy
> or should this be left to the client ? For other errors, I think it
> needs to be left to the client/application to determine whether it is in
> error.

[EZ] Agree about the need to pass up the error codes. Just handle the BUSY
at a lower level which is probably common to most applications. But we might
at least make it an optional service of the low level?
> -- Hal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20050909/50fc99e7/attachment.html>