AGX Orin - mtu 1466

Autonomous Machines Jetson & Embedded Systems Jetson AGX Orin
1

Is this a bug or a feature?

Why is the default MTU on Orin set to 1466?
Why do I need to do some weird stuff to set it to 1500?

root@orin:~# ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1466
        inet 192.168.5.95  netmask 255.255.255.0  broadcast 192.168.5.255
        inet6 fe80::4ab0:2dff:fe69:4126  prefixlen 64  scopeid 0x20<link>
        ether 48:b0:2d:69:41:26  txqueuelen 1000  (Ethernet)
        RX packets 76  bytes 14899 (14.8 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 105  bytes 22817 (22.8 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
root@orin:~# ifconfig eth0 down
[  253.459976] Trying to unregister non-registered hwtime source
root@orin:~# ifconfig eth0 mtu 1500
root@orin:~# ifconfig eth0 up
root@orin:~# ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1466
        inet 192.168.5.95  netmask 255.255.255.0  broadcast 192.168.5.255
        inet6 fe80::4ab0:2dff:fe69:4126  prefixlen 64  scopeid 0x20<link>
        ether 48:b0:2d:69:41:26  txqueuelen 1000  (Ethernet)
        RX packets 76  bytes 14899 (14.8 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 105  bytes 22817 (22.8 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
root@orin:~# ifconfig eth0 down
[  463.366881] Trying to unregister non-registered hwtime source
root@orin:~# ifconfig eth0 mtu 1534
root@orin:~# ifconfig eth0 up
root@orin:~# ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.5.95  netmask 255.255.255.0  broadcast 192.168.5.255
        inet6 fe80::4ab0:2dff:fe69:4126  prefixlen 64  scopeid 0x20<link>
        ether 48:b0:2d:69:41:26  txqueuelen 1000  (Ethernet)
        RX packets 155  bytes 30295 (30.2 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 190  bytes 54210 (54.2 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
3

I will check with internal to see if can have the update, but any issue met with 1466 or you can try with 1500 directly to see if any impact.

4

Since the device runs IP routing, having MTU’s that don’t match may result unnecessary ip fragmentation and performance penalty.

I have also verified that with MTU 1466, the device can receive standard size frames, but is not able to send them, since the IP layer is informed otherwise.


19:35:53.585976 00:04:4b:e5:9d:57 > 48:b0:2d:69:41:26, ethertype IPv4 (0x0800), length 1514: 10.0.38.101 > 10.0.38.253: ICMP echo request, id 39, seq 1, length 1480
19:35:53.586222 48:b0:2d:69:41:26 > 00:04:4b:e5:9d:57, ethertype IPv4 (0x0800), length 1474: 10.0.38.253 > 10.0.38.101: ICMP echo reply, id 39, seq 1, length 1440
19:35:53.586278 48:b0:2d:69:41:26 > 00:04:4b:e5:9d:57, ethertype IPv4 (0x0800), length 74: 10.0.38.253 > 10.0.38.101: ip-proto-1

I am currently forcing MTU to 1534. In the short term, it seems to work, but need to do more testing.
It looks to me like the nvethernet driver is confused about the definition of MTU.

6

@kayccc, have you received any more information internally? Do you have any suggested actions we should take?

7

Is this issue solved?