All of lore.kernel.org
 help / color / mirror / Atom feed
* Intel X520 looses ethtool flow-type rule the moment a BPF / XDP program is loaded
@ 2020-06-05 11:17 Gaul, Maximilian
  2020-06-05 11:57 ` Magnus Karlsson
  0 siblings, 1 reply; 6+ messages in thread
From: Gaul, Maximilian @ 2020-06-05 11:17 UTC (permalink / raw)
  To: Xdp

Hello,

I have an Intel X520 10Gbit/s NIC with driver:

		$ sudo ethtool -i eth5
		driver: ixgbe
		version: 5.7.1
		firmware-version: 0x80000827, 16.5.19
		expansion-rom-version: 
		bus-info: 0000:04:00.1
		supports-statistics: yes
		supports-test: yes
		supports-eeprom-access: yes
		supports-register-dump: yes
		supports-priv-flags: yes

and Kernel:

		$ uname -a
		Linux 5.6.0-2-amd64

I tried this tutorial before hand: https://software.intel.com/content/www/us/en/develop/articles/setting-up-intel-ethernet-flow-director.html

Unfortunately I am experiencing some strange behavior in combination with AF_XDP.

For example, I am adding an ethtool flow-type rule like this:

		$ sudo ethtool -N eth5 flow-type udp4 dst-ip 239.0.1.1 dst-port 5500 action 0
		Added rule with ID 4093

Checking it is there:

		$ sudo ethtool -n eth5
		16 RX rings available
		Total 1 rules

		Filter: 4093
				Rule Type: UDP over IPv4
				Src IP addr: 0.0.0.0 mask: 255.255.255.255
				Dest IP addr: 239.0.1.1 mask: 0.0.0.0
				TOS: 0x0 mask: 0xff
				Src port: 0 mask: 0xffff
				Dest port: 5500 mask: 0x0
				VLAN EtherType: 0x0 mask: 0xffff
				VLAN: 0x0 mask: 0xffff
				User-defined: 0x0 mask: 0xffffffffffffffff
				Action: Direct to queue 0

After that I am launching my AF_XDP program which firsts loads a compiled BPF-object file into the kernel (without any errors).
I am checking ethtool again:

		$ sudo ethtool -n eth5
		16 RX rings available
		Total 0 rules

Any ideas why that is? I am not saying that my program is bug-free but it worked fine in combination with Mellannox ConnectX5 and Broadcom 1Gbit/s NIC (without zcopy on the broadcom though).

Thank you

Max

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Intel X520 looses ethtool flow-type rule the moment a BPF / XDP program is loaded
  2020-06-05 11:17 Intel X520 looses ethtool flow-type rule the moment a BPF / XDP program is loaded Gaul, Maximilian
@ 2020-06-05 11:57 ` Magnus Karlsson
  2020-06-05 12:05   ` AW: " Gaul, Maximilian
  0 siblings, 1 reply; 6+ messages in thread
From: Magnus Karlsson @ 2020-06-05 11:57 UTC (permalink / raw)
  To: Gaul, Maximilian; +Cc: Xdp

On Fri, Jun 5, 2020 at 1:18 PM Gaul, Maximilian <maximilian.gaul@hm.edu> wrote:
>
> Hello,
>
> I have an Intel X520 10Gbit/s NIC with driver:
>
>                 $ sudo ethtool -i eth5
>                 driver: ixgbe
>                 version: 5.7.1
>                 firmware-version: 0x80000827, 16.5.19
>                 expansion-rom-version:
>                 bus-info: 0000:04:00.1
>                 supports-statistics: yes
>                 supports-test: yes
>                 supports-eeprom-access: yes
>                 supports-register-dump: yes
>                 supports-priv-flags: yes
>
> and Kernel:
>
>                 $ uname -a
>                 Linux 5.6.0-2-amd64
>
> I tried this tutorial before hand: https://software.intel.com/content/www/us/en/develop/articles/setting-up-intel-ethernet-flow-director.html
>
> Unfortunately I am experiencing some strange behavior in combination with AF_XDP.
>
> For example, I am adding an ethtool flow-type rule like this:
>
>                 $ sudo ethtool -N eth5 flow-type udp4 dst-ip 239.0.1.1 dst-port 5500 action 0
>                 Added rule with ID 4093
>
> Checking it is there:
>
>                 $ sudo ethtool -n eth5
>                 16 RX rings available
>                 Total 1 rules
>
>                 Filter: 4093
>                                 Rule Type: UDP over IPv4
>                                 Src IP addr: 0.0.0.0 mask: 255.255.255.255
>                                 Dest IP addr: 239.0.1.1 mask: 0.0.0.0
>                                 TOS: 0x0 mask: 0xff
>                                 Src port: 0 mask: 0xffff
>                                 Dest port: 5500 mask: 0x0
>                                 VLAN EtherType: 0x0 mask: 0xffff
>                                 VLAN: 0x0 mask: 0xffff
>                                 User-defined: 0x0 mask: 0xffffffffffffffff
>                                 Action: Direct to queue 0
>
> After that I am launching my AF_XDP program which firsts loads a compiled BPF-object file into the kernel (without any errors).
> I am checking ethtool again:
>
>                 $ sudo ethtool -n eth5
>                 16 RX rings available
>                 Total 0 rules
>
> Any ideas why that is? I am not saying that my program is bug-free but it worked fine in combination with Mellannox ConnectX5 and Broadcom 1Gbit/s NIC (without zcopy on the broadcom though).

Max,

This is unfortunately a known issue with this older NIC. The newer
Intel NICs such as i40e (Fortville) and ice (Columbiaville) work as
you would expect. They do remember filter settings after enabling XDP.

/Magnus

> Thank you
>
> Max

^ permalink raw reply	[flat|nested] 6+ messages in thread

* AW: Intel X520 looses ethtool flow-type rule the moment a BPF / XDP program is loaded
  2020-06-05 11:57 ` Magnus Karlsson
