On Tue, Sep 03, 2024 at 12:40:08PM -0700, Jakub Kicinski wrote:

On Tue, 3 Sep 2024 12:04:52 -0700 Samiullah Khawaja wrote:

quoted

Do we need a queue to napi association to set/persist napi
configurations? 

I'm afraid zero-copy schemes will make multiple queues per NAPI more
and more common, so pretending the NAPI params (related to polling)
are pre queue will soon become highly problematic.

quoted

Can a new index param be added to the netif_napi_add
and persist the configurations in napi_storage.

That'd be my (weak) preference.

quoted

I guess the problem would be the size of napi_storage.

I don't think so, we're talking about 16B per NAPI, 
struct netdev_queue is 320B, struct netdev_rx_queue is 192B. 
NAPI storage is rounding error next to those :S

quoted

Also wondering if for some use case persistence would be problematic
when the napis are recreated, since the new napi instances might not
represent the same context? For example If I resize the dev from 16
rx/tx to 8 rx/tx queues and the napi index that was used by TX queue,
now polls RX queue.

We can clear the config when NAPI is activated (ethtool -L /
set-channels). That seems like a good idea.

I'm probably misunderstanding this bit; I've implemented this by
just memsetting the storages to 0 on napi_enable which obviously
breaks the persistence and is incorrect because it doesn't respect
sysfs.

I'm going to send what I have as an RFC anyway, because it might be
easier to discuss by commenting on code that is (hopefully) moving
in the right direction?

I hope that's OK; I'll explicitly call it out in the cover letter
that I am about to send.

- Joe