DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] VF of a X520 card does not process VLAN packets
@ 2018-12-18 11:06 Eelco Chaudron
  2019-01-03 16:42 ` Eelco Chaudron
  0 siblings, 1 reply; 6+ messages in thread
From: Eelco Chaudron @ 2018-12-18 11:06 UTC (permalink / raw)
  To: wenzhuo.lu, konstantin.ananyev; +Cc: dev

Hi,

I’m assigning a VF of an X520 card for DPDK/testpmd/OVS but it's not 
accepting tagged VLAN packets (it does accept tag 0).  Is this a known 
bug/limitation of the 82599ES chipset?

This is how I've tested it:

$ echo 1 > /sys/bus/pci/devices/0000\:05\:00.0/sriov_numvfs
$driverctl -v set-override 0000:05:10.0 vfio-pci
$./testpmd -c 7 -n 4 --socket-mem 2048,0 -w 0000:05:10.0 -- \
   --burst 64 -i --rxq=1 --txq=1 --rxd=4096 --txd=1024 \
   —coremask=6 --auto-start --port-topology=chained
EAL: Detected 28 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
...
testpmd>


I’m sending broadcast ARP packets:

Ethernet II, Src: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00), Dst: 
ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
     Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
         Address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
         .... ..1. .... .... .... .... = LG bit: Locally administered 
address (this is NOT the factory default)
         .... ...1 .... .... .... .... = IG bit: Group address 
(multicast/broadcast)
     Source: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00)
         Address: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00)
         .... ..0. .... .... .... .... = LG bit: Globally unique address 
(factory default)
         .... ...0 .... .... .... .... = IG bit: Individual address 
(unicast)
     Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 10
     000. .... .... .... = Priority: Best Effort (default) (0)
     ...0 .... .... .... = CFI: Canonical (0)
     .... 0000 0000 1010 = ID: 10
     Type: ARP (0x0806)
     Padding: 2e2f303132333435363738393a3b
     Trailer: 3c3d3e3f404142434445464748494a4b4c4d4e4f50515253...
Address Resolution Protocol (request/gratuitous ARP)
     Hardware type: Ethernet (1)
     Protocol type: IP (0x0800)
     Hardware size: 6
     Protocol size: 4
     Opcode: request (1)
     [Is gratuitous: True]
     Sender MAC address: 00:00:00:00:00:00 (00:00:00:00:00:00)
     Sender IP address: 0.0.0.0 (0.0.0.0)
     Target MAC address: 00:00:00:00:00:00 (00:00:00:00:00:00)
     Target IP address: 0.0.0.0 (0.0.0.0)

No traffic is received, if you replace tag 10 with 0, packets are 
received.

Note that this is a simple reproducer with testpmd, but it's reported as 
part of an OVS integration. This works fine on the physical port, or 
with a VF on an XL710 card.

Any input appreciated.

Thanks,

Eelco

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

* Re: [dpdk-dev] VF of a X520 card does not process VLAN packets
  2018-12-18 11:06 [dpdk-dev] VF of a X520 card does not process VLAN packets Eelco Chaudron
@ 2019-01-03 16:42 ` Eelco Chaudron
  2019-01-18 11:25   ` Ananyev, Konstantin
  0 siblings, 1 reply; 6+ messages in thread
From: Eelco Chaudron @ 2019-01-03 16:42 UTC (permalink / raw)
  To: wenzhuo.lu, konstantin.ananyev; +Cc: dev

Hi maintainers, any feedback on the below?

Thanks,

Eelco


On 18 Dec 2018, at 12:06, Eelco Chaudron wrote:

> Hi,
>
> I’m assigning a VF of an X520 card for DPDK/testpmd/OVS but it's not 
> accepting tagged VLAN packets (it does accept tag 0).  Is this a known 
> bug/limitation of the 82599ES chipset?
>
> This is how I've tested it:
>
> $ echo 1 > /sys/bus/pci/devices/0000\:05\:00.0/sriov_numvfs
> $driverctl -v set-override 0000:05:10.0 vfio-pci
> $./testpmd -c 7 -n 4 --socket-mem 2048,0 -w 0000:05:10.0 -- \
>   --burst 64 -i --rxq=1 --txq=1 --rxd=4096 --txd=1024 \
>   —coremask=6 --auto-start --port-topology=chained
> EAL: Detected 28 lcore(s)
> EAL: Detected 1 NUMA nodes
> EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> ...
> testpmd>
>
>
> I’m sending broadcast ARP packets:
>
> Ethernet II, Src: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00), Dst: 
> ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
>     Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
>         Address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
>         .... ..1. .... .... .... .... = LG bit: Locally administered 
> address (this is NOT the factory default)
>         .... ...1 .... .... .... .... = IG bit: Group address 
> (multicast/broadcast)
>     Source: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00)
>         Address: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00)
>         .... ..0. .... .... .... .... = LG bit: Globally unique 
> address (factory default)
>         .... ...0 .... .... .... .... = IG bit: Individual address 
> (unicast)
>     Type: 802.1Q Virtual LAN (0x8100)
> 802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 10
>     000. .... .... .... = Priority: Best Effort (default) (0)
>     ...0 .... .... .... = CFI: Canonical (0)
>     .... 0000 0000 1010 = ID: 10
>     Type: ARP (0x0806)
>     Padding: 2e2f303132333435363738393a3b
>     Trailer: 3c3d3e3f404142434445464748494a4b4c4d4e4f50515253...
> Address Resolution Protocol (request/gratuitous ARP)
>     Hardware type: Ethernet (1)
>     Protocol type: IP (0x0800)
>     Hardware size: 6
>     Protocol size: 4
>     Opcode: request (1)
>     [Is gratuitous: True]
>     Sender MAC address: 00:00:00:00:00:00 (00:00:00:00:00:00)
>     Sender IP address: 0.0.0.0 (0.0.0.0)
>     Target MAC address: 00:00:00:00:00:00 (00:00:00:00:00:00)
>     Target IP address: 0.0.0.0 (0.0.0.0)
>
> No traffic is received, if you replace tag 10 with 0, packets are 
> received.
>
> Note that this is a simple reproducer with testpmd, but it's reported 
> as part of an OVS integration. This works fine on the physical port, 
> or with a VF on an XL710 card.
>
> Any input appreciated.
>
> Thanks,
>
> Eelco

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

* Re: [dpdk-dev] VF of a X520 card does not process VLAN packets
  2019-01-03 16:42 ` Eelco Chaudron
