Re: [PATCH net-next] wireguard: queuing: preserve napi_id on decapsulation

[Miroslav Lichvar <mlichvar@redhat.com>]

On Thu, Oct 30, 2025 at 06:57:34PM +0100, Jason A. Donenfeld wrote:
> > +#if defined(CONFIG_NET_RX_BUSY_POLL) || defined(CONFIG_XPS)
> > +               skb->napi_id = napi_id;
> > +#endif
> 
> Seems incorrect. Although the union where napi_id is defined has that
> define here:
> 
> #if defined(CONFIG_NET_RX_BUSY_POLL) || defined(CONFIG_XPS)
>        union {
>                unsigned int    napi_id;
>                unsigned int    sender_cpu;
>        };
> #endif
> 
> The skb_napi_id() has the narrower condition here:

> So I think all we care about is CONFIG_NET_RX_BUSY_POLL.

Ok, I'll fix that.

> > +       } else {
> 
> Why only do this in the !encapsulating case? Are get_timestamp() and
> put_ts_pktinfo() only called when !encapsulating?

Yes, I think so. The cmsg enabled by the timestamping option is added
only for received packets. Transmit timestamps are provided separately
with the packet looped back to the error queue (the timestamp is known
only after the actual transmission) and that can already provide the
index of the physical device in the IP_PKTINFO cmsg, which seems to
work correctly even with wireguard interfaces.

I'm not sure if the napi_id is actually used when sending. In my tests
it looked like it's the other field of the union, the sender cpu
index.

Thanks,

-- 
Miroslav Lichvar