public inbox for dev@dpdk.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Xavier Guillaume <xavier.guillaume@ovhcloud.com>
Cc: <dev@dpdk.org>, <stable@dpdk.org>
Subject: Re: [PATCH v2 0/3] net/af_packet: fix MTU handling and add jumbo frame support
Date: Mon, 9 Mar 2026 18:55:09 -0700	[thread overview]
Message-ID: <20260309185509.194f38a6@phoenix.local> (raw)
In-Reply-To: <20260309161021.2790684-1-xavier.guillaume@ovhcloud.com>

On Mon, 9 Mar 2026 17:10:18 +0100
Xavier Guillaume <xavier.guillaume@ovhcloud.com> wrote:

> This series fixes two bugs in the af_packet PMD related to frame
> size calculations and buffer safety, then enables jumbo frame
> support by deriving the advertised capabilities from the actual
> TPACKET ring configuration.
> 
> Patch 1 fixes the data size calculation in eth_dev_mtu_set() which
> is too restrictive due to TPACKET2_HDRLEN including sizeof(struct
> sockaddr_ll) even though the sockaddr_ll does not consume frame
> data space. The formula is now consistent with the RX and TX paths.
> 
> Patch 2 adds a bounds check in the RX path to prevent a heap buffer
> overflow when the kernel delivers a packet larger than the mbuf data
> room (e.g. if the kernel interface MTU is raised externally).
> 
> Patch 3 replaces the static max_rx_pktlen (RTE_ETHER_MAX_LEN) and
> adds max_mtu, both derived from the configured TPACKET frame size.
> This enables jumbo frame support when the user specifies a larger
> framesz devarg at vdev creation time.
> 
> v2:
>   - patch 2/3: fix Fixes tag to use 12-char SHA (checkpatch warning)
> 
> Xavier Guillaume (3):
>   net/af_packet: fix MTU set data size calculation
>   net/af_packet: fix receive buffer overflow
>   net/af_packet: support jumbo frames
> 
>  drivers/net/af_packet/rte_eth_af_packet.c | 17 +++++++++++++++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 

Looks good to me, so sent AI off to look at the fine details around MTU.
The one observation from me is that the new check for data_size is redundnt
and should be removed or turned into RTE_ASSERT()

**Patch 1/3 - fix MTU set data size calculation**

The sockaddr_ll fix is correct. The formula now matches the Rx and Tx
queue setup paths. Good commit message explaining the TPACKET2_HDRLEN
decomposition.

Minor: now that patch 3 reports max_mtu correctly, the ethdev layer
validates mtu <= max_mtu before calling the PMD callback
(eth_dev_validate_mtu in rte_ethdev.c). The data_size check here
becomes redundant dead code. Consider removing it to keep the driver
simple and avoid confusing future readers.

**Patch 2/3 - fix receive buffer overflow**

Good catch. Real buffer overflow when kernel MTU is raised externally
past the TPACKET ring capacity. The tailroom check, frame return to
kernel, and dropped counter are all correct.

**Patch 3/3 - support jumbo frames**

The max_rx_pktlen and max_mtu derivation from the actual TPACKET ring
frame size is correct and consistent with the data_size formula in
patches 1 and 2.

  parent reply	other threads:[~2026-03-10  1:55 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-06  9:20 [PATCH v1 0/3] net/af_packet: fix MTU handling and add jumbo frame support Xavier Guillaume
2026-03-06  9:20 ` [PATCH v1 1/3] net/af_packet: fix MTU set data size calculation Xavier Guillaume
2026-03-06  9:20 ` [PATCH v1 2/3] net/af_packet: fix receive buffer overflow Xavier Guillaume
2026-03-06  9:20 ` [PATCH v1 3/3] net/af_packet: support jumbo frames Xavier Guillaume
2026-03-09 16:03   ` Stephen Hemminger
2026-03-09 16:10 ` [PATCH v2 0/3] net/af_packet: fix MTU handling and add jumbo frame support Xavier Guillaume
2026-03-09 16:10   ` [PATCH v2 1/3] net/af_packet: fix MTU set data size calculation Xavier Guillaume
2026-03-09 16:10   ` [PATCH v2 2/3] net/af_packet: fix receive buffer overflow Xavier Guillaume
2026-03-09 16:10   ` [PATCH v2 3/3] net/af_packet: support jumbo frames Xavier Guillaume
2026-03-10 23:31     ` Stephen Hemminger
2026-03-12 13:32       ` Xavier Guillaume
2026-03-12 16:20         ` Stephen Hemminger
2026-03-09 20:16   ` [PATCH v2 0/3] net/af_packet: fix MTU handling and add jumbo frame support Stephen Hemminger
2026-03-09 20:49   ` [PATCH] net/af_packet: add multi-segment mbuf support for jumbo frames Sriram Yagnaraman
2026-03-09 21:02     ` [PATCH v2] " Sriram Yagnaraman
2026-03-10 14:02       ` Stephen Hemminger
2026-03-10 20:02         ` Sriram Yagnaraman
2026-03-16 16:02           ` Stephen Hemminger
2026-03-19  9:25             ` Sriram Yagnaraman
2026-03-10  1:55   ` Stephen Hemminger [this message]
2026-03-10 11:21   ` [PATCH v3 0/3] net/af_packet: fix MTU handling and add jumbo frame support Xavier Guillaume
2026-03-10 11:21     ` [PATCH v3 1/3] net/af_packet: fix MTU set data size calculation Xavier Guillaume
2026-03-10 11:21     ` [PATCH v3 2/3] net/af_packet: fix receive buffer overflow Xavier Guillaume
2026-03-10 11:21     ` [PATCH v3 3/3] net/af_packet: support jumbo frames Xavier Guillaume
2026-03-11 16:03     ` [PATCH v3 0/3] net/af_packet: fix MTU handling and add jumbo frame support Stephen Hemminger
2026-03-12 18:46     ` Stephen Hemminger
2026-03-16 15:59     ` Stephen Hemminger

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=20260309185509.194f38a6@phoenix.local \
    --to=stephen@networkplumber.org \
    --cc=dev@dpdk.org \
    --cc=stable@dpdk.org \
    --cc=xavier.guillaume@ovhcloud.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