@ 2019-01-18 11:25   ` Ananyev, Konstantin
  2019-01-22 13:33     ` Eelco Chaudron
  0 siblings, 1 reply; 6+ messages in thread
From: Ananyev, Konstantin @ 2019-01-18 11:25 UTC (permalink / raw)
  To: Eelco Chaudron; +Cc: dev

Hi
It’s been while since I looked at it last time,
but shouldn’t you assign desired vlan tag to the VF first:
ip link set <device> vf <num> vlan <num>
?
Konstantin

From: Eelco Chaudron [mailto:echaudro@redhat.com]
Sent: Thursday, January 3, 2019 4:42 PM
To: Lu, Wenzhuo <wenzhuo.lu@intel.com>; Ananyev, Konstantin <konstantin.ananyev@intel.com>
Cc: dev <dev@dpdk.org>
Subject: Re: [dpdk-dev] VF of a X520 card does not process VLAN packets


Hi maintainers, any feedback on the below?

Thanks,

Eelco

On 18 Dec 2018, at 12:06, Eelco Chaudron wrote:

Hi,

I’m assigning a VF of an X520 card for DPDK/testpmd/OVS but it's not accepting tagged VLAN packets (it does accept tag 0). Is this a known bug/limitation of the 82599ES chipset?

This is how I've tested it:

$ echo 1 > /sys/bus/pci/devices/0000:05:00.0/sriov_numvfs
$driverctl -v set-override 0000:05:10.0 vfio-pci
$./testpmd -c 7 -n 4 --socket-mem 2048,0 -w 0000:05:10.0 -- \
--burst 64 -i --rxq=1 --txq=1 --rxd=4096 --txd=1024 \
—coremask=6 --auto-start --port-topology=chained
EAL: Detected 28 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
...
testpmd>

