Re: [openib-general] [PATCH] IB/core: fix SM LID/LID change with client reregister set
Thanks, applied and queued for 2.6.18 ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] IB/core: fix SM LID/LID change with client reregister set
On Tue, 2006-08-15 at 11:06, Jack Morgenstein wrote: > On Tuesday 15 August 2006 17:42, Hal Rosenstock wrote: > > > > Are these two events equivalent ? e.g. does LID change require > > reregistration ? (That's a potential overhead as well). > > > > Before the change in mthca_mad.c (sm_snoop), the LID CHANGE event was > generated in all cases where a SET port-info MAD was received. > > After the change, either LID_CHANGE -- or -- CLIENT_REREGISTER is generated. > (i.e., CLIENT REREGISTER replaced LID_CHANGE in those cases where the > reregistration bit was set in the MAD). > > This patch simply restores the previous behavior of the sa_query and cache > modules in responding to events. Understood but doesn't it also has the effect of doing more than this for certain cases of Set PortInfo ? > No reregistration is required in these modules. Currently but I think it is a possibility in the future. -- Hal > > What about deregistration of the old registrations when this occurs ? > > Is that handled ? > > > There is no deregistration involvement. > > - Jack ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] IB/core: fix SM LID/LID change with client reregister set
Jack Morgenstein wrote: > Before the change in mthca_mad.c (sm_snoop), the LID CHANGE event was > generated in all cases where a SET port-info MAD was received. > > After the change, either LID_CHANGE -- or -- CLIENT_REREGISTER is generated. > (i.e., CLIENT REREGISTER replaced LID_CHANGE in those cases where the > reregistration bit was set in the MAD). > > This patch simply restores the previous behavior of the sa_query and cache > modules in responding to events. > > > I wish to emphases that without this fix opensm handover is NOT working now in OFED (and in kernel 2.6.18) and this is a must feature. Tziporet ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] IB/core: fix SM LID/LID change with client reregister set
On Tuesday 15 August 2006 17:42, Hal Rosenstock wrote: > > Are these two events equivalent ? e.g. does LID change require > reregistration ? (That's a potential overhead as well). > Before the change in mthca_mad.c (sm_snoop), the LID CHANGE event was generated in all cases where a SET port-info MAD was received. After the change, either LID_CHANGE -- or -- CLIENT_REREGISTER is generated. (i.e., CLIENT REREGISTER replaced LID_CHANGE in those cases where the reregistration bit was set in the MAD). This patch simply restores the previous behavior of the sa_query and cache modules in responding to events. No reregistration is required in these modules. > What about deregistration of the old registrations when this occurs ? > Is that handled ? > There is no deregistration involvement. - Jack ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] IB/core: fix SM LID/LID change with client reregister set
On Tue, 2006-08-15 at 10:20, Michael S. Tsirkin wrote:
> Hi, Roland!
> Please consider the following patch for 2.6.18 - this fixes a regression
> from 2.6.17 for us.
>
> After commit 12bbb2b7be7f5564952ebe0196623e97464b8ac5, when
> SM LID change or LID change MAD also has a client reregistration bit
> set, only CLIENT_REREGISTER event is generated.
>
> As a result, the sa_query module and the cache module don't update
> the port information, and ULPs (e.g. IPoIB) stop working.
> This is the regression we observe as compared to 2.6.17.
>
> Rather than generate multiple events (which would have negative performance
> impact), let us simply let cache and sa query respond to reregister event
> in the same way as to LID and SM change events.
Are these two events equivalent ? e.g. does LID change require
reregistration ? (That's a potential overhead as well).
What about deregistration of the old registrations when this occurs ?
Is that handled ?
-- Hal
> ---
>
> IB/core: fix SM LID/LID change with client reregister set
>
> If PortInfo set (e.g. LID change) MAD has the reregister bit set,
> IB_EVENT_LID_CHANGE event is no longer generated.
> So sa_query and cache must respond to IB_EVENT_CLIENT_REREGISTER event
> in the same way as to IB_EVENT_LID_CHANGE.
>
> Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
> Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
>
> Index: ofed_1_1/drivers/infiniband/core/cache.c
> ===
> --- ofed_1_1.orig/drivers/infiniband/core/cache.c 2006-08-03
> 14:30:20.0 +0300
> +++ ofed_1_1/drivers/infiniband/core/cache.c 2006-08-15 16:31:36.880294000
> +0300
> @@ -301,7 +301,8 @@ static void ib_cache_event(struct ib_eve
> event->event == IB_EVENT_PORT_ACTIVE ||
> event->event == IB_EVENT_LID_CHANGE ||
> event->event == IB_EVENT_PKEY_CHANGE ||
> - event->event == IB_EVENT_SM_CHANGE) {
> + event->event == IB_EVENT_SM_CHANGE ||
> + event->event == IB_EVENT_CLIENT_REREGISTER) {
> work = kmalloc(sizeof *work, GFP_ATOMIC);
> if (work) {
> INIT_WORK(&work->work, ib_cache_task, work);
> Index: ofed_1_1/drivers/infiniband/core/sa_query.c
> ===
> --- ofed_1_1.orig/drivers/infiniband/core/sa_query.c 2006-08-03
> 14:30:20.0 +0300
> +++ ofed_1_1/drivers/infiniband/core/sa_query.c 2006-08-15
> 16:32:35.100728000 +0300
> @@ -405,7 +405,8 @@ static void ib_sa_event(struct ib_event_
> event->event == IB_EVENT_PORT_ACTIVE ||
> event->event == IB_EVENT_LID_CHANGE ||
> event->event == IB_EVENT_PKEY_CHANGE ||
> - event->event == IB_EVENT_SM_CHANGE) {
> + event->event == IB_EVENT_SM_CHANGE ||
> + event->event == IB_EVENT_CLIENT_REREGISTER) {
> struct ib_sa_device *sa_dev;
> sa_dev = container_of(handler, typeof(*sa_dev), event_handler);
>
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
