The patch for dpdk-input node to use etype is: https://gerrit.fd.io/r/#/c/5563/
It is in 1704 or newer VPP and would match with your observation. Regards, John From: Nagaprabhanjan Bellaru [mailto:nagp.li...@gmail.com] Sent: Thursday, May 11, 2017 7:39 AM To: John Lo (loj) <l...@cisco.com> Cc: Damjan Marion (damarion) <damar...@cisco.com>; vpp-dev <vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] dpdk_device_input - not checking for vlan header... I am using VPP having tag "v17.01.1". I still see the problem, debugging is on... Thanks, -nagp On Tue, May 9, 2017 at 7:06 PM, John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>> wrote: Any chance you are using an older version of VPP, like 1609 or earlier? I kind of remember earlier version of VPP having this issue because it was relying on the packet type provided by DPDK driver and some NIC/driver did not provide packet type information consistently. In order to avoid this problem, we implemented dpdk_next_from_etype(), as mentioned by Damjan, in src/plugin/dpdk/device/node.c which rely on the etype of the packet only. -John From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> [mailto:vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io>] On Behalf Of Nagaprabhanjan Bellaru Sent: Tuesday, May 09, 2017 5:49 AM To: Damjan Marion (damarion) <damar...@cisco.com<mailto:damar...@cisco.com>> Cc: vpp-dev <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> Subject: Re: [vpp-dev] dpdk_device_input - not checking for vlan header... Ok, let me check again, the reason I don't suspect the packet is because, if I disable DPDK optimization (directly feed to ip4-no-checksum) - the packets are getting processed fine without any issues. Thanks, -nagp On Tue, May 9, 2017 at 3:09 PM, Damjan Marion (damarion) <damar...@cisco.com<mailto:damar...@cisco.com>> wrote: dpdk_rx_next_from_etype () will return value different than VNET_DEVICE_INPUT_NEXT_ETHERNET_INPUT _only_ if ethertype is ETHERNET_TYPE_IP4, ETHERNET_TYPE_IP6 or ETHERNET_TYPE_MPLS. So looks like ethertype in your packet is set to one of three listed above, which is wrong. On 9 May 2017, at 10:27, Nagaprabhanjan Bellaru <nagp.li...@gmail.com<mailto:nagp.li...@gmail.com>> wrote: Yes, it is set correctly. To validate it, I bypassed the dpdk optimization and fed every packet to ethernet-input (by making "dpdk_rx_next_from_etype" always return VNET_DEVICE_INPUT_NEXT_ETHERNET_INPUT). Then things started working fine - packets getting classified to correct sw_if_index, ip header pointing to beginning of ip header etc. I am referring to the way l3_offset is set by looking up device_input_next_node_advance[next] - there is no check to skip the vlan header - can you please point me to the code snippet in dpdk_device_input which does that? "vnet_feature_start_device_input" does not seem to be doing anything here.. Thanks, -nagp On Mon, May 8, 2017 at 7:32 PM, Damjan Marion (damarion) <damar...@cisco.com<mailto:damar...@cisco.com>> wrote: > > On 3 May 2017, at 13:28, Nagaprabhanjan Bellaru > <nagp.li...@gmail.com<mailto:nagp.li...@gmail.com>> wrote: > > Hi, > > It looks like dpdk_device_input() - is not checking if there is a vlan header > in the packet or not and always sets the buffer->current_data to 14 > (smac+dmac+ethtype). Because of that ip4_input is not able to recognize a > correct IP packet. > > For example, I have a subinterface created with vlan100 - which is trying to > send IP packets. The receiving side is setting l3offset to 14 and feeding the > packet to ip4-input-no-checksum and is getting dropped there. > > Am I missing something? "show interface" shows the main and the sub > interface. "show trace" for dpdk_input shows the vlan tag as 100. But > ip4_input_inline gets a buffer with current_data as 14 instead of 18 > (accounting for vlan header) We do respect VLAN ethertypes, is your ethertype set correctly?
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
