[PATCH] net/ixgbe: fix repeated Rx packet buffer shrink for FDIR
Zhang Tengfei
zhtfdev at gmail.com
Fri Sep 25 20:59:50 CEST 2026
On 9/25/26 18:05, Burakov, Anatoly wrote:
> On 9/25/2026 11:47 AM, Burakov, Anatoly wrote:
>> A general comment: instead of reducing/bringing things back and
>
> I asked an AI to implement a fix based on this, and here's what it came
> up with, it is roughly what I would like to see instead (obviously,
> please review/rework as appropriate e.g. to properly support VMDq as well):
>
Hi Anatoly, Bruce,
Thanks for the review. Agreed, keeping the FDIR mode after the last rule
is gone
is wrong (a later rule with another mode fails with "Conflict with
existing fdir mode"). I'll drop the flag and do v2 along the lines of
the draft: RXPBSIZE(0) computed from the default size on enable,
restored on disable, and FDIR disabled on the configure error path and
when the first rule fails after FDIR was just enabled.
Unless you object, I plan to:
1. Use hw->mac.rx_pb_size as the default size (512 on 82599, 384 on
X540/X550/E610) instead of saving RXPBSIZE at init.
2. Leave VMDq out: ixgbe_fdir_configure() rejects all DCB mq modes, and
the non-DCB VMDq/SR-IOV paths don't write RXPBSIZE, so PB0 is the
only buffer whenever FDIR can be enabled.
3. Not address the fact that FDIR enable/disable from the flow API
changes RXPBSIZE/FDIRCTRL while Rx is enabled if the port is
started. Enabling on the first rule already works this way today;
restoring the buffer on the last rule removal adds the disable side.
dev_start only touches these registers with Rx disabled.
I'll send v2 rebased on next-net-intel in the next few days.
Thanks
More information about the stable
mailing list