mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®