<br><br>
<div class="gmail_quote">On Wed, Aug 5, 2009 at 12:31 PM, Sasha Khapyorsky <span dir="ltr"><<a href="mailto:sashak@voltaire.com">sashak@voltaire.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">On 10:43 Wed 05 Aug     , Hal Rosenstock wrote:<br>><br>> Should this be done as a separate step on the way to the LFT parallelization<br>> across switches ?<br><br></div>What do you mean by "separate step" (separate from what)?</blockquote>

<div> </div>
<div>Separate patches: first to move the osm_ucast_mgr_set_fwd_table call up a level and a second one to the implement the LFT parallelization across switches underneath that.</div>
<div> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><span id=""></span><br><br>I'm trying to replay the idea again: each routing engine calculates LFTs<br>
and fill sw->new_lfts array accordingly, after all it calls a procedure<br>for sending switches' LFT blocks (and TOPs). So routing engine itself<br>should not care about how exactly LFT blocks update MADs submission is<br>
actually implemented.<br><font color="#888888"></font></blockquote>
<div> </div>
<div> </div>
<div>Yes, understood.</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"><font color="#888888"><span id=""></span><br>Sasha<br></font></blockquote></div><br>