Re: [PATCH v2] xen/netfront: Fix TX response spurious interrupts

[Jakub Kicinski <kuba@xxxxxxxxxx>]

On Tue, 15 Jul 2025 16:11:29 +0000 Anthoine Bourgeois wrote:
> Fixes: b27d47950e48 ("xen/netfront: harden netfront against event channel 
> storms")

Not entirely sure who you expect to apply this patch, but if networking
then I wouldn't classify this is a fix. The "regression" happened 4
years ago. And this patch doesn't seem to be tuning the logic added by
the cited commit. I think this is an optimization, -next material, and
therefore there should be no Fixes tag here. You can refer to the commit
without the tag.

> @@ -849,9 +847,6 @@ static netdev_tx_t xennet_start_xmit(struct sk_buff *skb, 
> struct net_device *dev
>       tx_stats->packets++;
>       u64_stats_update_end(&tx_stats->syncp);
>  
> -     /* Note: It is not safe to access skb after xennet_tx_buf_gc()! */
> -     xennet_tx_buf_gc(queue);
> -
>       if (!netfront_tx_slot_available(queue))
>               netif_tx_stop_queue(netdev_get_tx_queue(dev, queue->id));

I thought normally reaping completions from the Tx path is done
to prevent the queue from filling up, when the device-generated
completions are slow or the queue is short. I say "normally" but
this is relatively a uncommon thing to do in networking.
Maybe it's my lack of Xen knowledge but it would be good to add to
the commit message why these calls where here in the first place.
-- 
pw-bot: cr