Jumbo frame support on Pi4 ethernet (Genet) #5561
Assignees
Comments
|
I reviewed the old records I compiled during migration from 5.4 to 5.10. My first test is against kernel 5.10.17 and on the same hardware. The following code sends packets slightly above 4K to show the corruption problem. # only temporarily increase mtu, avoids losing headless connection
sudo ip link set dev eth0 mtu 8000
sudo ethtool -K eth0 tx on
#
# wireshark receives this udp packet with 2 nonzero bytes at 0x1028
dd if=/dev/zero bs=4100 count=1 |netcat -u 169.254.1.1 65000 -q 1
#
# icmp is not affected
ping 169.254.1.1 -c 1 -M do -v -s 4100 -p 0
#
# now repeat without crc offload
sudo ethtool -K eth0 tx off
#
# wireshark receives this udp packet with all zeros as expected
dd if=/dev/zero bs=4100 count=1 |netcat -u 169.254.1.1 65000 -q 1
#
# icmp is not affected
ping 169.254.1.1 -c 1 -M do -v -s 4100 -p 0
#
# back to surely stable state
sudo ip link set dev eth0 mtu 1500My stress test goes like this: for ((MTU=8192; MTU>2000; ((MTU=MTU-4)) )) do sudo ifconfig eth0 mtu ${MTU} ; ifconfig eth0 ; dd if=/dev/zero bs=65536 count=10 |netcat -u 169.254.1.1 65000 -q 1; doneeth0 freezes as soon as the last packet of the fragments reach approx. 2K and I see the well known time-out with Next steps:
|
|
The freeze occurs also on my CM4. Steps to reproduce: sudo ip link set dev eth0 mtu 2036
while (true) do dd if=/dev/zero bs=65536 count=1000 |netcat -u 169.254.1.1 65000 -q 0; done
Log message: Info Could increasing TBUF_TXCHK_PKTRDY_THLD (name taken from #5419 (comment)) be of any help? What is its address? |
|
I can confirm, that incoming jumbo packets are not fragmented into multiple buffers. This observation does not agree with my old records. I believe that I made mistakes interpreting the log messages in the past. Using a similar patch like #5419 (comment) and code like this for ((SIZE=3700; SIZE<3900; ((SIZE=SIZE+1)) )) do ping 169.254.1.1 -c 1 -v -s ${SIZE}; doneI see the following log: Packet length from register is 64 bytes larger then I would expect in case of length exceeding threshold. |
|
Well, I guess TBUF_PKT_RDY_THLD is at 0x10. This test triggers the time out/freeze at mtu = 2036: for ((MTU=1500; MTU<=3840; ((MTU=MTU+4)))) do sudo ifconfig eth0 mtu ${MTU} ; ip -d link list eth0 ; dd if=/dev/zero bs=65536 count=1024 |netcat -u 169.254.1.1 65000 -q 0; doneThe following patch pushes that limit by 0x70*16 = 1792 to 3828. So I can safely use mtu = 3824 now. Date: Mon, 7 Aug 2023 15:15:18 +0200
Subject: net: bcm: genet: Set the TBUF_PKT_RDY_THLD register
Set the TBUF_PKT_RDY_THLD register to the max value that it can
take to allow for larger frames. Allows for mtu up to 3824.
Signed-off-by: wtschueller <wtschueller@users.noreply.github.com>
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index 9749d6678..4a6038b7c 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -2502,6 +2502,7 @@ static void init_umac(struct bcmgenet_priv *priv)
*/
reg = 0xf0;
bcmgenet_rbuf_writel(priv, reg, RBUF_PKT_RDY_THLD);
+ bcmgenet_writel(reg, priv->base + priv->hw_params->tbuf_offset + TBUF_PKT_RDY_THLD);
/* enable rx checksumming */
reg = bcmgenet_rbuf_readl(priv, RBUF_CHK_CTRL);
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.h b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
index 52068d8bf..d470364ca 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.h
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
@@ -283,6 +283,8 @@ struct bcmgenet_mib_counters {
#define TBUF_EEE_EN (1 << 0)
#define TBUF_PM_EN (1 << 1)
+#define TBUF_PKT_RDY_THLD 0x10
+
#define TBUF_CTRL_V1 0x80
#define TBUF_BP_MC_V1 0xA0 |
|
Same behaviour for kernel 5.15.61, RPi4 and CM4. |
|
Any news? |
|
This feature would be great |
|
I've just pinged the thread on net-dev to see if Florian ever found any docs. I'm afraid it's a fairly low priority all round. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
From #5419 (closed PR) where someone had proposed a total hack to increase the max packet length.
Queried on net-dev
https://www.spinics.net/lists/netdev/msg919558.html
https://www.spinics.net/lists/netdev/msg925029.html
So Florian is going to have a little look into it.
Opening new issue to track anything that comes back from it.
Steps to reproduce the behaviour
Current max packet size only allows standard ethernet 1500 byte MTU (+ VLAN headers).
Device (s)
Raspberry Pi 4 Mod. B, Raspberry Pi 400, Raspberry Pi CM4, Raspberry Pi CM4 Lite
System
All kernels to current (6.5)
Logs
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: