On Jan 27, 2014, at 5:00 PM, Curtis Villamizar
<curtis(_at_)ipv6(_dot_)occnc(_dot_)com> wrote:
In message <52E6AB15(_dot_)2080907(_at_)isi(_dot_)edu>
Joe Touch writes:
On 1/27/2014 10:48 AM, joel jaeggli wrote:
On 1/27/14, 8:48 AM, Joe Touch wrote:
Those same mechanisms have provided hardware checksum support for a very
long time.
The new header and the payload are actually in different parts of the
forwarding complex until they hit the output queue, you can't checksum
data you don't have.
You can (and some do) the checksum component parts when things go into
memory; the partial sums can be added as the parts are combined in the
output queue.
I appreciate that we're all taking about what might be done, but the
reality is that there are many 'transparent TCP proxies' that have to
do this, so there's clearly a solution, and it clearly runs fast
enough.
Joe
Joe,
Chips that did 4 x 10 Gb/s are old stuff now but in their day they
pushed silicon limites. Chips now do N x 100 Gb/s.
Yes, and it's 18 years later.
Stewart is
describing how these chips (both the prior generation and current) are
architected and you are going back to some idea that there is a common
memory where this all resides and its just a matter of looking at it.
This is not software on a general purpose processor.
I never said software; I said that the checksum can be computed as the data
moves (which is how we did it in 1996).
If a queue forms, the headers are in SRAM and the body of the packet
is off chip in DRAM. There isn't enough memory bandwidth to pull the
packet back until its time to send it out. At that point the header
and body are joined but the header processing has been completed long
ago.
At some point the two come back together, at which point the partial sums of
the header and body can be combined and inserted in the header.
...
If there is no queue at all cut-through can happen. The header gets
transmitted before the entire packet arrives at the input of the
chip. (And if FCS fails a runt with bad FCS goes out).
At the very least this can't work if cut-through is used to reduce
latency.
Latency is a complex function of the bandwidth, propagation, coding, and
processing delays, and there are very rare cases where cut-through reductions
would impact E2E latency.
In those cases, there are other good reasons not to use UDP encapsulation.
When the two are joined, about the only processing is in the
MAC, its mostly loading a shift register and serializing but it also
does the FCS and sticks that *at the end*. The MAC is quite
inflexible as it is mostly silicon gates designed to do some minimal
processing for a layer-2 such as Ethernet or GFP/OTN.
Think for a moment what N x 100 Gb/s means. For small packets 150
Mpps per interface with Ethernet overhead (large overhead). That is
20 clock cycles per packet for a 3 GHz clock rate. Divide that by N.
This has to be done in specialized hardware
The hardware required is trivial, and easy to include in the same transfer
mechanism used to move data (as it already has been for many years in network
interfaces).
BTW - "transparent TCP proxies" don't need to look at the payload for
the purpose of updating a checksum.
That depends on whether the segments boundaries are preserved.
Joe