From my perspective, the older method does not work on newer chips :-)
It does work on tango4.
Agreed.
quoted
What does the tango5 do if you flood it with packets faster than the
kernel can keep up with? That would make it hit the end of the rx
chain, which is apparently what makes it miserable with the current dma
stop code.
The simplest way to test this would be sending tiny packets
as fast as possible, right? So ping -f on a GigE link should
fit the bill?
ping -f is limited to 100 packets per second. Use something like iperf
in UDP mode instead.
--
M?ns Rullg?rd
From: David Laight <hidden> Date: 2017-08-02 16:19:16
From: M?ns Rullg?rd
Sent: 02 August 2017 17:10
...
ping -f is limited to 100 packets per second. Use something like iperf
in UDP mode instead.
Or break a MAC driver so it just saturates the network.
You might actually need bursts of traffic - otherwise the receiver
will be continuously out of rx buffers and no dma will be active.
David
What does the tango5 do if you flood it with packets faster than the
kernel can keep up with? That would make it hit the end of the rx
chain, which is apparently what makes it miserable with the current dma
stop code.
The simplest way to test this would be sending tiny packets
as fast as possible, right? So ping -f on a GigE link should
fit the bill?
ping -f is limited to 100 packets per second. Use something like iperf
in UDP mode instead.
ping -f can go 100 times faster than 100 pps:
# ping -f -q -c 150000 -s 300 172.27.64.45
PING 172.27.64.45 (172.27.64.45) 300(328) bytes of data.
--- 172.27.64.45 ping statistics ---
150000 packets transmitted, 150000 received, 0% packet loss, time 15035ms
rtt min/avg/max/mdev = 0.065/0.084/0.537/0.014 ms, ipg/ewma 0.100/0.087 ms
150,000 packets in 15 seconds = 10,000 pps
(172.27.64.45 is the tango5 board)
Ergo, dealing with 10,000 packets per second does not hose RX.
Regards.
# iperf3 -c 172.27.64.45 -u -b 950M
Connecting to host 172.27.64.45, port 5201
[ 4] local 172.27.64.1 port 55533 connected to 172.27.64.45 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 102 MBytes 858 Mbits/sec 13091
[ 4] 1.00-2.00 sec 114 MBytes 953 Mbits/sec 14541
114 MB in 14541 packets => 7840 bytes per packet
Is iperf3 sending jumbo frames??
In the nb8800 driver, RX_BUF_SIZE is only 1552,
how would it deal with jumbo frames... truncate?
# iperf3 -c 172.27.64.45 -u -b 950M -l 800
Connecting to host 172.27.64.45, port 5201
[ 4] local 172.27.64.1 port 35197 connected to 172.27.64.45 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 90.6 MBytes 760 Mbits/sec 118724
[ 4] 1.00-2.00 sec 107 MBytes 894 Mbits/sec 139718
107 MB in 139718 packets => 766 bytes per packet
800 - 8 (UDP) - 20 (IPv4) = 772 bytes per packet
I suppose that's close enough...
772 * 139718 = 107.86 MB
I need to run the test slightly slower, to prevent
packet loss at the sender.
Perhaps -b 0 or -b 800M
Regards.