I’m sending broadcast ARP packets:

Ethernet II, Src: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00), Dst: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
Address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00)
Address: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 10
000. .... .... .... = Priority: Best Effort (default) (0)
...0 .... .... .... = CFI: Canonical (0)
.... 0000 0000 1010 = ID: 10
Type: ARP (0x0806)
Padding: 2e2f303132333435363738393a3b
Trailer: 3c3d3e3f404142434445464748494a4b4c4d4e4f50515253...
Address Resolution Protocol (request/gratuitous ARP)
Hardware type: Ethernet (1)
Protocol type: IP (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: request (1)
[Is gratuitous: True]
Sender MAC address: 00:00:00:00:00:00 (00:00:00:00:00:00)
Sender IP address: 0.0.0.0 (0.0.0.0)
Target MAC address: 00:00:00:00:00:00 (00:00:00:00:00:00)
Target IP address: 0.0.0.0 (0.0.0.0)

No traffic is received, if you replace tag 10 with 0, packets are received.

Note that this is a simple reproducer with testpmd, but it's reported as part of an OVS integration. This works fine on the physical port, or with a VF on an XL710 card.

Any input appreciated.

Thanks,

Eelco

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

* Re: [dpdk-dev] VF of a X520 card does not process VLAN packets
  2019-01-18 11:25   ` Ananyev, Konstantin
@ 2019-01-22 13:33     ` Eelco Chaudron
  0 siblings, 0 replies; 6+ messages in thread
From: Eelco Chaudron @ 2019-01-22 13:33 UTC (permalink / raw)
  To: Ananyev, Konstantin; +Cc: dev

Hi Konstantin,

Thanks for your reply…

Yes adding the VLAN to the VF from the kernel side will work, however, 
this is a different behaviour than the XL710.

The XL710 will allow all VLANs to pass through once the PMD takes 
control of the VF.

The real use case is using this VF interface trough Open vSwitch which 
needs to see all packets regardless of the VLAN.
It does not make sense to create 4K VLANs through the kernel to get this 
working.

Looking forward to your reply…

Cheers,

Eelco



On 18 Jan 2019, at 12:25, Ananyev, Konstantin wrote:

> Hi
> It’s been while since I looked at it last time,
> but shouldn’t you assign desired vlan tag to the VF first:
> ip link set <device> vf <num> vlan <num>
> ?
> Konstantin
>
> From: Eelco Chaudron [mailto:echaudro@redhat.com]
> Sent: Thursday, January 3, 2019 4:42 PM
> To: Lu, Wenzhuo <wenzhuo.lu@intel.com>; Ananyev, Konstantin 
> <konstantin.ananyev@intel.com>
> Cc: dev <dev@dpdk.org>
> Subject: Re: [dpdk-dev] VF of a X520 card does not process VLAN 
> packets
>
>
> Hi maintainers, any feedback on the below?
>
> Thanks,
>
> Eelco
>
> On 18 Dec 2018, at 12:06, Eelco Chaudron wrote:
>
> Hi,
>
> I’m assigning a VF of an X520 card for DPDK/testpmd/OVS but it's not 
> accepting tagged VLAN packets (it does accept tag 0). Is this a known 
> bug/limitation of the 82599ES chipset?
>
> This is how I've tested it:
>
> $ echo 1 > /sys/bus/pci/devices/0000:05:00.0/sriov_numvfs
> $driverctl -v set-override 0000:05:10.0 vfio-pci
> $./testpmd -c 7 -n 4 --socket-mem 2048,0 -w 0000:05:10.0 -- \
> --burst 64 -i --rxq=1 --txq=1 --rxd=4096 --txd=1024 \
> —coremask=6 --auto-start --port-topology=chained
> EAL: Detected 28 lcore(s)
> EAL: Detected 1 NUMA nodes
> EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> ...
> testpmd>
>
> I’m sending broadcast ARP packets:
>
> Ethernet II, Src: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00), Dst: 
> ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
> Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
> Address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
> .... ..1. .... .... .... .... = LG bit: Locally administered address 
> (this is NOT the factory default)
> .... ...1 .... .... .... .... = IG bit: Group address 
> (multicast/broadcast)
> Source: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00)
> Address: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00)
> .... ..0. .... .... .... .... = LG bit: Globally unique address 
> (factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Type: 802.1Q Virtual LAN (0x8100)
> 802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 10
> 000. .... .... .... = Priority: Best Effort (default) (0)
> ...0 .... .... .... = CFI: Canonical (0)
> .... 0000 0000 1010 = ID: 10
> Type: ARP (0x0806)
> Padding: 2e2f303132333435363738393a3b
> Trailer: 3c3d3e3f404142434445464748494a4b4c4d4e4f50515253...
> Address Resolution Protocol (request/gratuitous ARP)
> Hardware type: Ethernet (1)
> Protocol type: IP (0x0800)
> Hardware size: 6
> Protocol size: 4
> Opcode: request (1)
> [Is gratuitous: True]
> Sender MAC address: 00:00:00:00:00:00 (00:00:00:00:00:00)
> Sender IP address: 0.0.0.0 (0.0.0.0)
> Target MAC address: 00:00:00:00:00:00 (00:00:00:00:00:00)
> Target IP address: 0.0.0.0 (0.0.0.0)
>
> No traffic is received, if you replace tag 10 with 0, packets are 
> received.
>
> Note that this is a simple reproducer with testpmd, but it's reported 
> as part of an OVS integration. This works fine on the physical port, 
> or with a VF on an XL710 card.
>
> Any input appreciated.
>
> Thanks,
>
> Eelco

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

* Re: [dpdk-dev] VF of a X520 card does not process VLAN packets
  2019-01-23 14:09 ` Ananyev, Konstantin
@ 2019-01-29  9:30   ` Zhao1, Wei
  0 siblings, 0 replies; 6+ messages in thread
From: Zhao1, Wei @ 2019-01-29  9:30 UTC (permalink / raw)
  To: Ananyev, Konstantin, Eelco Chaudron; +Cc: dev


Hi, Konstantin

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev,
> Konstantin
> Sent: Wednesday, January 23, 2019 10:09 PM
> To: Eelco Chaudron <echaudro@redhat.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] VF of a X520 card does not process VLAN packets
> 
> Hi Eelco,
> 
> >
> >
> > Hi Konstantin,
> > Thanks for your reply…
> > Yes adding the VLAN to the VF from the kernel side will work, however,
> this is a different behaviour than the XL710.
> > The XL710 will allow all VLANs to pass through once the PMD takes control
> of the VF.


