On Tue, 10 Sep 2024 08:16:05 +0200 Joe Damato wrote: > > > 2. The two step "takeover" which seemed to imply that we might > > > pull napi_id into napi_storage? Or maybe I just read that part > > > wrong? > > > > Yes, the suggestion here is to drop patch #2 from your series and > > keep napi_id as a user facing 'id' for the persistent storage. But, > > obviously, this requires persistent napi_id(s) that survive device > > resets. > > > > The function that allocates new napi_id is napi_hash_add > > from netif_napi_add_weight. So we can do either of the following: > > 1. Keep everything as is, but add the napi_rehash somewhere > > around napi_enable to 'takeover' previously allocated napi_id. > > 2. (preferred) Separate napi_hash_add out of netif_napi_add_weight. > > And have some new napi_hash_with_id(previous_napi_id) to expose it to the > > userspace. Then convert mlx5 to this new interface. > > Jakub is this what you were thinking too? > > If this is the case, then the netlink code needs to be tweaked to > operate on NAPI IDs again (since they are persistent) instead of > ifindex + napi_storage index? No strong preference on the driver facing API, TBH, your netif_napi_add_storage() with some additional 'ifs' in the existing functions should work. Also no strong preference on the uAPI, avoiding adding new fields is a little bit tempting. But if you think NAPI ID won't work or is less clean - we can stick the index in.
