From: netdev-bot+sashiko@kernel.org
To: anthony.l.nguyen@intel.com
Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
edumazet@google.com, andrew+netdev@lunn.ch,
netdev@vger.kernel.org, chris.packham@alliedtelesis.co.nz,
kohei.enju@gmail.com, enjuk@amazon.com,
przemyslaw.kitszel@intel.com, blair.steven@alliedtelesis.co.nz,
carl.smith@alliedtelesis.co.nz, horms@kernel.org,
maciej.fijalkowski@intel.com, magnus.karlsson@intel.com,
ast@kernel.org, daniel@iogearbox.net, hawk@kernel.org,
john.fastabend@gmail.com, sdf@fomichev.me, bpf@vger.kernel.org,
aleksandr.loktionov@intel.com, sx.rinitha@intel.com
Subject: Re: [PATCH net-next 2/4] i40e: add support for bpf_xdp_metadata_rx_hash()
Date: Fri, 04 Sep 2026 09:19:55 +0000 [thread overview]
Message-ID: <178851359588.4131868.14209764775589320419@kernel.org> (raw)
In-Reply-To: <20260901211752.1922993-3-anthony.l.nguyen@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:
Critical: 0 · High: 0 · Medium: 1 · Low: 0
- [Medium] i40e_config_netdev() sets `netdev->xdp_metadata_ops =
&i40e_xdp_metadata_ops;` unconditionally…
--
i40e: add support for bpf_xdp_metadata_rx_hash()
This adds i40e_xdp_rx_hash() as an xdp_metadata_ops callback, extracting
the RSS hash and hash type from the RX descriptor the same way
i40e_rx_hash() does. A new I40E_RX_DESC_STATUS_FLTSTAT_MASK helper is
added to i40e_type.h and the ops struct is installed on the netdev.
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index 4b11ae9ed8d53..e487d697a634f 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
[ ... ]
> @@ -13582,6 +13583,34 @@ static int i40e_xdp(struct net_device *dev,
> }
> }
>
> +static int i40e_xdp_rx_hash(const struct xdp_md *_ctx, u32 *hash,
> + enum xdp_rss_hash_type *rss_type)
> +{
> + const struct i40e_xdp_buff *ctx = (const void *)_ctx;
> + const union i40e_rx_desc *desc = ctx->desc;
> + struct libeth_rx_pt rx_ptype;
> + u8 raw_rx_ptype;
> + u64 status;
> +
> + status = le64_to_cpu(desc->wb.qword1.status_error_len);
> + raw_rx_ptype = FIELD_GET(I40E_RXD_QW1_PTYPE_MASK, status);
> + rx_ptype = libie_rx_pt_parse(raw_rx_ptype);
> +
> + if (!libeth_rx_pt_has_hash(ctx->xdp.rxq->dev, rx_ptype) ||
> + FIELD_GET(I40E_RX_DESC_STATUS_FLTSTAT_MASK, status) !=
> + I40E_RX_DESC_FLTSTAT_RSS_HASH)
> + return -ENODATA;
> +
> + *hash = le32_to_cpu(desc->wb.qword0.hi_dword.rss);
> + *rss_type = rx_ptype.hash_type;
> +
> + return 0;
> +}
> +
> +static const struct xdp_metadata_ops i40e_xdp_metadata_ops = {
> + .xmo_rx_hash = i40e_xdp_rx_hash,
> +};
> +
> static const struct net_device_ops i40e_netdev_ops = {
> .ndo_open = i40e_open,
> .ndo_stop = i40e_close,
[ ... ]
> @@ -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.
> netdev->watchdog_timeo = 5 * HZ;
> i40e_set_ethtool_ops(netdev);
>
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260901211752.1922993-1-anthony.l.nguyen%40intel.com
next prev parent reply other threads:[~2026-09-04 9:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 21:17 [PATCH net-next 0/4][pull request] Intel Wired LAN Driver Updates 2026-09-01 (i40e) Tony Nguyen
2026-09-01 21:17 ` [PATCH net-next 1/4] i40e: prepare for XDP metadata ops support Tony Nguyen
2026-09-01 21:17 ` [PATCH net-next 2/4] i40e: add support for bpf_xdp_metadata_rx_hash() Tony Nguyen
2026-09-04 9:19 ` netdev-bot+sashiko [this message]
2026-09-01 21:17 ` [PATCH net-next 3/4] i40e: add support for bpf_xdp_metadata_rx_vlan_tag() Tony Nguyen
2026-09-01 21:17 ` [PATCH net-next 4/4] i40e: Avoid repeating RX filter warning Tony Nguyen
2026-09-04 9:19 ` netdev-bot+sashiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=178851359588.4131868.14209764775589320419@kernel.org \
--to=netdev-bot+sashiko@kernel.org \
--cc=aleksandr.loktionov@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=ast@kernel.org \
--cc=blair.steven@alliedtelesis.co.nz \
--cc=bpf@vger.kernel.org \
--cc=carl.smith@alliedtelesis.co.nz \
--cc=chris.packham@alliedtelesis.co.nz \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=enjuk@amazon.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=kohei.enju@gmail.com \
--cc=kuba@kernel.org \
--cc=maciej.fijalkowski@intel.com \
--cc=magnus.karlsson@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=sdf@fomichev.me \
--cc=sx.rinitha@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox