Re: [PATCH v4 net 0/8] Fix short frame transmission in enetc

[Vladimir Oltean]

On Thu, Oct 15, 2026 at 01:55:28PM +0300, vladimir.oltean@xxxxxxx wrote:
> This is a belated follow-up to Zefir Kurtisi's report:
> https://lore.kernel.org/netdev/20260220132930.2521155-1-zefir.kurtisi@xxxxxxxxx/
> 
> which is that the ENETC misbehaves when transmitting packets smaller
> than 16 octets sans FCS: it sends them but does not update the completed
> index in the transmit BD ring. I did find a sentence in the reference
> manual explicitly stating these short frames are not supported.
> 
> The original series was focused on handling the invalid frame
> geometries (now patches 4, 5 and 6). However, review pointed out further
> issues in annex code. The other patches handle those.
> 
> v1 at:
> https://lore.kernel.org/netdev/20260401172246.1075883-1-vladimir.oltean@xxxxxxx/
> 
> v2 at:
> https://lore.kernel.org/netdev/20260406204122.167237-1-vladimir.oltean@xxxxxxx/
> 
> v3 at:
> https://lore.kernel.org/netdev/20260915222735.1016937-5-vladimir.oltean@xxxxxxx/
> 
> Change log in individual patches. At a high level:
> - applied feedback from Wei Fang, David Laight and Sashiko
> - dropped "[PATCH v3 net 7/7] net: enetc: drain and cancel one-step TX
>   tstamp queue when going down" because addressing Sashiko's feedback
>   would grow this series to a point where it would become impossible to
>   make any progress; plus it becomes more and more unrelated to the main
>   objective. Will address that part separately.
> - dropped "[PATCH v3 net 6/7] net: enetc: linearize PTP event packets
>   with one-step TX timestamping"; also unrelated to short frames, will
>   resubmit separately.
> - split v3's "pad short frames in software" into patch 4 (do not rely on
>   mEMAC hardware frame padding) and patch 5 (ensure head buffer has at
>   least 16 octets).
> - reworked v3's "pad short XDP frames coming from devmap": instead of
>   padding the xdp_frame in place through a new generic xdp_frame_pad()
>   helper (which only covered ndo_xdp_xmit()), patch 6 now pads in the
>   driver using the shared tx_pad buffer, covering the XDP_TX path too.
>   Consequently, there is no longer a change to include/net/xdp.h, so the
>   BPF/XDP folks are no longer CCed.
> - new patches:
>   - 2/8: serialize access to the same TX ring from NAPI XDP_TX and
>     ndo_xdp_xmit()
>   - 7/8: fix leak of pending XDP_TX frames when going down
> 
> Vladimir Oltean (8):
>   net: enetc: consistently track dropped frames in enetc_xdp_xmit()
>   net: enetc: serialize access to the same TX ring from NAPI XDP_TX and
>     ndo_xdp_xmit()
>   net: enetc: fix bogus TX ring consumer index after reinitialization
>   net: enetc: do not rely on mEMAC hardware frame padding
>   net: enetc: ensure head buffer has at least 16 octets
>   net: enetc: pad short XDP frames in software
>   net: enetc: fix leak of pending XDP_TX frames when going down
>   net: enetc: ensure enetc_xdp_xmit() calls enetc_update_tx_ring_tail()
> 
>  drivers/net/ethernet/freescale/enetc/enetc.c | 160 ++++++++++++++++---
>  drivers/net/ethernet/freescale/enetc/enetc.h |  12 ++
>  2 files changed, 148 insertions(+), 24 deletions(-)
> 
> -- 
> 2.43.0
>

In short:

pw-bot: cr

I've received a rainfall of AI review from the Sashiko bot, on some
emails netdev was copied, on some it was not. Some of the feedback is
valid (a lot is duplicated, and that makes up a lot of the noise), and
that valid feedback falls into one of 2 categories:
- in scope for this patch set
- out of scope for this patch set

I can't humanly respond to all that verbiage, sorry.

Because I want to get this issue resolved ASAP, I will trim v5 to just 4
patches, which touch only what is strictly in scope, and will defer the
rest of the feedback to other patch sets to follow.