netdev - 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-next>] [day] [month] [year] [list]

Message-ID: <53455581.7060209@solarflare.com>
Date:	Wed, 9 Apr 2014 15:13:21 +0100
From:	Edward Cree <ecree@...arflare.com>
To:	<netdev@...r.kernel.org>, Shawn Bohrer <sbohrer@...advisors.com>
CC:	Jonathan Cooper <jcooper@...arflare.com>
Subject: udp: Question about busy_poll change

Commit 005ec9743394010cd37d86c3fd2e81978231cdbf, "udp: Only allow busy
read/poll on connected sockets",
causes a performance regression (increased latency) on some
micro-benchmarks which don't connect() their UDP socket, and might well
have a similar effect on real applications that do the same thing.
As far as I can tell, the change is only needed in the case where the
UDP socket is bound to INADDR_ANY, _and_ traffic on the chosen UDP port
is received through more than one NIC (or perhaps through a NIC with
separate NAPI contexts per receive queue?)
In particular, busy polling makes sense for a client (which will only be
receiving packets from one remote address even though the socket is
unconnected), or for a socket which has been bound to an interface's
address (at least in the case of sfc, where we have one NAPI context for
all the receive queues on an interface).

So, what was the deeper rationale for this change?  Is there a
correctness issue or does the old behaviour just affect performance
through unnecessary busy_polling?  Or have I just misunderstood things
completely?
--
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