<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.45">
<TITLE>RE: osmtest/OpenSM: ServiceGID and busy status</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>> On Fri, 2005-09-09 at 13:29, Eitan Zahavi wrote:</FONT>
<BR><FONT SIZE=2>> > Hal Rosenstock wrote:</FONT>
<BR><FONT SIZE=2>> > > Hi,</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > A couple of things about osmtest (and one is related to OpenSM):</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > 1. It appears that osmt_service.c sets ServiceRecords with the subnet</FONT>
<BR><FONT SIZE=2>> > > prefix of the ServiceGID set to 0 ? Is that the correct thing to do</FONT>
<BR><FONT SIZE=2>> > > (from an osmtest perspective) ?</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > ServiceGID..............0x0000000000000000 : 0x0008f10403960559</FONT>
<BR><FONT SIZE=2>> > Well, I could not find where the spec require the validation of the provided GID</FONT>
<BR><FONT SIZE=2>> field for</FONT>
<BR><FONT SIZE=2>> > ServiceRecords. The fact we allow non valid or unknown GIDs to be registered</FONT>
<BR><FONT SIZE=2>> might become useful.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> I may be wrong but:</FONT>
<BR><FONT SIZE=2>> ServiceGID says port GID for service. A port GID must meet the</FONT>
<BR><FONT SIZE=2>> requirements in the addressing section.</FONT>
<BR><FONT SIZE=2>[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</FONT></P>
<P><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> > > More importantly, should the SM allow this (is this a valid GID) ?</FONT>
<BR><FONT SIZE=2>> > > Shouldn't it match one of the GIDs for that port that is setting the</FONT>
<BR><FONT SIZE=2>> > > ServiceRecord ?</FONT>
<BR><FONT SIZE=2>> > As I said - I did not see anywhere in the spec a specific requirement for that.</FONT>
<BR><FONT SIZE=2>> > Why do you see this as an issue?</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> See above.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> > > 2. In general in osmtest (and other SA client code using the vendor</FONT>
<BR><FONT SIZE=2>> > > layer), when a remote error is indicated (MAD status != success), this</FONT>
<BR><FONT SIZE=2>> > > is indicated as a remote error. It appears that the various</FONT>
<BR><FONT SIZE=2>> > > clients/applications (osmtest is one) is not dealing with BUSY which can</FONT>
<BR><FONT SIZE=2>> > > be returned by an SM.</FONT>
<BR><FONT SIZE=2>> > This is a big hole! Thanks for bringing it up. I think we should enhance the</FONT>
<BR><FONT SIZE=2>> > SA client code to recognize this and re-issue the MAD. Can this be done in the</FONT>
<BR><FONT SIZE=2>> > lowest possible layer?</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> For busy, it might be possible but is there one timeout retry strategy</FONT>
<BR><FONT SIZE=2>> or should this be left to the client ? For other errors, I think it</FONT>
<BR><FONT SIZE=2>> needs to be left to the client/application to determine whether it is in</FONT>
<BR><FONT SIZE=2>> error.</FONT>
</P>
<P><FONT SIZE=2>[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?</FONT></P>
<P><FONT SIZE=2>> -- Hal</FONT>
</P>
</BODY>
</HTML>