From: Roland Dreier <rdreier@cisco.com>
To: David Miller <davem@davemloft.net>
Cc: tom@opengridcomputing.com, jeff@garzik.org,
swise@opengridcomputing.com, mshefty@ichips.intel.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
general@lists.openfabrics.org
Subject: Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCP ports from the host TCP port space.
Date: Fri, 17 Aug 2007 22:23:01 -0700 [thread overview]
Message-ID: <adatzqxwh56.fsf@cisco.com> (raw)
In-Reply-To: <20070817.170033.63993876.davem@davemloft.net> (David Miller's message of "Fri, 17 Aug 2007 17:00:33 -0700 (PDT)")
> This is also a series of falsehoods. All packet filtering,
> queue management, and packet scheduling facilities work perfectly
> fine and as designed with both LRO and TSO.
I'm not sure I follow. Perhaps "broken" was too strong a word to use,
but if you pass a huge segment to a NIC with TSO, then you've given
the NIC control of scheduling the packets that end up getting put on
the wire. If your software packet scheduling is operating at a bigger
scale, then things work fine, but I don't see how you can say that TSO
doesn't lead to head-of-line blocking etc at short time scales. And
yes of course I agree you can make sure things work by using short
segments or not using TSO at all.
Similarly with LRO the packets that get passed to the stack are not
the packets that were actually on the wire. Sure, most filtering will
work fine but eg are you sure your RTT estimates aren't going to get
screwed up and cause some subtle bug? And I could trot out all the
same bugaboos that are brought up about RDMA and warn darkly about
security problems with bugs in NIC hardware that after all has to
parse and rewrite TCP and IP packets.
Also, looking at the complexity and bug-fixing effort that go into
making TSO work vs the really pretty small gain it gives also makes
part of me wonder whether the noble proclamations about
maintainability are always taken to heart.
Of course I know everything I just wrote is wrong because I forgot to
refer to the crucial axiom that stateless == good && RDMA == bad.
And sometimes it's unfortunate that in Linux when there's disagreement
about something, the default action is *not* to do something.
Sorry for prolonging this argument. Dave, I should say that I
appreciate all the work you've done in helping build the most kick-ass
networking stack in history. And as I said before, I have plenty of
interesting work to do however this turns out, so I'll try to leave
any further arguing to people who actually have a dog in this fight.
- R.
next prev parent reply other threads:[~2007-08-18 5:23 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 [this message]
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
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=adatzqxwh56.fsf@cisco.com \
--to=rdreier@cisco.com \
--cc=davem@davemloft.net \
--cc=general@lists.openfabrics.org \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mshefty@ichips.intel.com \
--cc=netdev@vger.kernel.org \
--cc=swise@opengridcomputing.com \
--cc=tom@opengridcomputing.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