Re: [PATCH net-next v2] net: fec: support RX flushing via an ethtool private flag

[Jakub Kicinski]

On Tue,  1 Sep 2026 09:47:29 +0200 A. Sverdlin wrote:
> The FEC controller can flush the RX FIFO of an individual receive queue
> through the RX_FLUSHn bits of the FEC_QOS_SCHEME (ENET_QOS) register.
> 
> RX flushing prevents frames in the RX FIFO from being blocked. Blocking
> can occur when the frame at the head of the RX FIFO cannot be forwarded
> because the ring it is associated with cannot accept it, i.e. when the
> ring's RxBD[EMPTY] is not set or ENET_RDARn is not set. When RX flushing
> is enabled for a ring, such a blocking frame is flushed (discarded)
> instead of stalling the FIFO and holding up the other rings.
> 
> Expose this per-queue capability as a runtime ethtool private flag
> ("rx-flush-qN").
> 
> Due to erratum ERR050395 (observed e.g. on i.MX8QXP), enabling RX flushing
> on more than one queue at a time can lock up the receive path, so only a
> single queue may have flushing enabled.
> 
> According to i.MX8QXP Reference Manual, "when both class 1 and class 2 are
> disabled, RX flushing for these rings must also be disabled". Both RX and
> TX QoS classes are enabled via DMA_CLASS_EN bit, currently tied to
> num_tx_queues in the driver. Currently there are no constraints on
> num_tx_queues == num_rx_queues, neither in DT nor in the code, even though
> having different values doesn't make much sense even without RX flushing.
> RX flushing code just takes min() of the both values for now.

For the errata - how is the user supposed to pick a queue?
The documentation talks a lot about device specific terms instead of
using generic easily understood terms. IOW it reads like slop.

In general AFAIU the flushing should be enabled in tandem with pause
frames right now. It'd be great if we can stick to that, or failing
that add a generic config knob rather than private flags.
There's nothing private about the drop decision when host ring is empty