From: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>
To: Nivedita Singhvi <niv@us.ibm.com>
Cc: "Hurwitz Justin W." <hurwitz@lanl.gov>, linux-kernel@vger.kernel.org
Subject: Re: zero-copy networking & a performance drop
Date: Fri, 28 Jun 2002 11:33:10 +0200 [thread overview]
Message-ID: <20020628113310.D647@nightmaster.csn.tu-chemnitz.de> (raw)
In-Reply-To: <Pine.LNX.4.33.0206271513320.13651-100000@w-nivedita2.des.beaverton.ibm.com>; from niv@us.ibm.com on Thu, Jun 27, 2002 at 03:33:33PM -0700
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
next prev parent reply other threads:[~2002-06-28 13:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-27 19:53 Nivedita Singhvi
2002-06-27 21:50 ` Hurwitz Justin W.
2002-06-27 22:33 ` Nivedita Singhvi
2002-06-28 9:33 ` Ingo Oeser [this message]
2002-06-28 16:43 ` Hurwitz Justin W.
-- strict thread matches above, loose matches on Subject: below --
2002-06-29 17:04 Nivedita Singhvi
2002-06-28 3:01 Hurwitz Justin W.
[not found] <Pine.LNX.4.44.0206271545220.17078-100000@alvie-mail.lanl.gov.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.33.0206271513320.13651-100000@w-nivedita2.des.beaverton.ibm.com.suse.lists.linux.kernel>
2002-06-28 2:59 ` Andi Kleen
2002-06-28 15:04 ` Nivedita Singhvi
2002-06-27 18:16 Hurwitz Justin W.
2002-06-27 21:08 ` Bernd Eckenfels
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020628113310.D647@nightmaster.csn.tu-chemnitz.de \
--to=ingo.oeser@informatik.tu-chemnitz.de \
--cc=hurwitz@lanl.gov \
--cc=linux-kernel@vger.kernel.org \
--cc=niv@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®