<div dir="ltr">On Tue, Dec 3, 2013 at 10:45 PM, Greg Lindahl <span dir="ltr"><<a href="mailto:lindahl@pbm.com" target="_blank">lindahl@pbm.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On Mon, Dec 02, 2013 at 08:41:26AM -0500, atchley <a href="http://tds.net" target="_blank">tds.net</a> wrote:<br>
> On Mon, Dec 2, 2013 at 8:37 AM, atchley <a href="http://tds.net" target="_blank">tds.net</a> <<a href="mailto:atchley@tds.net">atchley@tds.net</a>> wrote:<br>
<br>
</div><div class="im">> > I am not sure what Aries currently offers that IB does not.<br>
<br>
</div>The IB in question is the True Scale adapter, which does some things<br>
really fast and other things pretty slowly. Aries has different<br>
features (quite different and more capable than IB, really), and is<br>
much larger.<br>
<br>
To put this into perspective, I suspect the typical modern Ethernet<br>
adapter has more gates than True Scale. If you're going to add<br>
something to a CPU, it had best be small. CPU guys get really irate if<br>
you reduce their yield.<br></blockquote><div><br></div><div>Given that the article said that it could borrow things not found in Ethernet or IB controllers, I don't think it was meant to be TS only.</div><div><br></div>
<div>What Aries features do you have in mind that are different and/or more capable? Are they expressed by the uGNI interface? I find the uGNI interface to be a strict subset of IB and the hardware has some interesting limits.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">> > As Myricom showed with MX over Ethernet followed by<br>
> > Mellanox with RoCE, you can get low latency over Ethernet bypassing the<br>
> > kernel and the TCP stack.<br>
<br>
</div>Indeed, Myricom+MX is quite similar in concept to the IB extension<br>
found in True Scale. The main difference (in my mind) is that OpenMX<br>
is hosted on a not-optimized-for-MX generic ethernet adapter, and that<br>
Myrinet's hardware was not fully optimized to do exactly what MX<br>
needed, nothing more and nothing less.</blockquote><div><br></div><div>Hmm, I was not speaking of OpenMX. It was a minor change to run the native MX on Myricom's NICs in Ethernet mode. The latency was no different than running MX on Myrinet until you went through a switch.</div>
<div><br></div><div>OpenMX is API, binary, and wire compatible with MX such that one could run MX on a Myricom 10G NIC connected to an Ethernet switch and OpenMX on a non-Myricom 10G Ethernet NIC connected to the same switch. Because OpenMX does not require specialized hardware, it sits atop the Ethernet driver in the kernel. It is not kernel-bypass, but it does bypass the full IP stack.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> True Scale is the smallest<br>
possible adapter that supports the basics of what MPI needs.<br>
<br>
The fabric is pretty irrelevant, as long as it has flexible<br>
routing. (See below for comments about SDN.)<br>
<div class="im"><br>
> > HPC sends a lot of small messages and various stacks are making use of<br>
> > 8-byte atomics. It is unhelpful to have a 64 byte minimum frame size in<br>
> > this case.<br>
<br>
</div>Yes, a smaller frame size is quite nice for achieving high message<br>
rates for tiny packets.<br>
<div class="im"><br>
> > Ethernet topology discovery protocols were designed for environments where<br>
> > equipment can be changed out, expanded, or otherwise altered.<br>
<br>
</div>This has changed in the new SDN (software defined networking)<br>
world. You can think of SDN on Ethernet as Infiniband management<br>
protocols implemented in ethernet, making many of the same mistakes<br>
that Infiniband did, plus some new ones.<br></blockquote><div><br></div><div>SDN is the Big Data of networking. It can be anything you want. ;-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="im">> Ethernet requires a single-path between any two endpoints.<br>
<br>
</div>This is not true. It's more accurate to say that ethernet (especially<br>
TCP) benefits from in-order delivery, which you can ensure either on a<br>
host-host basis (which is what spanning tree provides) or on a<br>
per-flow basis (which is what SDN allows.)<br>
<br>
Personally, I'm a bit bummed this won't happen until 2015 :-( but I'm<br>
really excited to see True Scale's basic design continue into another<br>
generation.</blockquote><div><br></div><div>You are confusing a transport layer with the L2 layer. Ethernet does not care about order. It does not care about reliability. These are provided at higher layers.</div><div><br>
</div><div>SDN has many uses. You can provide per-flow routing, but it can do much more.</div><div><br></div><div>I thought most SDN efforts were to provide routing between fabrics. Ethernet, by definition, is non-routing and is a common broadcast domain. I though STP et al took care of multiple paths to ensure single path between any two MACs. Is it possible for one host to send a broadcast and another host to receive multiple copies?<br>
</div><div><br></div><div>Scott</div></div></div></div>