@ 2020-06-05 12:05   ` Gaul, Maximilian
  2020-06-05 12:15     ` Magnus Karlsson
  0 siblings, 1 reply; 6+ messages in thread
From: Gaul, Maximilian @ 2020-06-05 12:05 UTC (permalink / raw)
  To: Magnus Karlsson; +Cc: Xdp

> Max,
> 
> This is unfortunately a known issue with this older NIC. The newer
> Intel NICs such as i40e (Fortville) and ice (Columbiaville) work as
> you would expect. They do remember filter settings after enabling XDP.
> 
> /Magnus
> 

Thank you for your reply Magnus.

That is unfortunate but looks like I am not able to change anything about it.

Do you know if there are other problems with AF_XDP and that NIC?

For example, I am adding a multicast address membership to a generic Linux socket and then loading a BPF / XDP program.

After loading the BPF program I no longer receive any packets (tcpdump -i eth5).

Thank you

Max

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Intel X520 looses ethtool flow-type rule the moment a BPF / XDP program is loaded
  2020-06-05 12:05   ` AW: " Gaul, Maximilian
@ 2020-06-05 12:15     ` Magnus Karlsson
  2020-06-05 12:25       ` AW: " Gaul, Maximilian
  0 siblings, 1 reply; 6+ messages in thread
From: Magnus Karlsson @ 2020-06-05 12:15 UTC (permalink / raw)
  To: Gaul, Maximilian, Raczynski, Piotr, Fijalkowski, Maciej, lihong.yang; +Cc: Xdp

On Fri, Jun 5, 2020 at 2:05 PM Gaul, Maximilian <maximilian.gaul@hm.edu> wrote:
>
> > Max,
> >
> > This is unfortunately a known issue with this older NIC. The newer
> > Intel NICs such as i40e (Fortville) and ice (Columbiaville) work as
> > you would expect. They do remember filter settings after enabling XDP.
> >
> > /Magnus
> >
>
> Thank you for your reply Magnus.
>
> That is unfortunate but looks like I am not able to change anything about it.
>
> Do you know if there are other problems with AF_XDP and that NIC?
>
> For example, I am adding a multicast address membership to a generic Linux socket and then loading a BPF / XDP program.
>
> After loading the BPF program I no longer receive any packets (tcpdump -i eth5).

I do not use this card in my AF_XDP lab setup, so unforuately I do not
know. I have included some persons from the networking division at
Intel. They might know of a "known issues" page or somewhere where you
can bug report this.

/Magnus

> Thank you
>
> Max

^ permalink raw reply	[flat|nested] 6+ messages in thread

* AW: Intel X520 looses ethtool flow-type rule the moment a BPF / XDP program is loaded
  2020-06-05 12:15     ` Magnus Karlsson
@ 2020-06-05 12:25       ` Gaul, Maximilian
  2020-06-05 13:11         ` Magnus Karlsson
  0 siblings, 1 reply; 6+ messages in thread
From: Gaul, Maximilian @ 2020-06-05 12:25 UTC (permalink / raw)
  To: Magnus Karlsson, Raczynski, Piotr, Fijalkowski, Maciej, lihong.yang; +Cc: Xdp

> I do not use this card in my AF_XDP lab setup, so unforuately I do not
> know. I have included some persons from the networking division at
> Intel. They might know of a "known issues" page or somewhere where you
> can bug report this.
> 
> /Magnus

Thank you so much!

One more question: Does the 82599ES 10Gbit/s NIC have similiar issues with XDP and ethtool?

Best regards

Max

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Intel X520 looses ethtool flow-type rule the moment a BPF / XDP program is loaded
  2020-06-05 12:25       ` AW: " Gaul, Maximilian
@ 2020-06-05 13:11         ` Magnus Karlsson
  0 siblings, 0 replies; 6+ messages in thread
From: Magnus Karlsson @ 2020-06-05 13:11 UTC (permalink / raw)
  To: Gaul, Maximilian; +Cc: Raczynski, Piotr, Fijalkowski, Maciej, lihong.yang, Xdp

On Fri, Jun 5, 2020 at 2:25 PM Gaul, Maximilian <maximilian.gaul@hm.edu> wrote:
>
> > I do not use this card in my AF_XDP lab setup, so unforuately I do not
> > know. I have included some persons from the networking division at
> > Intel. They might know of a "known issues" page or somewhere where you
> > can bug report this.
> >
> > /Magnus
>
> Thank you so much!
>
> One more question: Does the 82599ES 10Gbit/s NIC have similiar issues with XDP and ethtool?

I believe that is a Niantic card too, so yes it will have at least
have the XDP issue.

/Magnus

> Best regards
>
> Max

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-06-05 13:11 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-05 11:17 Intel X520 looses ethtool flow-type rule the moment a BPF / XDP program is loaded Gaul, Maximilian
2020-06-05 11:57 ` Magnus Karlsson
2020-06-05 12:05   ` AW: " Gaul, Maximilian
2020-06-05 12:15     ` Magnus Karlsson
2020-06-05 12:25       ` AW: " Gaul, Maximilian
2020-06-05 13:11         ` Magnus Karlsson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.