Hello sunxi-community

I have a problem with Allwinner Ethernet, but I am not sure if this is the 
right community.

I try to keep it short, I can provide more infos, if somebody suggests, what 
may be useful

Hardware: FriendlyArm nanoPi Neo 2    Allwinner H5
OS: "Armbian" , Linux nanopineo2 4.14.15-sunxi64 #95 SMP Wed Jan 24 10:55:45 
CET 2018 aarch64 aarch64 aarch64 GNU/Linux

Problem: MTU setting on the Ethernet mac does not allow to receive large frames 

The device comes up with MTU 1500, and when revceiving larger packets, I get an 
error in dmesg. Fine, and as expected.

When I increase the MTU I see I can not go to 9000, but the maximum is 3582

eth0      Link encap:Ethernet  HWaddr 02:01:3b:9f:c7:2d  
         inet addr:192.168.17.77  Bcast:192.168.17.255  Mask:255.255.255.0
         inet6 addr: fe80::1:3bff:fe9f:c72d/64 Scope:Link
         UP BROADCAST RUNNING PROMISC MULTICAST  MTU:3582  Metric:1
         RX packets:107156 errors:11 dropped:64955 overruns:0 frame:11
         TX packets:5254 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000 
         RX bytes:181690239 (181.6 MB)  TX bytes:2129670 (2.1 MB)
         Interrupt:22

Ok, I am not a hardware/kernel guy, but from glancing at the H5 datasheet it 
seems the Mac has separated RX and TX Fifos and the TX is limited to 4k, so I 
guess it makes sense. Although RX buffer is larger. I think somewhere I read 
the maximum is configured in the Device tree somewhere? Could Linux/an Ethernet 
driver theoretically deal with the situation, where it can receive large 
frames, but only send smaller ones? (would solve my usecase)

However, the main problem is, even with the 3582 setting, the maximum length 
frames that actually can be received is much smaller

Works:

$ ping -s 1996 192.168.17.77
PING 192.168.17.77 (192.168.17.77) 1996(2024) bytes of data.
2004 bytes from 192.168.17.77: icmp_seq=1 ttl=64 time=0.663 ms
2004 bytes from 192.168.17.77: icmp_seq=2 ttl=64 time=0.388 ms

Doesn't work
$ ping -s 1997 192.168.17.77

(from a machine with mtu 9k, that definitely works with frames around 4k, so 
the sender is not the problem)

When this happens I do NOT get any length warning in dmesg or anything. The 
frames just never appears at the interface (checked with tcpdump)

This seems wrong. Can it be explained, or preferably :) fixed? Where would I 
need to dig deeper?

Thanks 

Sebastian

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to