Re: [PATCH net-next 2/4] i40e: add support for bpf_xdp_metadata_rx_hash()

[Jakub Kicinski <kuba@kernel.org>]

On Fri, 04 Sep 2026 09:19:55 +0000 netdev-bot+sashiko@kernel.org wrote:
> > @@ -13784,6 +13813,7 @@ static int i40e_config_netdev(struct i40e_vsi *vsi)
> >  	i40e_vsi_config_netdev_tc(vsi, vsi->tc_config.enabled_tc);
> >  
> >  	netdev->netdev_ops = &i40e_netdev_ops;
> > +	netdev->xdp_metadata_ops = &i40e_xdp_metadata_ops;  
> 
> [Severity: Medium]
> Should this assignment live inside the I40E_VSI_MAIN branch, next to where
> the rest of the XDP capability state is set?
> 
> Earlier in i40e_config_netdev() the XDP capabilities are set only for the
> main VSI:
> 
> 	if (vsi->type == I40E_VSI_MAIN) {
> 		...
> 		netdev->xdp_features = NETDEV_XDP_ACT_BASIC |
> 				       NETDEV_XDP_ACT_REDIRECT |
> 				       NETDEV_XDP_ACT_XSK_ZEROCOPY |
> 				       NETDEV_XDP_ACT_RX_SG;
> 		netdev->xdp_zc_max_segs = I40E_MAX_BUFFER_TXD;
> 	} else {
> 		/* Relate the VSI_VMDQ name to the VSI_MAIN name ... */
> 
> but i40e_config_netdev() also runs for VMDQ2 netdevs, via i40e_vsi_setup():
> 
> 	switch (vsi->type) {
> 	/* setup the netdev if needed */
> 	case I40E_VSI_MAIN:
> 	case I40E_VSI_VMDQ2:
> 		ret = i40e_config_netdev(vsi);
> 
> Those macvlan-offload "<pf>v%d" netdevs get xdp_features == 0, and
> i40e_xdp() rejects every ndo_bpf command on them:
> 
> 	if (vsi->type != I40E_VSI_MAIN)
> 		return -EINVAL;
> 
> So no native XDP program can be attached there, and xmo_rx_hash can never
> be reached on such a netdev.
> 
> Does this make the netlink capability report inconsistent?  netdev_nl_dev_fill()
> derives the xdp-rx-metadata-features bits purely from the presence of the
> callback, with no cross-check against dev->xdp_features:
> 
> net/core/netdev-genl.c:netdev_nl_dev_fill() {
> 	...
> #define XDP_METADATA_KFUNC(_, flag, __, xmo)			\
> 	if (netdev->xdp_metadata_ops && netdev->xdp_metadata_ops->xmo)	\
> 		xdp_rx_meta |= flag;
> 	...
> }
> 
> which means a VMDQ2 netdev advertises NETDEV_XDP_RX_METADATA_HASH ("Device is
> capable of exposing receive packet hash via bpf_xdp_metadata_rx_hash()") while
> rejecting XDP entirely.
> 
> The follow-up patch adding bpf_xdp_metadata_rx_vlan_tag() extends the same
> unconditional assignment, so NETDEV_XDP_RX_METADATA_VLAN_TAG ends up reported
> on those netdevs too; the assignment is still unconditional at the end of the
> series.

Unclear to me whether it's a responsibility of the driver of the
netlink side should skip reporting if xdp_features are empty.
Let's punt on this..