Linus Torvalds wrote:
> Proof: the data to be sent out is in RAM. In fact, often it is cached
> in the CPU these days. In order to start sending out the packet, the
> smart card has to move all of the data from RAM/cache over the bus to
> the card. It can only start actually sending after that. Cost: bus
> speed to copy it over.
> In contrast, if you do it on the CPU, you can basically start feeding
> the packet out on the net after doing a CPU checksum that is limited
> by RAM/cache speeds. Bus speed isn't the limiting factor any more on
> packet latency, as you can send out the start of the packet on the
> network before the whole packet has even been copied over the internal
Nice point! Only valid for TCP & UDP though.
When people want _real_ low latency, they don't use TCP or UDP, and they
certainly don't put data checksums at the start. They still aim for
zero copies. That pass, even over cached data, is still significant.
> Right now gigabit is heavy-duty enough that it is worth smart cards.
> The same used to be true about the first generation of 100Mbit cards.
> The same will be true of 10Gbps cards in another few years. But
> basically, they'll probably always end up being the exception rather
> than the rule, unless they become so cheap that it doesn't matter. But
> "cheap" and "pushing the performance envelope" do not tend to go hand in
Fair enough. Please read my description of a zero-copy scheme that
doesn't require much intelligence on the card though. I think it's a
neat kernel trick that might just pay off. Sometimes, maybe.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:16 EST