From: David Miller <davem@davemloft.net>
To: felix@chelsio.com
Cc: sean.hefty@intel.com, netdev@vger.kernel.org, rdreier@cisco.com,
general@lists.openfabrics.org, linux-kernel@vger.kernel.org,
jeff@garzik.org
Subject: Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
Date: Sun, 19 Aug 2007 18:05:40 -0700 (PDT) [thread overview]
Message-ID: <20070819.180540.74750322.davem@davemloft.net> (raw)
In-Reply-To: <8A71B368A89016469F72CD08050AD334018E20BE@maui.asicdesigners.com>
From: "Felix Marti" <felix@chelsio.com>
Date: Sun, 19 Aug 2007 17:47:59 -0700
> [Felix Marti]
Please stop using this to start your replies, thank you.
> David and Herbert, so you agree that the user<>kernel
> space memory copy overhead is a significant overhead and we want to
> enable zero-copy in both the receive and transmit path? - Yes, copy
> avoidance is mainly an API issue and unfortunately the so widely used
> (synchronous) sockets API doesn't make copy avoidance easy, which is one
> area where protocol offload can help. Yes, some apps can resort to
> sendfile() but there are many apps which seem to have trouble switching
> to that API... and what about the receive path?
On the send side none of this is an issue. You either are sending
static content, in which using sendfile() is trivial, or you're
generating data dynamically in which case the data copy is in the
noise or too small to do zerocopy on and if not you can use a shared
mmap to generate your data into, and then sendfile out from that file,
to avoid the copy that way.
splice() helps a lot too.
Splice has the capability to do away with the receive side too, and
there are a few receivefile() implementations that could get cleaned
up and merged in.
Also, the I/O bus is still the more limiting factor and main memory
bandwidth in all of this, it is the smallest data pipe for
communications out to and from the network. So the protocol header
avoidance gains of TSO and LRO are still a very worthwhile savings.
But even if RDMA increases performance 100 fold, it still doesn't
avoid the issue that it doesn't fit in with the rest of the networking
stack and feature set.
Any monkey can change the rules around ("ok I can make it go fast as
long as you don't need firewalling, packet scheduling, classification,
and you only need to talk to specific systems that speak this same
special protocol") to make things go faster. On the other hand well
designed solutions can give performance gains within the constraints
of the full system design and without sactificing functionality.
next prev parent reply other threads:[~2007-08-20 1:05 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-07 14:37 [PATCH RFC] RDMA/CMA: Allocate PS_TCP ports from the host TCP port space Steve Wise
2007-08-07 14:54 ` Evgeniy Polyakov
2007-08-07 15:06 ` Steve Wise
2007-08-07 15:39 ` Evgeniy Polyakov
2007-08-09 18:49 ` Steve Wise
2007-08-09 21:40 ` [ofa-general] " Sean Hefty
2007-08-09 21:55 ` David Miller
2007-08-09 23:22 ` Sean Hefty
2007-08-15 14:42 ` Steve Wise
2007-08-16 2:26 ` Jeff Garzik
2007-08-16 3:11 ` Roland Dreier
2007-08-16 3:27 ` [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCP portsfrom " Sean Hefty
2007-08-16 13:43 ` [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCP ports from " Tom Tucker
2007-08-16 21:17 ` David Miller
2007-08-17 19:52 ` Roland Dreier
2007-08-17 21:27 ` David Miller
2007-08-17 23:31 ` Roland Dreier
2007-08-18 0:00 ` David Miller
2007-08-18 5:23 ` Roland Dreier
2007-08-18 6:44 ` David Miller
2007-08-19 7:01 ` [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCP portsfrom " Sean Hefty
2007-08-19 7:23 ` David Miller
2007-08-19 17:33 ` [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom " Felix Marti
2007-08-19 19:32 ` David Miller
2007-08-19 19:49 ` Felix Marti
2007-08-19 23:04 ` David Miller
2007-08-20 0:32 ` Felix Marti
2007-08-20 0:40 ` David Miller
2007-08-20 0:47 ` Felix Marti
2007-08-20 1:05 ` David Miller [this message]
2007-08-20 1:41 ` Felix Marti
2007-08-20 11:07 ` Andi Kleen
2007-08-20 16:26 ` Felix Marti
2007-08-20 19:16 ` Rick Jones
2007-08-20 9:43 ` Evgeniy Polyakov
2007-08-20 16:53 ` Felix Marti
2007-08-20 18:10 ` Andi Kleen
2007-08-20 19:02 ` Felix Marti
2007-08-20 20:18 ` Thomas Graf
2007-08-20 20:33 ` Andi Kleen
2007-08-20 20:33 ` Patrick Geoffray
2007-08-21 4:21 ` Felix Marti
2007-08-19 23:27 ` Andi Kleen
2007-08-19 23:12 ` David Miller
2007-08-20 1:45 ` Felix Marti
2007-08-20 0:18 ` Herbert Xu
2007-08-21 1:16 ` [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCP ports from " Roland Dreier
2007-08-21 6:58 ` David Miller
2007-08-28 19:38 ` Roland Dreier
2007-08-28 20:43 ` David Miller
2007-10-08 21:54 ` Steve Wise
2007-10-09 13:44 ` James Lentini
2007-10-10 21:01 ` Sean Hefty
2007-10-10 23:04 ` David Miller
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=20070819.180540.74750322.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=felix@chelsio.com \
--cc=general@lists.openfabrics.org \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rdreier@cisco.com \
--cc=sean.hefty@intel.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