Re: [PATCH net-next v3] xsk: skip validating skb list in xmit path

[Paolo Abeni <pabeni@redhat.com>]

On 11/25/25 12:57 PM, Jason Xing wrote:
> This patch also removes total ~4% consumption which can be observed
> by perf:
> |--2.97%--validate_xmit_skb
> |          |
> |           --1.76%--netif_skb_features
> |                     |
> |                      --0.65%--skb_network_protocol
> |
> |--1.06%--validate_xmit_xfrm
> 
> The above result has been verfied on different NICs, like I40E. I
> managed to see the number is going up by 4%.

I must admit this delta is surprising, and does not fit my experience in
slightly different scenarios with the plain UDP TX path.

> [1] - analysis of the validate_xmit_skb()
> 1. validate_xmit_unreadable_skb()
>    xsk doesn't initialize skb->unreadable, so the function will not free
>    the skb.
> 2. validate_xmit_vlan()
>    xsk also doesn't initialize skb->vlan_all.
> 3. sk_validate_xmit_skb()
>    skb from xsk_build_skb() doesn't have either sk_validate_xmit_skb or
>    sk_state, so the skb will not be validated.
> 4. netif_needs_gso()
>    af_xdp doesn't support gso/tso.
> 5. skb_needs_linearize() && __skb_linearize()
>    skb doesn't have frag_list as always, so skb_has_frag_list() returns
>    false. In copy mode, skb can put more data in the frags[] that can be
>    found in xsk_build_skb_zerocopy().

I'm not sure  parse this last sentence correctly, could you please
re-phrase?

I read it as as the xsk xmit path could build skb with nr_frags > 0.
That in turn will need validation from
validate_xmit_skb()/skb_needs_linearize() depending on the egress device
(lack of NETIF_F_SG), regardless of any other offload required.

/P