xsk: Fix l2fwd for copy mode + busy poll combo
authorMaciej Fijalkowski <maciej.fijalkowski@intel.com>
Wed, 6 Apr 2022 15:58:04 +0000 (17:58 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 9 May 2022 07:14:32 +0000 (09:14 +0200)
commitd84f8327af13b975d3ccd5eeb4f4c6e58dc7674d
treebd20ef2edb10a446b5eba95ca0cd988861ceaecb
parent3ec920d755ae69c201b358e8d8e96c32f51145d8
xsk: Fix l2fwd for copy mode + busy poll combo

[ Upstream commit 8de8b71b787f38983d414d2dba169a3bfefa668a ]

While checking AF_XDP copy mode combined with busy poll, strange
results were observed. rxdrop and txonly scenarios worked fine, but
l2fwd broke immediately.

After a deeper look, it turned out that for l2fwd, Tx side was exiting
early due to xsk_no_wakeup() returning true and in the end
xsk_generic_xmit() was never called. Note that AF_XDP Tx in copy mode
is syscall steered, so the current behavior is broken.

Txonly scenario only worked due to the fact that
sk_mark_napi_id_once_xdp() was never called - since Rx side is not in
the picture for this case and mentioned function is called in
xsk_rcv_check(), sk::sk_napi_id was never set, which in turn meant that
xsk_no_wakeup() was returning false (see the sk->sk_napi_id >=
MIN_NAPI_ID check in there).

To fix this, prefer busy poll in xsk_sendmsg() only when zero copy is
enabled on a given AF_XDP socket. By doing so, busy poll in copy mode
would not exit early on Tx side and eventually xsk_generic_xmit() will
be called.

Fixes: a0731952d9cd ("xsk: Add busy-poll support for {recv,send}msg()")
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20220406155804.434493-1-maciej.fijalkowski@intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
net/xdp/xsk.c