On Wed, 21 Jan 2026 16:24:11 +0800 Xuan Zhuo wrote:

+	napi_consume_skb(meta->skb, in_napi);

Please see cd18e8ac030e646. I was hoping AI code review would flag 
the issue in this patch with that kdoc in place but doesn't look like 
it worked :( Oh well, guessing machines..

+netdev_tx_t eea_tx_xmit(struct sk_buff *skb, struct net_device *netdev)
+{
+	const struct skb_shared_info *shinfo = skb_shinfo(skb);
+	struct eea_net *enet = netdev_priv(netdev);
+	int qnum = skb_get_queue_mapping(skb);
+	struct eea_net_tx *tx = &enet->tx[qnum];
+	struct netdev_queue *txq;
+	int err, n;
+
+	txq = netdev_get_tx_queue(netdev, qnum);
+
+	n = shinfo->nr_frags + 1;
+
+	if (!netif_txq_maybe_stop(txq, tx->ering->num_free, n, n)) {
+		/* maybe the previous skbs was xmitted without kick. */
+		eea_tx_kick(tx);
+		return NETDEV_TX_BUSY;
+	}
+
+	skb_tx_timestamp(skb);
+
+	err = eea_tx_post_skb(tx, skb);
+	if (unlikely(err))
+		dev_kfree_skb_any(skb);

You should try to stop the queue after submitting the skb if another
worst case packet won't fit on the ring. NETDEV_TX_BUSY is expensive
and bad for AQM.

+	if (!netdev_xmit_more() || netif_xmit_stopped(txq))
+		eea_tx_kick(tx);
+
+	return NETDEV_TX_OK;
+}

-- 
pw-bot: cr