> 
> It is not about who controls VF.
> On ixgbe VLAN filter are configured and controlled by PF.
> In your case PF is controlled by kernel ixgbe driver.
> AFAIK, in SRIOV mode ixgbe kernel driver always enables VLAN filtering, and
> there is not possible to revert it (at least I don't know how).
> Konstantin

Yes, you are right. BY now, ixgbe vf has no ops to enable this.
I have commit a patch set to enable VF VLAN and MAC promiscuous on ixgbe.
And also dpdk pf host has update to pf kernel 5.3.7 which has support this.

https://patches.dpdk.org/patch/49870/ 

https://patches.dpdk.org/patch/49871/ 

https://patches.dpdk.org/patch/49872/


> 
> > The real use case is using this VF interface trough Open vSwitch which
> needs to see all packets regardless of the VLAN.
> > It does not make sense to create 4K VLANs through the kernel to get this
> working.
> > Looking forward to your reply…
> > Cheers,
> > Eelco
> >
> > On 18 Jan 2019, at 12:25, Ananyev, Konstantin wrote:
> > Hi
> > It’s been while since I looked at it last time, but shouldn’t you
> > assign desired vlan tag to the VF first:
> > ip link set <device> vf <num> vlan <num> ?
> > Konstantin
> >
> > From: Eelco Chaudron [mailto:echaudro@redhat.com]
> > Sent: Thursday, January 3, 2019 4:42 PM
> > To: Lu, Wenzhuo <wenzhuo.lu@intel.com>; Ananyev, Konstantin
> > <konstantin.ananyev@intel.com>
> > Cc: dev <dev@dpdk.org>
> > Subject: Re: [dpdk-dev] VF of a X520 card does not process VLAN
> > packets
> >
> > Hi maintainers, any feedback on the below?
> > Thanks,
> > Eelco
> > On 18 Dec 2018, at 12:06, Eelco Chaudron wrote:
> > Hi,
> > I’m assigning a VF of an X520 card for DPDK/testpmd/OVS but it's not
> > accepting tagged VLAN packets (it does accept tag 0). Is this a known
> bug/limitation of the 82599ES chipset?
> > This is how I've tested it:
> > $ echo 1 > /sys/bus/pci/devices/0000:05:00.0/sriov_numvfs
> > $driverctl -v set-override 0000:05:10.0 vfio-pci $./testpmd -c 7 -n 4
> > --socket-mem 2048,0 -w 0000:05:10.0 -- \ --burst 64 -i --rxq=1 --txq=1
> > --rxd=4096 --txd=1024 \
> > —coremask=6 --auto-start --port-topology=chained
> > EAL: Detected 28 lcore(s)
> > EAL: Detected 1 NUMA nodes
> > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket ...
> > testpmd>
> > I’m sending broadcast ARP packets:
> > Ethernet II, Src: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00), Dst:
> > ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
> > Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
> > Address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff) .... ..1. .... ....
> > .... .... = LG bit: Locally administered address (this is NOT the
> > factory default) .... ...1 .... .... .... .... = IG bit: Group address
> > (multicast/broadcast)
> > Source: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00)
> > Address: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00) .... ..0. .... ....
> > .... .... = LG bit: Globally unique address (factory default) ....
> > ...0 .... .... .... .... = IG bit: Individual address (unicast)
> > Type: 802.1Q Virtual LAN (0x8100)
> > 802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 10 000. .... .... .... =
> > Priority: Best Effort (default) (0)
> > ...0 .... .... .... = CFI: Canonical (0) .... 0000 0000 1010 = ID: 10
> > Type: ARP (0x0806)
> > Padding: 2e2f303132333435363738393a3b
> > Trailer: 3c3d3e3f404142434445464748494a4b4c4d4e4f50515253...
> > Address Resolution Protocol (request/gratuitous ARP) Hardware type:
> > Ethernet (1) Protocol type: IP (0x0800) Hardware size: 6 Protocol
> > size: 4
> > Opcode: request (1)
> > [Is gratuitous: True]
> > Sender MAC address: 00:00:00:00:00:00 (00:00:00:00:00:00) Sender IP
> > address: 0.0.0.0 (0.0.0.0) Target MAC address: 00:00:00:00:00:00
> > (00:00:00:00:00:00) Target IP address: 0.0.0.0 (0.0.0.0) No traffic is
> > received, if you replace tag 10 with 0, packets are received.
> > Note that this is a simple reproducer with testpmd, but it's reported
> > as part of an OVS integration. This works fine on the physical port, or with a
> VF on an XL710 card.
> > Any input appreciated.
> > Thanks,
> > Eelco

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

