Re: [PATCH 3/5] net: cadence: macb: implement EEE TX LPI support

["Théo Lebrun" <theo.lebrun@bootlin.com>]

On Thu Feb 26, 2026 at 11:49 AM CET, Nicolai Buchwitz wrote:
> On 26.2.2026 10:52, Théo Lebrun wrote:
>> On Wed Feb 25, 2026 at 6:50 PM CET, Russell King (Oracle) wrote:
>>> On Wed, Feb 25, 2026 at 06:42:08PM +0100, Théo Lebrun wrote:
>>>> On Wed Feb 25, 2026 at 10:15 AM CET, Nicolai Buchwitz wrote:
>>>> > @@ -2349,6 +2454,8 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
>>>> >  	netdev_tx_sent_queue(netdev_get_tx_queue(bp->dev, queue_index),
>>>> >  			     skb->len);
>>>> >
>>>> > +	macb_tx_lpi_wake(bp);
>>>> 
>>>> Should this be protected by a bp->eee_active condition? It could go
>>>> in macb_tx_lpi_wake(). We avoid a spinlock acquire per xmit for most
>>>> platforms. Probably negligeable though.
>>> 
>>> It will read the register, find the bit clear, and then return if
>>> EEE is already disabled.
>> 
>> Yes I agree with your sentence, sorry my point was unclear. I was not
>> describing a bug but rather a performance optimisation.
>> 
>> We would look up bp->eee_active to know if we can avoid calling
>> macb_tx_lpi_set(), to avoid grabbing bp->lock once per xmit.
>> That spinlock is interface-wide.
>
> So you're suggesting to revert to the v2 approach?
> https://patchwork.kernel.org/project/netdevbpf/patch/20260224091821.47671-4-nb@tipi-net.de/

I discovered this series at its V3.
It seems like I was suggesting a mix of both V2 & V3 approaches.

// V2 was:
static void macb_tx_lpi_wake(struct macb *bp)
{
	if (!bp->eee_active)
		return;

	macb_tx_lpi_set(bp, false);
	cancel_delayed_work(&bp->tx_lpi_work);
	udelay(50);
}

// V3 & V3 are:
static void macb_tx_lpi_wake(struct macb *bp)
{
	if (!macb_tx_lpi_set(bp, false))
		return;

	cancel_delayed_work(&bp->tx_lpi_work);
	udelay(50);
}

// I was suggesting:
static void macb_tx_lpi_wake(struct macb *bp)
{
	if (!eee_active || !macb_tx_lpi_set(bp, false))
		return;

	cancel_delayed_work(&bp->tx_lpi_work);
	udelay(50);
}

But talking about perf, let's measure.

I don't get any measurable performance improvement on average/max time
spent in macb_start_xmit() between net-next and this series. We spend
<3µs per call anyway. 10s iperf3 1G TCP test on EyeQ5, ftrace function
graph tracer on macb_start_xmit().

Summary: you can ignore my remark.

Thanks,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com