RE: Empty ethernet frame after XDP_TX

"Panneman, J.J. (Jeffrey)" <jeffrey.panneman@xxxxxx> · Thu, 1 Jun 2017 11:38:33 +0000

Hi Andy,

Thanks for your quick response! When looking at the header I observe that the protocol is listed as '0x0000',  besides that the 'data field' in the Ethernet Frame is all 0s, but I think this is expected.
Maybe some more context for my setup as is is needed. Currently I have set up two network namespaces on my Ubuntu machine, the XDP example is then attached to the receiving side of my setup.
Before this I verify the routes are setup correctly using ping, this works as expected.
When the network is setup, I use 'nping' from the 'nmap' package, using the following settings:

nping $SERVER_IP --udp --source-ip $CLIENT_IP -p $TCPDUMP_PORT -g $TCPDUMP_PORT --data-length 1000 --rate 100 -c $NPING_SEND_COUNT --source-mac $CLIENT_MAC --dest-mac $SERVER_MAC

I have added the source and dest mac parameters in the hopes this would fix the problem, but the same behavior occurs when disregarding these parameters.
After I start the nping on the client side, I load the XDP program onto the receiving interface on the server side.  I added some ' bpf_trace_printk' statements to verify the program was reaching certain areas but besides this it is exactly the same example file. (xdp2)

The diff can be found below. For this experiment I ran my test using "-c 110", so 110 UDP packets should be sent using nping.
This is for the server (receiving side) interface: https://www.diffchecker.com/2HLX9Y5t
This is for the client (sending side) interface: https://www.diffchecker.com/TK7EncN5

In case the above links do not properly present the information I have included the output in the attachments.
If you need any other information I am happy to supply this, thank you for your time so far!

Kind regards,

Jeffrey Panneman

-----Original Message-----
From: xdp-newbies-owner@xxxxxxxxxxxxxxx [mailto:xdp-newbies-owner@xxxxxxxxxxxxxxx] On Behalf Of Andy Gospodarek
Sent: woensdag 31 mei 2017 18:34
To: Jeffrey Panneman <jeffrey.panneman@xxxxxxxxxxxxxx>
Cc: xdp-newbies@xxxxxxxxxxxxxxx
Subject: Re: Empty ethernet fram after XDP_TX

On Wed, May 31, 2017 at 5:29 AM, Jeffrey Panneman <jeffrey.panneman@xxxxxxxxxxxxxx> wrote:
> Hi all,
>
> I have recently started experimenting with XDP in regards to my master 
> thesis project. I have been playing around with some examples and had 
> a question regarding the following sample file from the linux kernel:
> https://github.com/torvalds/linux/blob/master/samples/bpf/xdp2_kern.c
>
> I have setup a test environment on which I can monitor both my source 
> and destination port using Wireshark. I observe that when I run the 
> example, always returning XDP_PASS, packets go on normal but the MAC 
> swapping does not occur. When using the XDP_TX return code after 
> swapping I observe that I see Ethernet frames appear in wireshark with 
> a source and destination 00:00:00:00:00:00. The IP related headers are 
> gone and this is the only thing I am seeing.

That is not what I would expect to see.  I've run numerous tests with
xdp2 on other hardware (Broadcom) and not seen this issue.  Are only the source and destination MAC addresses all zeros or are other parts of the ethernet header also zero?

> For some context, I am running on: 4.11.0-041100-generic x86_64 x86_64
> x86_64 GNU/Linux using ConnectX-4 Lx cards with the mlx5_core driver 
> (from lspci -v output). From "systool -vm" output I see my mlx5_core 
> version is "4.0-2.0.0"
>
> I was wondering if this behaviour was normal, and if anyone knows what 
> is going wrong here. I am happy to provide some more diagnostic 
> information if needed.

Can you send the diff of the ethtool stats (ethtool -S <netdev>) from before and after your XDP_TX test to see if anything stands out?

> Kind regards,
>
> Jeffrey
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.