You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a simple client that sends a single packet to the AF_XDP example application (l2fwd), waits for it to return, and then sends another one in forever while loop. This client only measures the latency of the packet going throughout the AF_XDP stack.
Unfortunately, l2fwd example does not echo packets back when it operates in the zero-cpy mode (-z). It only works when poll mode (-p) is enabled. This is while the copy mode (-c) works regardless seamlessly. Also, the zero-cpy mode would work if you endlessly send packets (flooding the application). However, closed-loop experiments seem to be problematic.
I wonder why this is the case. I am expecting to work regardless. I also tested this on two different NICs (ConnectX6 and ConnectX4) and also on two different kernel versions. This seems to be a problem with the application logic. Unfortunately, it is quite tricky to understand where the problem can be. I have some rough guesses (I suspect there wouldn't be enough descriptors for the kernel to use and send a packet over the wire.)
Thanks
The text was updated successfully, but these errors were encountered:
sarsanaee
changed the title
Problem with latency test in AF_XDP-example
Problem with AF_XDP-example app.
Apr 25, 2024
The last time I ran this with a single package on an Intel NIC, this worked. So I would start with checking if it is a Mellanox zero-copy driver problem. Do you have another card you can try with that is not a Mellanox card since both your cards use the same driver, I believe?
Hi
I have a simple client that sends a single packet to the AF_XDP example application (l2fwd), waits for it to return, and then sends another one in forever while loop. This client only measures the latency of the packet going throughout the AF_XDP stack.
Unfortunately, l2fwd example does not echo packets back when it operates in the zero-cpy mode (-z). It only works when poll mode (-p) is enabled. This is while the copy mode (-c) works regardless seamlessly. Also, the zero-cpy mode would work if you endlessly send packets (flooding the application). However, closed-loop experiments seem to be problematic.
I wonder why this is the case. I am expecting to work regardless. I also tested this on two different NICs (ConnectX6 and ConnectX4) and also on two different kernel versions. This seems to be a problem with the application logic. Unfortunately, it is quite tricky to understand where the problem can be. I have some rough guesses (I suspect there wouldn't be enough descriptors for the kernel to use and send a packet over the wire.)
Thanks
The text was updated successfully, but these errors were encountered: