cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
SaberLuther
Newbie
Newbie
454 Views
Registered: ‎06-03-2021

Lost multicast packets when I use Solarflare XtremeScale X2522-25G Adapter to receive udp packets

Hi,

I use solarflare X2522-25G Adapter to receive udp multicast packets from fpga by onload.

I always find packet loss. For example, lost about 200 packets when I try to receive 800,000 packets.

I guess the main reason is network adapter buffer overflow.

And I try to increass buffer when I execute our program as following.  Unfortunately, it doesn't work. 

Now, I am wondering what can I do to make sure no packets lost?

 

ps:

I use to crontab to execute our program.

#!/bin/sh
DIR="/root/receive_quote/"

cd ${DIR}
export EF_RXQ_SIZE=4096
export EF_UDP_RCVBUF=1638400
export EF_MAX_PACKETS=19660800
onload -p latency taskset -c 12,13 ./rx_multicast_packets

 

 

Tags (1)
0 Kudos
3 Replies
abrunnin
Xilinx Employee
Xilinx Employee
431 Views
Registered: ‎03-31-2020

Hi.

 

There really isn't enough information there for us to diagnose a cause for drops.

Basic system tuning advice can be found in our user guides.  But to give a better analysis we would need to see the output from "onload_stackdump lots" taken after some drops are seen, but before the application exits to see if there are any drops in Onload at the socket level.

The output from "sfreport" taken after the drops are seen (available in our diagnostics package, from https://support-nic.xilinx.com/ ) would also help, as it would let us check for drops at the interface.

 

0 Kudos
SaberLuther
Newbie
Newbie
370 Views
Registered: ‎06-03-2021

I run the application again from 14:00 to 15:00. I still found there was 134 packets lost(the totoal number packets are 375255, the application received 375121, so lost 134 packets).

there are no drops in Onload at the socket level. By the way, I allocated 512 * 1024 * 1024 byte memory for the application

I attached  the "onload_stackdump lots" and "sfreport" to the attachment. 

I really hope to get your answer, thank you very much.

0 Kudos
abrunnin
Xilinx Employee
Xilinx Employee
362 Views
Registered: ‎03-31-2020

For analysis, you'd be better off raising a support ticket (via https://support-nic.xilinx.com/ )

But at a quick look: 

The stackdump looks OK.  350k packets received, no drops within Onload itself.

The sfreport ALSO shows no drops (at the interface).  So it looks like any drops are elsewhere.

 

Are you able to categorise the missing multicast?  Is it, for example, relatively long periods of no multicast arriving for a given group (which might indicate a problem with the switch losing IGMP group membership  and stopping forwarding that group to the host).

Do you see these missing packets when you tap the switch?

 

One slightly strange thing is the stack having quite a lot of interrupts despite being configured for spinning.  This suggests that the application quite often sleeps for longer than the poll time you have set.

This does not appear to be causing any issues, but does seem worth noting, and checking if it is intentional.

0 Kudos