[ofa-general] [PATCH 2/2] IB/IPoIB: Separate IB events to groups and handle each according to level of severity

[Olga Shern (Voltaire)]

On 5/19/08, Hal Rosenstock <hrosenstock at xsigo.com> wrote:
>
> On Sun, 2008-05-18 at 18:10 +0300, Moni Shoua wrote:
> > Hal Rosenstock wrote:
> > > On Sun, 2008-05-18 at 15:36 +0300, Moni Shoua wrote:
> > >> The purpose of this patch is to make the events that are related to SM
> change
> > >> (namely CLIENT_REREGISTER event and SM_CHANGE event) less disruptive.
> > >> When SM related events are handled, it is not necessary to flush
> unicast
> > >> info from device but only multicast info.
> > >
> > > How is unicast invalidation handled on these changes ? On a local LID
> > > change event, how does an end port know/determine what else (e.g. other
> > > LIDs, paths) the SM might have changed (that specifically might affect
> > > IPoIB since this is limited to IPoIB) ?
> > I'm not sure I understand the question but local LID change would be
> handled as before
> > with a LID_CHANGE event. For this type of event, there is not change in
> what IPoIB does to cope.
>
> It's SM change which I'm not sure about. I'm unaware of an IBA spec
> guarantee on preservation of paths on SM failover. Can you point me at
> this ?
>
> Also, as many routing protocols are dependent on where they are run in
> the subnet (location of SM node in the topology), I don't think all path
> parameters can be maintained when in a heterogeneous subnet and hence
> would need refreshing (or flushing to cause this) on an SM change event.
>
> So while it may work in a homogeneous subnet, I don't think this is the
> general case.


You are rigth there is no IBA spec request to preserve LIDs but all SMs that
we are familiar with,
are doing so.
You are refering to the case where there is remote LID change but not local
LID change,
but also without this patch this case is not taken care of.  We should think
about solution for this case in the future.


> > Also, wouldn't there be similar issues with other ULPs ?
> > There might be but the purpose of this one is to make things better  for
> IPoIB
>
> Understood; just trying to widen the scope. IMO other ULPs should at
> least be inspected for the same issues. The multicast issue is IPoIB
> specific but local LID, client reregister (maybe only events for other
> ULPs as multicast and service records may not apply (perhaps except DAPL
> but this may be old implementation)) and SM changes apply to all.
>
> -- Hal
>
> > > -- Hal
> > >
> > _______________________________________________
> > general mailing list
> > general at lists.openfabrics.org
> > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> >
> > To unsubscribe, please visit
> http://openib.org/mailman/listinfo/openib-general
>
> _______________________________________________
> general mailing list
> general at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>
> To unsubscribe, please visit
> http://openib.org/mailman/listinfo/openib-general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20080519/2aa669a1/attachment.html>