Re: zero-copy networking & a performance drop

Ingo Oeser (ingo.oeser@informatik.tu-chemnitz.de)
Fri, 28 Jun 2002 11:33:10 +0200


On Thu, Jun 27, 2002 at 03:33:33PM -0700, Nivedita Singhvi wrote:
> - rx side processing can involve more work (stack length
> is simply longer) and so can legitimately take longer.
> This is especially true when options and out of order
> packets are involved, and TCP fast path processing
> on the rx side isnt taken. (I had done a breakdown
> of this based on some profiles last year, but dont
> have that at the moment)

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.

Regards

Ingo Oeser

-- 
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/