<br><br>
<div><span class="gmail_quote">On 5/19/08, <b class="gmail_sendername">Hal Rosenstock</b> <<a href="mailto:hrosenstock@xsigo.com">hrosenstock@xsigo.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Sun, 2008-05-18 at 18:10 +0300, Moni Shoua wrote:<br>> Hal Rosenstock wrote:<br>> > On Sun, 2008-05-18 at 15:36 +0300, Moni Shoua wrote:<br>
> >> The purpose of this patch is to make the events that are related to SM change<br>> >> (namely CLIENT_REREGISTER event and SM_CHANGE event) less disruptive.<br>> >> When SM related events are handled, it is not necessary to flush unicast<br>
> >> info from device but only multicast info.<br>> ><br>> > How is unicast invalidation handled on these changes ? On a local LID<br>> > change event, how does an end port know/determine what else (e.g. other<br>
> > LIDs, paths) the SM might have changed (that specifically might affect<br>> > IPoIB since this is limited to IPoIB) ?<br>> I'm not sure I understand the question but local LID change would be handled as before<br>
> with a LID_CHANGE event. For this type of event, there is not change in what IPoIB does to cope.<br><br>It's SM change which I'm not sure about. I'm unaware of an IBA spec<br>guarantee on preservation of paths on SM failover. Can you point me at<br>
this ?<br><br>Also, as many routing protocols are dependent on where they are run in<br>the subnet (location of SM node in the topology), I don't think all path<br>parameters can be maintained when in a heterogeneous subnet and hence<br>
would need refreshing (or flushing to cause this) on an SM change event.<br><br>So while it may work in a homogeneous subnet, I don't think this is the<br>general case.</blockquote>
<div> </div>
<div>You are rigth there is no IBA spec request to preserve LIDs but all SMs that we are familiar with, </div>
<div>are doing so. </div>
<div>You are refering to the case where there is remote LID change but not local LID change,</div>
<div>but also without this patch this case is not taken care of.  We should think about solution for this case in the future.</div>
<div>   </div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> > Also, wouldn't there be similar issues with other ULPs ?<br>> There might be but the purpose of this one is to make things better  for IPoIB<br>
<br>Understood; just trying to widen the scope. IMO other ULPs should at<br>least be inspected for the same issues. The multicast issue is IPoIB<br>specific but local LID, client reregister (maybe only events for other<br>
ULPs as multicast and service records may not apply (perhaps except DAPL<br>but this may be old implementation)) and SM changes apply to all.<br><br>-- Hal<br><br>> > -- Hal<br>> ><br>> _______________________________________________<br>
> general mailing list<br>> <a href="mailto:general@lists.openfabrics.org">general@lists.openfabrics.org</a><br>> <a href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general">http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general</a><br>
><br>> To unsubscribe, please visit <a href="http://openib.org/mailman/listinfo/openib-general">http://openib.org/mailman/listinfo/openib-general</a><br><br>_______________________________________________<br>general mailing list<br>
<a href="mailto:general@lists.openfabrics.org">general@lists.openfabrics.org</a><br><a href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general">http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general</a><br>
<br>To unsubscribe, please visit <a href="http://openib.org/mailman/listinfo/openib-general">http://openib.org/mailman/listinfo/openib-general</a><br></blockquote></div><br>