[T1042]: Frames being dropped when packet size greater than 25152

[alis1]

Hello,

We decided to upgrade the Linux kernel of our ppc64 product from 3.12.19 to 4.14 using sources taken from Freescale/linux-fscl repository:

https://github.com/Freescale/linux-fslc/tree/4.14.x+fslc

Communication works only partially i.e. packets bigger than certain size do not come through:

ping 10.12.50.122 -s 25153
PING 10.12.50.122 (10.12.50.122) 25153(25181) bytes of data.
--- 10.12.50.122 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6144ms

While adjusting device tree I used example .dts files from linux-fslc and made sure that reserved-memory node is present in order to satisfy driver's external memory requirements.

reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;

bman_fbpr: bman-fbpr {
size = <0 0x1000000>;
alignment = <0 0x1000000>;
};
qman_fqd: qman-fqd {
size = <0 0x400000>;
alignment = <0 0x400000>;
};
qman_pfdr: qman-pfdr {
size = <0 0x2000000>;
alignment = <0 0x2000000>;
};
};

I also increased FSL_FM_MAX_FRAME_SIZE from 1522 to 1550 because initially even smaller packets were not reaching the destination. Increasing that value helped, but only partially. Further increasing the MTU does not change the behavior.

I added some logs so I can verify on how many fragments packet is fragmented and with smaller values, the number of fragments is OK (packet size/MTU). For bigger packets I can see a really big burst of fragments and then ICMP request stop showing up (I can verify if packet type == ICMP using sk_buff 'type' field which is 8 for ICMP request) 

Also, even when I do not ping, some packets are constantly being dropped on the eth1 interface 

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1528
inet6 fe80::280:eaff:feb0:2952 prefixlen 64 scopeid 0x20<link>
ether 00:80:ea:b0:29:52 txqueuelen 1000 (Ethernet)
RX packets 349813 bytes 37890813 (36.1 MiB)
RX errors 0 dropped 71985 overruns 0 frame 0
TX packets 228585 bytes 27237102 (25.9 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0xffe4e4000-ffe4e4fff

I added some debug logs and noticed that in the latter case rx_dropped counter is increased in dpaa_eth.c in 

function named rx_default_dqrr after calling netif_receive_skb(skb), which goes deep into Linux network internals:
__netif_receive_skb_core, then ip_rcv_finish

Can you help with this?

Arkadiusz Lis

[bpe]

T1040/42 DPAA supports Jumbo frames of up to 9.6K octets - see
T1040DPAARM, Section 1.5.3.1. Setting MTU to the value in the
Subject is not guaranteed to work properly. There are two kernel
configuration options related to Jumbo frames handling, visit the
links below for details:

https://nxp.sdlproducts.com/LiveContent/content/en-US/LSDKUG_Rev19.06/GUID-42C25C64-5B62-4EF7-8372-E...

https://nxp.sdlproducts.com/LiveContent/content/en-US/LSDKUG_Rev19.06/GUID-23BA17B4-170B-40D9-B4DF-9...

Note that DPAA Linux Ethernet driver is only responsible for transferring
frames that are below the MTU in size, which can be maximum 9.6K
octets as explained above. For any packets larger than MTU,
fragmentation is done by the generic Linux IP stack which is not NXP
maintained code.

Have a great day,
Platon

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------