netdev - Re: udp: Question about busy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 9 Apr 2014 17:20:04 +0100
From:	Edward Cree <ecree@...arflare.com>
To:	Shawn Bohrer <shawn.bohrer@...il.com>
CC:	<netdev@...r.kernel.org>, Shawn Bohrer <sbohrer@...advisors.com>,
	Jonathan Cooper <jcooper@...arflare.com>,
	<eric.dumazet@...il.com>
Subject: Re: udp: Question about busy_poll change

On 09/04/14 15:51, Shawn Bohrer wrote:
> I believe the sfc case where you only have a single NAPI context is
> also valid and it seems reasonable to me that if you can detect that
> specific case that busy polling could be allowed.  I'm not sure how to
> detect this.  I'm sure patches are welcome.
I think that to detect this we would have to have (a) a flag in the
struct sock to say that "this socket is bound to a real address" (ie.
not INADDR_ANY, multicast or anycast), (b) a flag in the skb to say that
"the driver that received this packet only uses one NAPI context per
intf.  Then if a && b you can fill in sk_napi_id even on unconnected
sockets.  If this sounds reasonable, I'll put a patch together.
> If we are spinning on a NAPI context and a packet arrives in a
> different rx queue then you'll get unpredictable latencies and
> out of order packets.  For the people using this feature that is
> probably not desirable.
A further question is, what happens if the user removes the IP address
from one interface and adds it to another?  AFAICT they will keep
busy_polling the old NAPI context until a packet is received on the new
interface and updates sk->sk_napi_id; and this is still the case even if
the socket is connected.  Of course this could be a case of "don't do
that then", but I can imagine some kind of hot-failover setup doing this.
This is also why we'd need a flag in the skb and can't just find out at
bind() time what the driver is and whether it uses multiple NAPI
contexts - because when the socket moves interface, it could end up on a
different driver.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html