Hi, Does anyone have a work-around for this? Should we debug the vmxnet3 driver since for sure this issue is even coming in standard l2fwd example.
Thanks, Padam > On 12-Apr-2018, at 11:52 AM, Padam Jeet Singh <padam.si...@inventum.net> > wrote: > > > >> On 10-Apr-2018, at 11:43 AM, Yong Wang <yongw...@vmware.com> wrote: >> >> When using 4095, I assume you enabled trunk mode on ESX vswitch. What ESX >> version did you use? Is the vswitch standard switch or DVS? We have tested >> over ESX6.0 and onwards plus DPDK 17.05 and it should work. > > Yes, the 4095 enables trunk mode. ESXi version is "6.0.0 (Build 3620759)”, > the switch is a “Standard vSwitch”. > > I did a simple change to the standard l2fwd sample application. Then tried > the same app once with e1000e emulation driver, and then with the vmxnet3 > driver. Patch for changes done to the l2fwd code are available here: > https://pastebin.com/0RMJYKr0 > > The change I did was enable hw_vlan_strip = 1 and also call > rte_eth_dev_set_vlan_offload both post configure and post start. > > With e1000e driver, sample packets arriving with different VLANs: > > mbuff->vlan_tci=500 vlan_tci_outer=0 ethertype=8 > mbuff->vlan_tci=500 vlan_tci_outer=0 ethertype=8 > mbuff->vlan_tci=105 vlan_tci_outer=0 ethertype=8 > mbuff->vlan_tci=100 vlan_tci_outer=0 ethertype=8 > > > With vmxnet3, packets arriving with different VLANs: > > mbuff->vlan_tci=0 vlan_tci_outer=0 ethertype=81 > mbuff->vlan_tci=0 vlan_tci_outer=0 ethertype=81 > mbuff->vlan_tci=0 vlan_tci_outer=0 ethertype=81 > mbuff->vlan_tci=0 vlan_tci_outer=0 ethertype=81 > mbuff->vlan_tci=0 vlan_tci_outer=0 ethertype=81 > > the ether type values are not printed byte-swapped … so it’s 8100 (VLAN) and > 0800 (IPv4). > > > > >> >> On 4/8/18, 11:22 PM, "Padam Jeet Singh" <padam.si...@inventum.net> wrote: >> >> >>> On 06-Apr-2018, at 11:12 PM, Yong Wang <yongw...@vmware.com> wrote: >>> >>> Padam, >>> >>> As far as I know, this feature works. What DPDK version did you use? >> >> DPDK Version 17.05 >> >>> Is there any port reconfiguration (stop/start/mtu change, etc) that could >>> lose your vlan offload settings (a dump of the port config at runtime will >>> be able to confirm this)? Can you also post a snippet of packet capture of >>> the vlan traffic received? >>> >> >> It’s a standard configure followed by start. No MTU change/Stop. Here are >> the port configuration post the device start: >> >> 2018-04-09T05:37:45.332573+00:00 INFO inventum fpnas : APP: -- Ethernet >> Port Info (0) -- >> 2018-04-09T05:37:45.332729+00:00 INFO inventum fpnas : APP: Driver >> net_vmxnet3 >> 2018-04-09T05:37:45.332822+00:00 INFO inventum fpnas : APP: if_index >> 0 >> 2018-04-09T05:37:45.332926+00:00 INFO inventum fpnas : APP: >> min_rx_bufsize 1646 >> 2018-04-09T05:37:45.333015+00:00 INFO inventum fpnas : APP: >> max_rx_pktlen 16384 >> 2018-04-09T05:37:45.333102+00:00 INFO inventum fpnas : APP: >> max_rx_queues supported 16 >> 2018-04-09T05:37:45.333218+00:00 INFO inventum fpnas : APP: >> max_tx_queues supported 8 >> 2018-04-09T05:37:45.333305+00:00 INFO inventum fpnas : APP: rx_queues >> configured 2 >> 2018-04-09T05:37:45.333390+00:00 INFO inventum fpnas : APP: tx_queues >> configured 2 >> 2018-04-09T05:37:45.333475+00:00 INFO inventum fpnas : APP: >> max_mac_addrs 1 >> 2018-04-09T05:37:45.333560+00:00 INFO inventum fpnas : APP: max_vfs >> 0 >> 2018-04-09T05:37:45.333644+00:00 INFO inventum fpnas : APP: >> max_vmdq_pools 0 >> 2018-04-09T05:37:45.333728+00:00 INFO inventum fpnas : APP: >> rx_offload_cap 29 >> 2018-04-09T05:37:45.333832+00:00 INFO inventum fpnas : APP: >> tx_offload_cap 45 >> 2018-04-09T05:37:45.333944+00:00 INFO inventum fpnas : APP: >> vlan_offload_flags 1 >> >> >> And the VLAN offload setting while the device is running (with the packet >> coming from the test PC): >> >> vlan_offload_flag: 1 >> >> >> The configuration as is as follows: >> >> [vmxnet3 based interface on VM with DPDK app] —— [ vswitch with VLAN 4095 >> and uplink using Intel igb based adaptor] —— [ test PC with VLAN interface ] >> >> Packet sent by the PC (ARP packet): >> >> Frame 1: 46 bytes on wire (368 bits), 46 bytes captured (368 bits) >> Ethernet II, Src: 00:25:64:cf:f2:30, Dst: ff:ff:ff:ff:ff:ff >> 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 105 >> Address Resolution Protocol (request) >> >> >> If I redo the test with the same physical and vmware setup but instead of >> vmxnet3 I use e1000e emulation driver, all of this works fine. Packets come >> properly stripped of VLAN with vlan_tci fields set correctly. >> >> >>> Yong >>> >>> On 4/6/18, 6:51 AM, "dev on behalf of Padam Jeet Singh" >>> <dev-boun...@dpdk.org on behalf of padam.si...@inventum.net> wrote: >>> >>> Hi, >>> >>> When configuring the vmxnet3 based ethernet device, the RX VLAN Strip >>> offload does not work as it usually does with other real NICs which support >>> this function. >>> >>> When configuring with rxmode.hw_vlan_strip = 1, the ipackets statistic >>> does not increase when a VLAN ether type frame is received on the port and >>> it is also not received on queue RX. >>> However, when configuring rxmode.hw_vlan_strip = 0 ,the ipackets statistic >>> increases as well as frames arrives with VLAN header. >>> >>> Though calling rte_eth_dev_set_vlan_offload(port, ETH_VLAN_STRIP_OFFLOAD) >>> returns a success, however VLAN stripping on RX does not work. >>> >>> TX VLAN INSERT offload on the other hand works just fine. >>> >>> Is this a bug in vmxnet3 driver of dpdk? >>> >>> Thanks, >>> Padam >>> >> >> >> >
