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/
This archive was generated by hypermail 2b29 : Sun Jun 30 2002 - 22:00:13 EST