diff options
author | Jakub Kicinski <kuba@kernel.org> | 2025-01-07 19:08:39 +0300 |
---|---|---|
committer | Paolo Abeni <pabeni@redhat.com> | 2025-01-09 17:33:08 +0300 |
commit | d6c7b03497eef8b66bf0b5572881359913e39787 (patch) | |
tree | 2df232a781a855ac5d982f1d9351f31af47a6338 /net/core/netdev_rx_queue.c | |
parent | a3b3d2dc389568a77d0e25da17203e3616218e93 (diff) | |
download | linux-d6c7b03497eef8b66bf0b5572881359913e39787.tar.xz |
net: make sure we retain NAPI ordering on netdev->napi_list
Netlink code depends on NAPI instances being sorted by ID on
the netdev list for dump continuation. We need to be able to
find the position on the list where we left off if dump does
not fit in a single skb, and in the meantime NAPI instances
can come and go.
This was trivially true when we were assigning a new ID to every
new NAPI instance. Since we added the NAPI config API, we try
to retain the ID previously used for the same queue, but still
add the new NAPI instance at the start of the list.
This is fine if we reset the entire netdev and all NAPIs get
removed and added back. If driver replaces a NAPI instance
during an operation like DEVMEM queue reset, or recreates
a subset of NAPI instances in other ways we may end up with
broken ordering, and therefore Netlink dumps with either
missing or duplicated entries.
At this stage the problem is theoretical. Only two drivers
support queue API, bnxt and gve. gve recreates NAPIs during
queue reset, but it doesn't support NAPI config.
bnxt supports NAPI config but doesn't recreate instances
during reset.
We need to save the ID in the config as soon as it is assigned
because otherwise the new NAPI will not know what ID it will
get at enable time, at the time it is being added.
Reviewed-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Diffstat (limited to 'net/core/netdev_rx_queue.c')
0 files changed, 0 insertions, 0 deletions