Re: zero-copy networking & a performance drop

From: Hurwitz Justin W. (
Date: Fri Jun 28 2002 - 11:43:06 EST

On Fri, 28 Jun 2002, Ingo Oeser wrote:

> Jupp, I think this is really true. Look at all the checking alone.
> Remember: We accept data from an untrusted source (network) which
> has lots of control information encoded with many of them
> being optional.
> -> This involves a lot of "parsing" (for binary streams,
> decoding might be better) of a complex language (TCP/IP ;-))
> with many optional elements (read: lots of branches in the
> language tree).
> On sending data, we have all the information trusted, because we
> checked that already, as the user sets it. With sendfile, we have
> even trusted and mapped data (because we just paged it in before).
> If we take this into account, rx MUST be always slower, or tx
> isn't really optimized yet.

Indeed, the above does make sense. But, what about when the receive side
is trustable, too. This is obviously not the normal case; but with
quadrics I think that it is. Since quadrics is a shared memory
architecture, with all of the processing taken care of on the cards, we
should be able to reliably trust the receive side as much as the send
side. Unless I'm misunderstanding your use of trust?

If I am right on this, how much of an overhaul would it be to implement,
for instance, a NETIF_RX_TRUSTED flag in the net_device struct to force a
receive side fast path? I don't expect this to bring the receive side even
with the transmit side, but right now we (and I have heard the same from
others) are running at ~70% of the transmit side on the receive side,
which seems to leave a good margin for improvement.

This seems like it could be useful not just for the special case of
quadrics (and other shared mamory architectures)- if, for instance, cards
begin to do more TCP processing in hardware (or we modify the firmware to
do this for us, ala AceNIC), it would be nice to bypass it in the kernel.
This is, of course, a quick idea that's just popped into my head, and
probably is inherently impossible or foolish :)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Jun 30 2002 - 22:00:13 EST