All of lore.kernel.org
 help / color / mirror / Atom feed
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: Thu, 08 Aug 2013 11:46:17 +0300	[thread overview]
Message-ID: <52035AD9.30703@linux.intel.com> (raw)
In-Reply-To: <1375906946.4004.45.camel@edumazet-glaptop>


On 07/08/2013 23:22, Eric Dumazet wrote:
> On Tue, 2013-08-06 at 14:51 -0500, Shawn Bohrer wrote:
>> Set the napi id for each socket in the multicast path to enable
>> low-latency/polling support.
>>
>> Signed-off-by: Shawn Bohrer <sbohrer@rgmadvisors.com>
>> ---
>> v2 include ipv6 support
> 
> This might help your workload, but I doubt it is generic enough.
> 
> One UDP socket is supposed to receive traffic from many endpoints,
> so we have no guarantee all the received traffic will end on a single RX
> queue on the NIC.
> 
> That's the same logic than RFS here.
> 
> 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.

  reply	other threads:[~2013-08-08  8:46 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 [this message]
2013-08-08 23:55           ` Eric Dumazet
2013-08-11  7:59             ` Eliezer Tamir
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=52035AD9.30703@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.