(damarion) ; vpp-dev
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)
mailto:l...@cisco.com>> wrote:
Any chance
ich rely on the etype of the packet only.
> -John
>
>
>
> *From:* 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)
> *Cc:* vpp-dev
> *Su
:49 AM
To: Damjan Marion (damarion)
Cc: vpp-dev
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
ge
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) wrote:
> dpdk_rx_next_
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:2
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 heade
>
> On 3 May 2017, at 13:28, Nagaprabhanjan Bellaru 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
