<br><br>
<div class="gmail_quote">On Mon, Sep 14, 2009 at 11:05 AM, Eli Dorfman (Voltaire) <span dir="ltr"><<a href="mailto:dorfman.eli@gmail.com">dorfman.eli@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im">Hal Rosenstock wrote:<br>><br>><br>> On Mon, Sep 14, 2009 at 10:32 AM, Eli Dorfman (Voltaire)<br></div>
<div class="im">> <<a href="mailto:dorfman.eli@gmail.com">dorfman.eli@gmail.com</a> <mailto:<a href="mailto:dorfman.eli@gmail.com">dorfman.eli@gmail.com</a>>> wrote:<br>><br>> Hal Rosenstock wrote:<br>
> ><br>> ><br>> > On Sun, Sep 13, 2009 at 3:55 AM, Doron Shoham <<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a><br>> <mailto:<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a>><br>
</div>
<div class="im">> > <mailto:<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a> <mailto:<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a>>>> wrote:<br>> ><br>> > Hal Rosenstock wrote:<br>
> > ><br>> > ><br>> > > On Thu, Sep 10, 2009 at 7:56 AM, Doron Shoham<br>> <<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a> <mailto:<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a>><br>
> > <mailto:<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a> <mailto:<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a>>><br>> > > <mailto:<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a> <mailto:<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a>><br>
> <mailto:<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a> <mailto:<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a>>>>> wrote:<br>> > ><br>> > > ibcheckroutes validates route between all hosts in the<br>
> fabric.<br>> > > This script finds all leaf switches (switches that are<br>> > connected to<br>> > > HCAs)<br>> > ><br>> ><br>> > This script parses the output of ibnetdiscoer.<br>
> > It finds all leaf switches (from the topology file<br>> > generated by ibnetdiscover).<br>> > The it checks if a route exists between all leaf switches<br>> > using ibtracert.<br>
> ><br>> ><br>> > Why leaf switches (and not CAs) ? How are they determined (from the<br>> > ibnetdiscover output) ?<br>><br>><br>><br>> How are the leaf switches determined (from core switches) in the<br>
> ibnetdiscover output ? Is it any switch which has an attached CA versus<br>> any switch which has no attached CAs ?<br></div>yes<br>
<div class="im"><br>><br>><br>><br>> because there are much less combinations (routes) of leaf switches<br>> than CAs.<br>><br>><br>> So is the check is that there are routes between all the leaf switches ?<br>
</div>yes<br>
<div class="im">><br>><br>> And since we assume that opensm routing builds lid matrix based on<br>> switch connectivity than if two switches have route between each<br>> other then all CAs that are connected to them will have route to<br>
> each other.<br>><br>><br>> I can't parse this sentence. Also, this should have nothing to do with<br>> OpenSM as it is SM independent AFAIT.<br></div>since we check routes between leaf switches LIDs, for opensm this also assures that we have route between CAs that are attached to them.<br>
</blockquote>
<div> </div>
<div>Not quite. It assures there should be a path but not necessarily a route as all the LFTs are not checked with the CA port LIDs.</div>
<div> </div>
<div>-- Hal</div>
<div> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div>
<div></div>
<div class="h5"><br>><br>><br>> In ibnetdiscover you can see to which switch (LID) each CA is connected.<br>><br>><br>> Sure.<br>><br>><br>><br>> ><br>> ><br>> ><br>
> > ><br>> > > CAs or HCAs ?<br>> > CAs<br>> > ><br>> > > What about switch port 0s ?<br>> > It checks connectivity only between leaf switches (not all<br>
> switches).<br>> > I assume that traffic is generated only between CAs and therefor<br>> > connectivity between other switches (not leaf switches) does not<br>> > important.<br>
> ><br>> ><br>> > It's important for a couple of reasons: first PMA access on<br>> switches and<br>> > secondly it's an IBA requirement although some OpenSM routing<br>
> protocols<br>> > ignore this. IMO it should be an option (not the default) to add these<br>> > LIDs in too to the ones checked.<br>><br>> Ok, we can this option once this patch is applied.<br>
><br>><br>> I have some other specific comments on the patch.<br>><br>><br>> Also it may be better to provide the switch LID(s) from which PM is<br>> running to reduce number of tested routes.<br>
><br>><br>> This is in the vein of only checking leaf switch connectivity but is not<br>> the IBA general requirement.<br>><br>> -- Hal<br>><br>><br>><br>> Eli<br>><br>> ><br>
> ><br>> ><br>> ><br>> > ><br>> > ><br>> > > and runs ibtracert between them.<br>> > > When using various routing algorithms (e.g. up-down),<br>
> > ><br>> > ><br>> > > With which routing algorithms has this been tried ?<br>> > I assume that from complexity perspective, the routing algorithms<br>> > calculate<br>
> > routes only between leaf switches and not between all CAs.<br>> > Then it adds one hop for all CAs connected to the leaf switches.<br>> ><br>> ><br>> > It depends on the routing algorithm (some violate this) but the basic<br>
> > IBA requirement is:<br>> > *<br>> ><br>> > C14-62.1.4:<br>> ><br>> > *From every endport within the subnet, the SM *shall *provide at least<br>> > one reversible path to every other endport.<br>
> ><br>> > -- Hal<br>> ><br>> ><br>> > I've tested it with up-down but it really doesn't matter which<br>> > routing algorithm you are using.<br>
> > It just check the routes between leaf switches (and if the routing<br>> > algorithm behave as above, it means that it checks all CAs<br>> > connectivity).<br>> ><br>
> > ><br>> > > -- Hal<br>> > ><br>> > ><br>> > > if fabric topology is not suitable there will be no<br>> > > routes between some nodes.<br>
> > > It reports when the route exists between source and<br>> > destination LIDs.<br>> > ><br>> > > Signed-off-by: Doron Shoham <<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a><br>
> <mailto:<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a>><br>> > <mailto:<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a> <mailto:<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a>>><br>
</div></div>
<div class="im">> > > <mailto:<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a> <mailto:<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a>><br></div>
<div class="im">> <mailto:<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a> <mailto:<a href="mailto:dorons@voltaire.com">dorons@voltaire.com</a>>>>><br>> > ><br>> > ><br>
> > > <snip...><br>> ><br>> ><br>> ><br>> ><br>> ------------------------------------------------------------------------<br>> ><br>> > _______________________________________________<br>
> > general mailing list<br></div>> > <a href="mailto:general@lists.openfabrics.org">general@lists.openfabrics.org</a> <mailto:<a href="mailto:general@lists.openfabrics.org">general@lists.openfabrics.org</a>><br>
<div>
<div></div>
<div class="h5">> > <a href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general" target="_blank">http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general</a><br>> ><br>> > To unsubscribe, please visit<br>
> <a href="http://openib.org/mailman/listinfo/openib-general" target="_blank">http://openib.org/mailman/listinfo/openib-general</a><br>><br>><br><br></div></div></blockquote></div><br>