[PATCH] dpaa2-eth: treat skb with exact headroom as scatter/gather frames

[Mathew McBride <matt@traverse.com.au>]

In commit f422abe3f23d ("dpaa2-eth: increase the needed headroom to
account for alignment"), the required skb headroom of dpaa2-eth was
increased to exactly 128 bytes. The headroom increase was to ensure
frames on the Tx path were always aligned to 64 bytes.

This caused a regression when vhost-net was used to accelerate virtual
machine frames between a KVM guest and a dpaa2-eth interface over a bridge.
While the skb passed to the driver had the required headroom (128 bytes),
the skb->head pointer did not match the alignment expected by the driver
(aligned_start => skb->head in dpaa2_eth_build_single_fd).

Treating outbound skb's where skb_headroom() == net_dev->needed_headroom
the same as skb's with inadequate headroom resolves this issue.

Signed-off-by: Mathew McBride <matt@traverse.com.au>
Fixes: f422abe3f23d ("dpaa2-eth: increase the needed headroom to account for alignment")
Closes: https://lore.kernel.org/netdev/70f0dcd9-1906-4d13-82df-7bbbbe7194c6@app.fastmail.com/T/#u
---
A while ago, changes were made to the dpaa2-eth driver to workaround
an issue when TX frames were not aligned to 64 bytes.

As part of this change, the required skb headroom in dpaa2-eth
was increased to 128 bytes.

When frames originating from a virtual machine over vhost-net
were forwarded to the dpaa2-eth driver for transmission,
the vhost frames were being dropped as they failed an alignment check.

The skb's originating from vhost-net had exactly the required headroom
(128 bytes).

I have tested a fix to the issue which treats frames with the "exact"
headroom the same as frames with inadequate headroom. These are
transmitted using the scatter/gather (S/G) process.

Network drivers are not my area of expertise so I cannot be 100%
confident this is the correct solution, however, I've done extensive
reliability testing on this fix to confirm it resolves the regression
involving vhost-net without any other side effects.

What I can't answer (yet) is if there are performance or other ramifcations
from having all VM-originating frames handled as S/G.

As far as I am aware, the virtual machine / vhost-net workload is the
only workload that generates skb's that require the S/G handling in
vhost-net. I have not seen any variants of this issue without vhost-net.

My original analysis of the problem can be found in the message below.
The diagnosis of the issue is still correct at the time of writing
(circa 6.18-rc1)

https://lore.kernel.org/netdev/70f0dcd9-1906-4d13-82df-7bbbbe7194c6@app.fastmail.com/T/#u
---
 drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
index c96d1d6ba8fe9..4eaf7cbec558d 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
@@ -1439,7 +1439,7 @@ static netdev_tx_t __dpaa2_eth_tx(struct sk_buff *skb,
 		percpu_extras->tx_sg_frames++;
 		percpu_extras->tx_sg_bytes += skb->len;
 		fd_len = dpaa2_fd_get_len(fd);
-	} else if (skb_headroom(skb) < needed_headroom) {
+	} else if (skb_headroom(skb) <= needed_headroom) {
 		err = dpaa2_eth_build_sg_fd_single_buf(priv, skb, fd, &swa);
 		percpu_extras->tx_sg_frames++;
 		percpu_extras->tx_sg_bytes += skb->len;

---
base-commit: 9b332cece987ee1790b2ed4c989e28162fa47860
change-id: 20251015-fix-dpaa2-vhost-net-3477be4e3ac9

Best regards,
-- 
Mathew McBride <matt@traverse.com.au>