Sasha, On Thu, Oct 2, 2008 at 6:22 PM, Hal Rosenstock <[EMAIL PROTECTED]> wrote: > Sasha, > > On Thu, Oct 2, 2008 at 1:00 PM, Sasha Khapyorsky <[EMAIL PROTECTED]> wrote: >> Hi Hal, >> >> On 10:18 Thu 02 Oct , Hal Rosenstock wrote: >>> > >>> > 2. ibis doesn't register class 0x81 - SM direct routed, only SM lid >>> > routed (0x1). In comment in ibutils/ibis/src/ibsm.c line 118 is stated: >>> > >>> > /* no need to bind the Directed Route class as it will automatically >>> > be handled by the osm_vendor_bind if asked for LID route */ >>> > >>> > As far as I can see in osm_vendor_bind() it is not (but it is in >>> > opposite order - when class 0x81 is registered class 0x1 will be >>> > registered too). >>> >>> Yes that is what osm_vendor_ibumad.c:osm_vendor_bind does. >>> >>> So either ibdiagnet needs to register 0x81 r.t.1 or >>> osm_vendor_ibumad.c:osm_vendor_bind needs to be "symmetric" in terms >>> of registering the other SM class when only one is requested. This is >>> a minor change in the underlying semantics. [Popping up a level in >>> terms of this, (other than applications taking advantage of this >>> "feature",) I'm not sure why the vendor layer should assume that just >>> because one SM class is requested, the other should be too]. I just >>> looked and the latter appears to be consistent with the other vendor >>> layers. I think either solution will work. Your solution below also >>> looks like it would work but don't that should be done in a sim layer. >> >> I'm not like this "solution" too, but the fact that ibis works with real >> stack without registering 0x81 class is unclear for me. > > Me too. See below. > >>> > Somehow it works without ibsim - so I suspect user_mad handles it. >>> > >>> > (Hal, could you clarify?) >>> >>> The kernel (user_mad/mad) does not change the requested registrations >>> but I'm not sure I understand the question you are asking to be >>> clarified. Is that what you're asking ? >> >> ibis works somehow with real stack. It registers 0x1 class only and >> uses direct routing SMPs. Do you have any idea about why >> (osm_vendor_idumad and/or libibumad don't help)? > > libibumad umad_register does not do anything that would affect this > either. I can only conclude there must be something in ibutils that > fixes this if it does work with the real stack. It shouldn't be too > hard to track down where that registration for class 0x81 comes from.
Are you sure this is the only registration and not DR class too ? That's the first thing to confirm or maybe you've already confirmed this and it wasn't clear to me in what you wrote. If so, I have a theory about what could be occuring. It may be the case that it is an effect of the kernel MAD layer in that a MAD agent can send any class and when using request/response it matches on transaction ID which contains the MAD agent. Unsolicited messages on that other class wouldn't get through though. I just ran a simple test of this and that appears to be the case. -- Hal > > -- Hal > >> Sasha >> > _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
