Hi Sasha,
Sasha Khapyorsky wrote:
On 13:09 Wed 04 Nov , Yevgeny Kliteynik wrote:
This patch implements connect_switches option in up/down
routing. Also, connect_roots is now handled as a special
case of connect_switches.
The idea is the following: when clearing hops, preserve
the entries for switches that are above the highest leaf
in the tree.
So if the highest leaf in the tree has rank N, preserve
hops to all the switches with ranks 0 to (N-1).
When connecting roots (--connect_roots option), just set
N to 1.
Would this affect multicast routing in sense of a credit loop
generation?
Since I sent these patches, I had it running in various
simulations and setups, and there are couple of fundamental
issue with this approach. Basically, what I did here (in up/dn)
is wrong. Not only for multicast, but for unicast too.
It interferes with the usual up/down paths routing.
I will issue V3 of the patches, and it will be only
connect_roots implementation for fat-tree with the
two small remarks that you found.
As for the general algorithm for connecting switches,
the whole approach of the connect_roots option and of
what I was lately trying to do with connect_switches
option is wrong. There is no need to connect all the
roots to each other. There's also no need to connect
all the switches to each other.
What we need is a connection between all the *managed*
switches (extended port 0) to all the other switches
in the fabric in both directions.
This option should *replace* the connect_roots option
functionality (though we can leave connect_roots for
backward compatibility).
I'll work on the algorithm, but clearly it won't be
ready for OFED 1.5.
If you have any thoughts about this idea, I'd be happy
to hear them.
-- Yevgeny
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html