* Re: [dpdk-dev] VF of a X520 card does not process VLAN packets
       [not found] <2601191342CEEE43887BDE71AB977258010D9070D3@irsmsx105.ger.corp.intel.com>
@ 2019-01-23 14:09 ` Ananyev, Konstantin
  2019-01-29  9:30   ` Zhao1, Wei
  0 siblings, 1 reply; 6+ messages in thread
From: Ananyev, Konstantin @ 2019-01-23 14:09 UTC (permalink / raw)
  To: Eelco Chaudron; +Cc: dev

Hi Eelco,

> 
> 
> Hi Konstantin,
> Thanks for your reply…
> Yes adding the VLAN to the VF from the kernel side will work, however, this is a different behaviour than the XL710.
> The XL710 will allow all VLANs to pass through once the PMD takes control of the VF.

It is not about who controls VF.
On ixgbe VLAN filter are configured and controlled by PF.
In your case PF is controlled by kernel ixgbe driver.
AFAIK, in SRIOV mode ixgbe kernel driver always enables VLAN filtering,
and there is not possible to revert it (at least I don't know how).
Konstantin 

> The real use case is using this VF interface trough Open vSwitch which needs to see all packets regardless of the VLAN.
> It does not make sense to create 4K VLANs through the kernel to get this working.
> Looking forward to your reply…
> Cheers,
> Eelco
> 
> On 18 Jan 2019, at 12:25, Ananyev, Konstantin wrote:
> Hi
> It’s been while since I looked at it last time,
> but shouldn’t you assign desired vlan tag to the VF first:
> ip link set <device> vf <num> vlan <num>
> ?
> Konstantin
> 
> From: Eelco Chaudron [mailto:echaudro@redhat.com]
> Sent: Thursday, January 3, 2019 4:42 PM
> To: Lu, Wenzhuo <wenzhuo.lu@intel.com>; Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: dev <dev@dpdk.org>
> Subject: Re: [dpdk-dev] VF of a X520 card does not process VLAN packets
> 
> Hi maintainers, any feedback on the below?
> Thanks,
> Eelco
> On 18 Dec 2018, at 12:06, Eelco Chaudron wrote:
> Hi,
> I’m assigning a VF of an X520 card for DPDK/testpmd/OVS but it's not accepting tagged VLAN packets (it does accept tag 0). Is this a known
> bug/limitation of the 82599ES chipset?
> This is how I've tested it:
> $ echo 1 > /sys/bus/pci/devices/0000:05:00.0/sriov_numvfs
> $driverctl -v set-override 0000:05:10.0 vfio-pci
> $./testpmd -c 7 -n 4 --socket-mem 2048,0 -w 0000:05:10.0 -- \
> --burst 64 -i --rxq=1 --txq=1 --rxd=4096 --txd=1024 \
> —coremask=6 --auto-start --port-topology=chained
> EAL: Detected 28 lcore(s)
> EAL: Detected 1 NUMA nodes
> EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> ...
> testpmd>
> I’m sending broadcast ARP packets:
> Ethernet II, Src: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00), Dst: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
> Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
> Address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
> .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
> .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
> Source: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00)
> Address: 04:f4:bc:43:e1:00 (04:f4:bc:43:e1:00)
> .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Type: 802.1Q Virtual LAN (0x8100)
> 802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 10
> 000. .... .... .... = Priority: Best Effort (default) (0)
> ...0 .... .... .... = CFI: Canonical (0)
> .... 0000 0000 1010 = ID: 10
> Type: ARP (0x0806)
> Padding: 2e2f303132333435363738393a3b
> Trailer: 3c3d3e3f404142434445464748494a4b4c4d4e4f50515253...
> Address Resolution Protocol (request/gratuitous ARP)
> Hardware type: Ethernet (1)
> Protocol type: IP (0x0800)
> Hardware size: 6
> Protocol size: 4
> Opcode: request (1)
> [Is gratuitous: True]
> Sender MAC address: 00:00:00:00:00:00 (00:00:00:00:00:00)
> Sender IP address: 0.0.0.0 (0.0.0.0)
> Target MAC address: 00:00:00:00:00:00 (00:00:00:00:00:00)
> Target IP address: 0.0.0.0 (0.0.0.0)
> No traffic is received, if you replace tag 10 with 0, packets are received.
> Note that this is a simple reproducer with testpmd, but it's reported as part of an OVS integration. This works fine on the physical port, or
> with a VF on an XL710 card.
> Any input appreciated.
> Thanks,
> Eelco

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

end of thread, other threads:[~2019-01-29  9:30 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-18 11:06 [dpdk-dev] VF of a X520 card does not process VLAN packets Eelco Chaudron
2019-01-03 16:42 ` Eelco Chaudron
2019-01-18 11:25   ` Ananyev, Konstantin
2019-01-22 13:33     ` Eelco Chaudron
     [not found] <2601191342CEEE43887BDE71AB977258010D9070D3@irsmsx105.ger.corp.intel.com>
2019-01-23 14:09 ` Ananyev, Konstantin
2019-01-29  9:30   ` Zhao1, Wei

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).