[openib-general][PATCH 1 of 3] repost: Client Reregister support for kernel space

Leonid Arsh leonida at voltaire.com
Wed May 31 08:48:04 PDT 2006


Generating the LID_CHANGE event instead of CLIENT_REREGISTER is simply
not correct.

We need the event for our user mode applications.
Although the patch doesn't change current functionality, I wouldn't
like to write applications
based on the erroneous code. The application won't just work with
devices that generate the event correctly.

Although the event is optional, it's very helpful and, I think, it
will be supported by most of the devices/drivers soon. The fix does
not affect the ipath behaviour, anyway.

Thanks,
   Leonid
On 5/31/06, Roland Dreier <rdreier at cisco.com> wrote:
>  >  the most urgent and critical case is
>  >  the SM failure/restart when the SM is not connected to the host directly.
>  >  In this cases neither PortError no PortActive events will be
>  > generated on the host.
>  >  The SM will lose the multicast group configuration for the host and
>  > the host will need to rejoin its multicast groups in this case.
>  >  IPoIB shall handle the problem by catching the ClientReregister event.
>
> It seems your patch doesn't help in this situation at all.  Right now
> mthca will generate a LID_CHANGE event for any set of PortInfo; IPoIB
> will catch that event and rejoin all multicast groups.  Your patch
> changes some of those events to CLIENT_REREGISTER events and has IPoIB
> treat them exactly the same way as LID_CHANGE events.  So the behavior
> won't change at all.
>
>  >   There are additional cases. Any client which registers itself on the
>  > SA, will need to handle this event in order to work properly after the
>  > SM failure/restart. We'll need it very soon for a user mode
>  > application.
>
> OK, but you could use LID_CHANGE events the same way as IPoIB does
> now.  Since ClientReregister support is optional, and in fact you
> didn't fix ipath to generate these events, your app can't count on
> CLIENT_REREGISTER events being generated anyway.
>
> I'm not really opposed to these changes, but it is adding additional
> code for what looks like very minimal improvement.  So I'm trying to
> understand how this really helps you.
>
>  - R.
> _______________________________________________
> openib-general mailing list
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>
>



More information about the general mailing list