* Re: [dpdk-dev] [dpdk-users] VLAN tags always stripped on i40evf [VMware SR-IOV]
2017-10-11 13:19 ` [dpdk-dev] [dpdk-users] VLAN tags always stripped on i40evf [VMware SR-IOV] Iain Barker
@ 2017-10-27 2:23 ` Xing, Beilei
0 siblings, 0 replies; 2+ messages in thread
From: Xing, Beilei @ 2017-10-27 2:23 UTC (permalink / raw)
To: Iain Barker, users; +Cc: dev
> -----Original Message-----
> From: users [mailto:users-bounces@dpdk.org] On Behalf Of Iain Barker
> Sent: Wednesday, October 11, 2017 9:20 PM
> To: users@dpdk.org
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-users] VLAN tags always stripped on i40evf [VMware SR-
> IOV]
>
> On Tuesday, October 10, 2017 9:49 AM (EST), Iain Barker wrote:
> > I have a problem trying to get VLAN tagged frames to be received at the
> i40evf PMD.
>
> With more debugging enabled, I can see that this seems to be a compatibility
> problem between DPDK and i40evf related to VLAN hardware stripping.
>
> Specifically, when DPDK requests VLAN stripping to be disabled by VF, but
> the PF policy doesn't allow it to be disabled (as is the case for VMware SR-
> IOV), an error is returned from the API.
>
> testpmd> vlan set strip off 0
> i40evf_execute_vf_cmd(): No response for 28
> i40evf_disable_vlan_strip(): Failed to execute command of
> VIRTCHNL_OP_DISABLE_VLAN_STRIPPING
>
> In that case, received frames with VLAN headers will still be stripped at the
> PF, and the TCI will record the missing VLAN details when handed up to the
> DPDK driver.
>
> With i40e debug enabled, it's clear to see the difference being reported in
> i40e_rxd_to_vlan_tci:
>
> Example using VLAN on i40e PCI (vlan works):
> PMD: i40e_rxd_to_vlan_tci(): Mbuf vlan_tci: 0, vlan_tci_outer: 0
> Port 0 pkt-len=102 nb-segs=1
> ETH: src=00:10:E0:8D:A7:52 dst=00:10:E0:8A:86:8A [vlan id=8] type=0x0800
> IPV4: src=8.8.8.102 dst=8.8.8.3 proto=1 (ICMP)
> ICMP: echo request seq id=1
>
> Example using VLAN on i40evf SR-IOV (vlan fails):
> PMD: i40e_rxd_to_vlan_tci(): Mbuf vlan_tci: 8, vlan_tci_outer: 0
> Port 0 pkt-len=60 nb-segs=1
> ETH: src=00:10:E0:8D:A7:52 dst=FF:FF:FF:FF:FF:FF type=0x0806
> ARP: hrd=1 proto=0x0800 hln=6 pln=4 op=1 (ARP Request)
> sha=00:10:E0:8D:A7:52 sip=8.8.8.102
> tha=00:00:00:00:00:00 tip=8.8.8.3
>
> As the application requested tagging not be stripped, and the hardware
> driver was not able to disable strip, in my opinion DPDK should emulate the
> requested behavior by re-add the missing VLAN header in the RX thread,
> before it passes the mbuf to the application. I'm guessing that the native
> Linux driver is smart enough to do something like this automatically in
> software, but DPDK does not...
>
> Adding a call to rte_vlan_insert() to reinstate the VLAN header using the data
> from TCI is sufficient to avoid the problem in a quick test.
>
> --- drivers/net/i40e/i40e_rxtx.c.orig 2016-11-30 04:28:48.000000000 -0500
> +++ drivers/net/i40e/i40e_rxtx.c 2017-10-10 15:07:10.851398087 -0400
> @@ -93,6 +93,8 @@
> rte_le_to_cpu_16(rxdp->wb.qword0.lo_dword.l2tag1);
> PMD_RX_LOG(DEBUG, "Descriptor l2tag1: %u",
> rte_le_to_cpu_16(rxdp->wb.qword0.lo_dword.l2tag1));
> + // vlan got stripped. Re-inject vlan from tci
> + rte_vlan_insert(&mb);
> } else {
> mb->vlan_tci = 0;
> }
>
NACK this patch as it will impact performance.
VLAN strip is supported by latest i40e kernel driver, it works well in kernel PF +
DPDK VF mode with i40e kernel driver 2.1.26 and DPDK 17.08. Please refer to
Latest kernel driver.
Beilei
> For a proper solution, this would need to be made selective based on
> whether the port config originally asked for VLANs to be stripped or not. But
> I'm not sure that rte_vlan_insert() has enough context to be able to access
> that data, as it's stored in the driver/hw struct not the rx buffer.
>
> Obviously the same would be required in the vector rxtx and similar data
> paths for other drivers, if affected by the same shortcoming. I don't have
> other combinations available that I could test with, and I guess VMware
> i40evf SR-IOV VLAN isn't part of the DPDK release test suite either.
>
> cc: dev@dpdk.org for comment as this is getting beyond my level of
> knowledge as a DPDK user
>
> thanks,
> Iain
^ permalink raw reply [flat|nested] 2+ messages in thread