From: Eliezer Tamir <eliezer.tamir@linux.intel.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Shawn Bohrer <sbohrer@rgmadvisors.com>,
davem@davemloft.net, netdev@vger.kernel.org,
Amir Vadai <amirv@mellanox.com>,
tomk@rgmadvisors.com
Subject: Re: [PATCH v2 net-next] net: Add low-latency/polling support for UDP multicast
Date: Sun, 11 Aug 2013 10:59:39 +0300 [thread overview]
Message-ID: <5207446B.4080003@linux.intel.com> (raw)
In-Reply-To: <1376006114.4004.141.camel@edumazet-glaptop>
On 09/08/2013 02:55, Eric Dumazet wrote:
> On Thu, 2013-08-08 at 11:46 +0300, Eliezer Tamir wrote:
>> On 07/08/2013 23:22, Eric Dumazet wrote:
>>> sk_mark_napi_id() in UDP are wrong IMHO.
>>>
>>> It should be guarded by the following test in
>>> __udp_queue_rcv_skb()
>>>
>>> if (inet_sk(sk)->inet_daddr) {
>>> sock_rps_save_rxhash(sk, skb);
>>> sk_mark_napi_id(sk, skb);
>>> }
>>>
>>> (To occur only for connected UDP sockets, where we are 100% sure all
>>> packets will use this same rxhash/rx queue)
>>
>> This would also be safe if there is only one NIC and said NIC was
>> programmed to always place this socket's data on the same queue.
>>
>> I don't have a good suggestion on how to detect this.
>
> Well, this stuff relies on flows being correctly steered.
>
> TCP stack performs much better if we avoid reorders ;)
Let's limit the discussion to UDP for now.
If you are getting packets on multiple queues for a TCP socket,
it's hard to see how you can avoid caused reordering.
Maybe it would be enough to have a socket option that the user
can set to tell the stack "I know what I'm doing, please allow busy
polling on this UDP socket, even though it's not bound".
next prev parent reply other threads:[~2013-08-11 7:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-05 21:22 low latency/busy poll feedback and bugs Shawn Bohrer
2013-08-05 22:16 ` [PATCH net-next] net: Add low-latency/polling support for UDP multicast Shawn Bohrer
2013-08-06 7:13 ` Eliezer Tamir
2013-08-06 19:51 ` [PATCH v2 " Shawn Bohrer
2013-08-07 20:22 ` Eric Dumazet
2013-08-08 8:46 ` Eliezer Tamir
2013-08-08 23:55 ` Eric Dumazet
2013-08-11 7:59 ` Eliezer Tamir [this message]
2013-08-06 7:41 ` low latency/busy poll feedback and bugs Eliezer Tamir
2013-08-06 18:08 ` Shawn Bohrer
2013-08-06 18:25 ` Eliezer Tamir
2013-08-07 20:05 ` Ben Hutchings
2013-08-07 20:23 ` Eric Dumazet
2013-08-07 23:41 ` David Miller
2013-08-06 20:39 ` Or Gerlitz
2013-08-06 21:02 ` Eric Dumazet
2013-08-06 12:15 ` Amir Vadai
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=5207446B.4080003@linux.intel.com \
--to=eliezer.tamir@linux.intel.com \
--cc=amirv@mellanox.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=sbohrer@rgmadvisors.com \
--cc=tomk@rgmadvisors.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;
as well as URLs for NNTP newsgroup(s).