[dpdk-dev] [vpp-dev] VLAN packets dropped... ?
We will be adding a patch to the i40e driver that would check the packet for presence of VLAN tag set the required PKT_RX_VLAN_PKT flag. I hope to get it done by the end of this week. -John From: Chandrasekar Kannan [mailto:ckan...@console.to] Sent: Wednesday, June 01, 2016 2:45 PM To: John Daley (johndale) Cc: John Lo (loj); Ananyev, Konstantin; Wiles, Keith; vpp-dev; Zhang, Helin; dev at dpdk.org Subject: Re: [vpp-dev] VLAN packets dropped... ? Just checking back on this thread to see where things are. Are we saying this is a bug in dpdk or vpp ?. That part wasn't quite clear to me. -Chandra On Thu, May 26, 2016 at 3:56 PM, John Daley (johndale) mailto:johndale at cisco.com>> wrote: John, As just discussed, what you suggest was considered but there are other apps depending a different behavior of the flag, so we thought the best thing to do is deprecate it. That is part of what Olivier's patch discussed in http://www.dpdk.org/ml/archives/dev/2016-May/038786.html does. Adding a new ptype for VLAN tagged packets after the patch is accepted would allow VPP to check if the ptype is supported by the PMD and if so, use it to determine if the delivered packet actually has a VLAN tag in it. No need to know if stripping is enabled/disabled. If the ptype is not supported, the app would have check the packet in SW. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org<mailto:dev-bounces at dpdk.org>] On > Behalf Of John Lo (loj) > Sent: Thursday, May 26, 2016 11:11 AM > To: Ananyev, Konstantin intel.com<mailto:konstantin.ananyev at intel.com>>; Wiles, Keith > mailto:keith.wiles at intel.com>>; Chandrasekar > Kannan mailto:ckannan at console.to>> > Cc: vpp-dev mailto:vpp-dev at lists.fd.io>>; Zhang, > Helin mailto:helin.zhang at intel.com>>; > dev at dpdk.org<mailto:dev at dpdk.org> > Subject: Re: [dpdk-dev] [vpp-dev] VLAN packets dropped... ? > > Hi Konstantin, > > Thanks for the link to DPDK discussion wrt this VLAN offload flag > PKT_RX_VLAN_PKT. It seems the proposal was to deprecate > PKT_RX_VLAN_PKT and introduce two new flags PKT_RX_VLAN_STRIPPED > and PKT_RX_QINQ_STRIPPED. > > It would be a really good idea to keep PKT_RX_VLAN_PKT to indicate at least > one VLAN tag is present on the packet. For the case of i40e where its HW > cannot detect VLAN tag if strip is not enabled, it should be reasonable for > the > i40e DPDK driver software to make a check and set this flag. I would think the > overhead to check the 1st ethertype field in the MAC header against dot1q > or dot1ad values in software be pretty minimal. > > Regards, > John > > > -Original Message- > From: Ananyev, Konstantin [mailto:konstantin.ananyev at > intel.com<mailto:konstantin.ananyev at intel.com>] > Sent: Wednesday, May 25, 2016 3:23 PM > To: John Lo (loj); Wiles, Keith; Chandrasekar Kannan > Cc: vpp-dev; Zhang, Helin; dev at dpdk.org<mailto:dev at dpdk.org> > Subject: RE: [vpp-dev] VLAN packets dropped... ? > > > > I suppose this has to do with what is expected usage of the > > PKT_RX_VLAN_PKT offload flag. Is it set only for VLAN packets with the > > VLAN stripped or should always be set if VLAN is/was present in the > > received packet. It seems that different DPDK drivers are behaving > differently which will make it really hard for VPP to take advantage of NIC > and driver offload capability to provide better performance. > > Yes, that's true ixgbe/igb from one side and i40e do raise PKT_RX_VLAN_PKT > in a different manner. > There is an attempt to make it unified across all supported devices: > http://dpdk.org/dev/patchwork/patch/12938/ > > Though, I am not sure it will help you with your issue. > As I understand, for you the desired behaviour is: > If it is a vlan packet, keep the packet intact (don't strip the vlan) and > raise > PKT_RX_VLAN_PK inside mbuf->ol_flags. > That's what ixgbe is doing with rte_eth_conf.rxmode.hw_vlan_strip==0. > Correct? > As far as I know, i40e HW doesn't provide such ability. > i40e Receive HW Descriptor can only flag was VLAN tag stripped from the > packet or not, but if stripping is disabled it wouldn't indicate in any way is > VLAN tag is present inside the packet or not. > I am CC-ing it to dpdk.org<http://dpdk.org> in case I am missing something > here. > Probably someone knows a way to make it work in that way. > Konstantin > > > > > If VPP cannot rely on offload flags for VLAN so packets always have to go > through ethernet-input node, there is a performance cost. > > For the 10GE case, before the inverse patch of the ixgbe driver, 10GE > > Rx-vector path removed support of offload flag with DPDK 16.04 and so > > ether
[dpdk-dev] [vpp-dev] VLAN packets dropped... ?
Awesome!. Thanks for the quick response John!. -Chandra On Wed, Jun 1, 2016 at 1:02 PM, John Lo (loj) wrote: > We will be adding a patch to the i40e driver that would check the packet > for presence of VLAN tag set the required PKT_RX_VLAN_PKT flag. I hope to > get it done by the end of this week. -John > > > > *From:* Chandrasekar Kannan [mailto:ckannan at console.to] > *Sent:* Wednesday, June 01, 2016 2:45 PM > *To:* John Daley (johndale) > *Cc:* John Lo (loj); Ananyev, Konstantin; Wiles, Keith; vpp-dev; Zhang, > Helin; dev at dpdk.org > *Subject:* Re: [vpp-dev] VLAN packets dropped... ? > > > > Just checking back on this thread to see where things are. Are we saying > this is a bug in dpdk or vpp ?. That part wasn't quite clear to me. > > > > -Chandra > > > > > > > > On Thu, May 26, 2016 at 3:56 PM, John Daley (johndale) > wrote: > > John, > As just discussed, what you suggest was considered but there are other > apps depending a different behavior of the flag, so we thought the best > thing to do is deprecate it. That is part of what Olivier's patch discussed > in http://www.dpdk.org/ml/archives/dev/2016-May/038786.html does. Adding > a new ptype for VLAN tagged packets after the patch is accepted would allow > VPP to check if the ptype is supported by the PMD and if so, use it to > determine if the delivered packet actually has a VLAN tag in it. No need to > know if stripping is enabled/disabled. If the ptype is not supported, the > app would have check the packet in SW. > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John Lo (loj) > > Sent: Thursday, May 26, 2016 11:11 AM > > To: Ananyev, Konstantin ; Wiles, Keith > > ; Chandrasekar Kannan > > Cc: vpp-dev ; Zhang, Helin > intel.com>; > > dev at dpdk.org > > Subject: Re: [dpdk-dev] [vpp-dev] VLAN packets dropped... ? > > > > Hi Konstantin, > > > > Thanks for the link to DPDK discussion wrt this VLAN offload flag > > PKT_RX_VLAN_PKT. It seems the proposal was to deprecate > > PKT_RX_VLAN_PKT and introduce two new flags PKT_RX_VLAN_STRIPPED > > and PKT_RX_QINQ_STRIPPED. > > > > It would be a really good idea to keep PKT_RX_VLAN_PKT to indicate at > least > > one VLAN tag is present on the packet. For the case of i40e where its HW > > cannot detect VLAN tag if strip is not enabled, it should be reasonable > for the > > i40e DPDK driver software to make a check and set this flag. I would > think the > > overhead to check the 1st ethertype field in the MAC header against dot1q > > or dot1ad values in software be pretty minimal. > > > > Regards, > > John > > > > > > -Original Message- > > From: Ananyev, Konstantin [mailto:konstantin.ananyev at intel.com] > > Sent: Wednesday, May 25, 2016 3:23 PM > > To: John Lo (loj); Wiles, Keith; Chandrasekar Kannan > > Cc: vpp-dev; Zhang, Helin; dev at dpdk.org > > Subject: RE: [vpp-dev] VLAN packets dropped... ? > > > > > > > I suppose this has to do with what is expected usage of the > > > PKT_RX_VLAN_PKT offload flag. Is it set only for VLAN packets with the > > > VLAN stripped or should always be set if VLAN is/was present in the > > > received packet. It seems that different DPDK drivers are behaving > > differently which will make it really hard for VPP to take advantage of > NIC > > and driver offload capability to provide better performance. > > > > Yes, that's true ixgbe/igb from one side and i40e do raise > PKT_RX_VLAN_PKT > > in a different manner. > > There is an attempt to make it unified across all supported devices: > > http://dpdk.org/dev/patchwork/patch/12938/ > > > > Though, I am not sure it will help you with your issue. > > As I understand, for you the desired behaviour is: > > If it is a vlan packet, keep the packet intact (don't strip the vlan) > and raise > > PKT_RX_VLAN_PK inside mbuf->ol_flags. > > That's what ixgbe is doing with rte_eth_conf.rxmode.hw_vlan_strip==0. > > Correct? > > As far as I know, i40e HW doesn't provide such ability. > > i40e Receive HW Descriptor can only flag was VLAN tag stripped from the > > packet or not, but if stripping is disabled it wouldn't indicate in any > way is > > VLAN tag is present inside the packet or not. > > I am CC-ing it to dpdk.org in case I am missing something here. > > Probably someone knows a way to make it work in that way. > > Konstantin > > > > > > > > If VPP cannot rely on offload flags for VLAN so packets always have to > go &
[dpdk-dev] [vpp-dev] VLAN packets dropped... ?
Just checking back on this thread to see where things are. Are we saying this is a bug in dpdk or vpp ?. That part wasn't quite clear to me. -Chandra On Thu, May 26, 2016 at 3:56 PM, John Daley (johndale) wrote: > John, > As just discussed, what you suggest was considered but there are other > apps depending a different behavior of the flag, so we thought the best > thing to do is deprecate it. That is part of what Olivier's patch discussed > in http://www.dpdk.org/ml/archives/dev/2016-May/038786.html does. Adding > a new ptype for VLAN tagged packets after the patch is accepted would allow > VPP to check if the ptype is supported by the PMD and if so, use it to > determine if the delivered packet actually has a VLAN tag in it. No need to > know if stripping is enabled/disabled. If the ptype is not supported, the > app would have check the packet in SW. > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John Lo (loj) > > Sent: Thursday, May 26, 2016 11:11 AM > > To: Ananyev, Konstantin ; Wiles, Keith > > ; Chandrasekar Kannan > > Cc: vpp-dev ; Zhang, Helin > intel.com>; > > dev at dpdk.org > > Subject: Re: [dpdk-dev] [vpp-dev] VLAN packets dropped... ? > > > > Hi Konstantin, > > > > Thanks for the link to DPDK discussion wrt this VLAN offload flag > > PKT_RX_VLAN_PKT. It seems the proposal was to deprecate > > PKT_RX_VLAN_PKT and introduce two new flags PKT_RX_VLAN_STRIPPED > > and PKT_RX_QINQ_STRIPPED. > > > > It would be a really good idea to keep PKT_RX_VLAN_PKT to indicate at > least > > one VLAN tag is present on the packet. For the case of i40e where its HW > > cannot detect VLAN tag if strip is not enabled, it should be reasonable > for the > > i40e DPDK driver software to make a check and set this flag. I would > think the > > overhead to check the 1st ethertype field in the MAC header against dot1q > > or dot1ad values in software be pretty minimal. > > > > Regards, > > John > > > > > > -Original Message- > > From: Ananyev, Konstantin [mailto:konstantin.ananyev at intel.com] > > Sent: Wednesday, May 25, 2016 3:23 PM > > To: John Lo (loj); Wiles, Keith; Chandrasekar Kannan > > Cc: vpp-dev; Zhang, Helin; dev at dpdk.org > > Subject: RE: [vpp-dev] VLAN packets dropped... ? > > > > > > > I suppose this has to do with what is expected usage of the > > > PKT_RX_VLAN_PKT offload flag. Is it set only for VLAN packets with the > > > VLAN stripped or should always be set if VLAN is/was present in the > > > received packet. It seems that different DPDK drivers are behaving > > differently which will make it really hard for VPP to take advantage of > NIC > > and driver offload capability to provide better performance. > > > > Yes, that's true ixgbe/igb from one side and i40e do raise > PKT_RX_VLAN_PKT > > in a different manner. > > There is an attempt to make it unified across all supported devices: > > http://dpdk.org/dev/patchwork/patch/12938/ > > > > Though, I am not sure it will help you with your issue. > > As I understand, for you the desired behaviour is: > > If it is a vlan packet, keep the packet intact (don't strip the vlan) > and raise > > PKT_RX_VLAN_PK inside mbuf->ol_flags. > > That's what ixgbe is doing with rte_eth_conf.rxmode.hw_vlan_strip==0. > > Correct? > > As far as I know, i40e HW doesn't provide such ability. > > i40e Receive HW Descriptor can only flag was VLAN tag stripped from the > > packet or not, but if stripping is disabled it wouldn't indicate in any > way is > > VLAN tag is present inside the packet or not. > > I am CC-ing it to dpdk.org in case I am missing something here. > > Probably someone knows a way to make it work in that way. > > Konstantin > > > > > > > > If VPP cannot rely on offload flags for VLAN so packets always have to > go > > through ethernet-input node, there is a performance cost. > > > For the 10GE case, before the inverse patch of the ixgbe driver, 10GE > > > Rx-vector path removed support of offload flag with DPDK 16.04 and so > > > ethernet-input node is always used. The 10GE IPv4 throughput rate > > > dropped from 6.17MPPSx2 to 4.92MPPSx2 for bidirectional traffic (2 > > > streams each with a single IP address as destination) on a single core > > > on my server. Konstantin suggested at that time to use scalar mode > which > > does support offload flags properly. The scalar mode did by-pass > ethernet- > > input and provided throughput of 5.72MPPS.
[dpdk-dev] [vpp-dev] VLAN packets dropped... ?
John, As just discussed, what you suggest was considered but there are other apps depending a different behavior of the flag, so we thought the best thing to do is deprecate it. That is part of what Olivier's patch discussed in http://www.dpdk.org/ml/archives/dev/2016-May/038786.html does. Adding a new ptype for VLAN tagged packets after the patch is accepted would allow VPP to check if the ptype is supported by the PMD and if so, use it to determine if the delivered packet actually has a VLAN tag in it. No need to know if stripping is enabled/disabled. If the ptype is not supported, the app would have check the packet in SW. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John Lo (loj) > Sent: Thursday, May 26, 2016 11:11 AM > To: Ananyev, Konstantin ; Wiles, Keith > ; Chandrasekar Kannan > Cc: vpp-dev ; Zhang, Helin ; > dev at dpdk.org > Subject: Re: [dpdk-dev] [vpp-dev] VLAN packets dropped... ? > > Hi Konstantin, > > Thanks for the link to DPDK discussion wrt this VLAN offload flag > PKT_RX_VLAN_PKT. It seems the proposal was to deprecate > PKT_RX_VLAN_PKT and introduce two new flags PKT_RX_VLAN_STRIPPED > and PKT_RX_QINQ_STRIPPED. > > It would be a really good idea to keep PKT_RX_VLAN_PKT to indicate at least > one VLAN tag is present on the packet. For the case of i40e where its HW > cannot detect VLAN tag if strip is not enabled, it should be reasonable for > the > i40e DPDK driver software to make a check and set this flag. I would think the > overhead to check the 1st ethertype field in the MAC header against dot1q > or dot1ad values in software be pretty minimal. > > Regards, > John > > > -Original Message- > From: Ananyev, Konstantin [mailto:konstantin.ananyev at intel.com] > Sent: Wednesday, May 25, 2016 3:23 PM > To: John Lo (loj); Wiles, Keith; Chandrasekar Kannan > Cc: vpp-dev; Zhang, Helin; dev at dpdk.org > Subject: RE: [vpp-dev] VLAN packets dropped... ? > > > > I suppose this has to do with what is expected usage of the > > PKT_RX_VLAN_PKT offload flag. Is it set only for VLAN packets with the > > VLAN stripped or should always be set if VLAN is/was present in the > > received packet. It seems that different DPDK drivers are behaving > differently which will make it really hard for VPP to take advantage of NIC > and driver offload capability to provide better performance. > > Yes, that's true ixgbe/igb from one side and i40e do raise PKT_RX_VLAN_PKT > in a different manner. > There is an attempt to make it unified across all supported devices: > http://dpdk.org/dev/patchwork/patch/12938/ > > Though, I am not sure it will help you with your issue. > As I understand, for you the desired behaviour is: > If it is a vlan packet, keep the packet intact (don't strip the vlan) and > raise > PKT_RX_VLAN_PK inside mbuf->ol_flags. > That's what ixgbe is doing with rte_eth_conf.rxmode.hw_vlan_strip==0. > Correct? > As far as I know, i40e HW doesn't provide such ability. > i40e Receive HW Descriptor can only flag was VLAN tag stripped from the > packet or not, but if stripping is disabled it wouldn't indicate in any way is > VLAN tag is present inside the packet or not. > I am CC-ing it to dpdk.org in case I am missing something here. > Probably someone knows a way to make it work in that way. > Konstantin > > > > > If VPP cannot rely on offload flags for VLAN so packets always have to go > through ethernet-input node, there is a performance cost. > > For the 10GE case, before the inverse patch of the ixgbe driver, 10GE > > Rx-vector path removed support of offload flag with DPDK 16.04 and so > > ethernet-input node is always used. The 10GE IPv4 throughput rate > > dropped from 6.17MPPSx2 to 4.92MPPSx2 for bidirectional traffic (2 > > streams each with a single IP address as destination) on a single core > > on my server. Konstantin suggested at that time to use scalar mode which > does support offload flags properly. The scalar mode did by-pass ethernet- > input and provided throughput of 5.72MPPS. We ended up inverse patched > the ixgbe driver to restore vector mode offload flag support as the original > restriction (the reason offload flag support was removed) would not affect > VPP. > > > > I think for 40GE driver to provide offload flag support in vector mode > > but not give indication of presence of VLAN tag is just wrong. This make the > offload flag support useless for VPP. > > > > Regards, > > John > > > > -Original Message- > > From: Ananyev, Konstantin [mailto:konstantin.ananyev at intel.com] > > Sent: Wednesday, May 25, 2016 11:30 AM > > To: John Lo (loj); Wiles, Keith; C
[dpdk-dev] [vpp-dev] VLAN packets dropped... ?
Hi Konstantin, Thanks for the link to DPDK discussion wrt this VLAN offload flag PKT_RX_VLAN_PKT. It seems the proposal was to deprecate PKT_RX_VLAN_PKT and introduce two new flags PKT_RX_VLAN_STRIPPED and PKT_RX_QINQ_STRIPPED. It would be a really good idea to keep PKT_RX_VLAN_PKT to indicate at least one VLAN tag is present on the packet. For the case of i40e where its HW cannot detect VLAN tag if strip is not enabled, it should be reasonable for the i40e DPDK driver software to make a check and set this flag. I would think the overhead to check the 1st ethertype field in the MAC header against dot1q or dot1ad values in software be pretty minimal. Regards, John -Original Message- From: Ananyev, Konstantin [mailto:konstantin.anan...@intel.com] Sent: Wednesday, May 25, 2016 3:23 PM To: John Lo (loj); Wiles, Keith; Chandrasekar Kannan Cc: vpp-dev; Zhang, Helin; dev at dpdk.org Subject: RE: [vpp-dev] VLAN packets dropped... ? > I suppose this has to do with what is expected usage of the > PKT_RX_VLAN_PKT offload flag. Is it set only for VLAN packets with the > VLAN stripped or should always be set if VLAN is/was present in the > received packet. It seems that different DPDK drivers are behaving > differently which will make it really hard for VPP to take advantage of NIC > and driver offload capability to provide better performance. Yes, that's true ixgbe/igb from one side and i40e do raise PKT_RX_VLAN_PKT in a different manner. There is an attempt to make it unified across all supported devices: http://dpdk.org/dev/patchwork/patch/12938/ Though, I am not sure it will help you with your issue. As I understand, for you the desired behaviour is: If it is a vlan packet, keep the packet intact (don't strip the vlan) and raise PKT_RX_VLAN_PK inside mbuf->ol_flags. That's what ixgbe is doing with rte_eth_conf.rxmode.hw_vlan_strip==0. Correct? As far as I know, i40e HW doesn't provide such ability. i40e Receive HW Descriptor can only flag was VLAN tag stripped from the packet or not, but if stripping is disabled it wouldn't indicate in any way is VLAN tag is present inside the packet or not. I am CC-ing it to dpdk.org in case I am missing something here. Probably someone knows a way to make it work in that way. Konstantin > > If VPP cannot rely on offload flags for VLAN so packets always have to go > through ethernet-input node, there is a performance cost. > For the 10GE case, before the inverse patch of the ixgbe driver, 10GE > Rx-vector path removed support of offload flag with DPDK 16.04 and so > ethernet-input node is always used. The 10GE IPv4 throughput rate > dropped from 6.17MPPSx2 to 4.92MPPSx2 for bidirectional traffic (2 > streams each with a single IP address as destination) on a single core > on my server. Konstantin suggested at that time to use scalar mode which does > support offload flags properly. The scalar mode did by-pass ethernet-input > and provided throughput of 5.72MPPS. We ended up inverse patched the ixgbe > driver to restore vector mode offload flag support as the original > restriction (the reason offload flag support was removed) would not affect > VPP. > > I think for 40GE driver to provide offload flag support in vector mode > but not give indication of presence of VLAN tag is just wrong. This make the > offload flag support useless for VPP. > > Regards, > John > > -Original Message- > From: Ananyev, Konstantin [mailto:konstantin.ananyev at intel.com] > Sent: Wednesday, May 25, 2016 11:30 AM > To: John Lo (loj); Wiles, Keith; Chandrasekar Kannan > Cc: vpp-dev; Zhang, Helin > Subject: RE: [vpp-dev] VLAN packets dropped... ? > > > > > > I see what you are getting at, Konstantin. The VPP init code does > > not enable VLAN strip for Intel NICs as VLAN tag must be in the > > packet for sub-interface lookup by ethernet-input node. I agree if > > we enable VLAN tag strip for the i40e driver, we can get around this > > problem > but then all packets will be considered as received on the main interface. > > I see... > As far as I know, when VLAN stripping is disabled, i40e RXD doesn't contain > information does that packet contain a VLAN or not. > So, if enabling vlan stripping is not an option for you guys, then I > don't see any other way on i40e to recognise is that VLAN packet or not, > except then parse the packet in SW. > Helin, please correct me here, if I am missing something here. > Thanks > Konstantin > > > > > Regards, > > John > > > > -Original Message- > > From: Ananyev, Konstantin [mailto:konstantin.ananyev at intel.com] > > Sent: Wednesday, May 25, 2016 10:35 AM > > To: John Lo (loj); Wiles, Keith; Chandrasekar Kannan > > Cc: vpp-dev > > Subject: RE: [vpp-dev] VLAN packets dropped... ? > > > > > > > > > > Since this is the XL710 40GE NIC, I suppose the DPDK driver involved > > > would be the i40e driver and not ixgbe for 10GE NICs. > > > > Yes, I understand that you are facing problem
[dpdk-dev] [vpp-dev] VLAN packets dropped... ?
> I suppose this has to do with what is expected usage of the PKT_RX_VLAN_PKT > offload flag. Is it set only for VLAN packets with the > VLAN stripped or should always be set if VLAN is/was present in the received > packet. It seems that different DPDK drivers are > behaving differently which will make it really hard for VPP to take advantage > of NIC and driver offload capability to provide better > performance. Yes, that's true ixgbe/igb from one side and i40e do raise PKT_RX_VLAN_PKT in a different manner. There is an attempt to make it unified across all supported devices: http://dpdk.org/dev/patchwork/patch/12938/ Though, I am not sure it will help you with your issue. As I understand, for you the desired behaviour is: If it is a vlan packet, keep the packet intact (don't strip the vlan) and raise PKT_RX_VLAN_PK inside mbuf->ol_flags. That's what ixgbe is doing with rte_eth_conf.rxmode.hw_vlan_strip==0. Correct? As far as I know, i40e HW doesn't provide such ability. i40e Receive HW Descriptor can only flag was VLAN tag stripped from the packet or not, but if stripping is disabled it wouldn't indicate in any way is VLAN tag is present inside the packet or not. I am CC-ing it to dpdk.org in case I am missing something here. Probably someone knows a way to make it work in that way. Konstantin > > If VPP cannot rely on offload flags for VLAN so packets always have to go > through ethernet-input node, there is a performance cost. > For the 10GE case, before the inverse patch of the ixgbe driver, 10GE > Rx-vector path removed support of offload flag with DPDK 16.04 > and so ethernet-input node is always used. The 10GE IPv4 throughput rate > dropped from 6.17MPPSx2 to 4.92MPPSx2 for bidirectional > traffic (2 streams each with a single IP address as destination) on a single > core on my server. Konstantin suggested at that time to use > scalar mode which does support offload flags properly. The scalar mode did > by-pass ethernet-input and provided throughput of > 5.72MPPS. We ended up inverse patched the ixgbe driver to restore vector mode > offload flag support as the original restriction (the > reason offload flag support was removed) would not affect VPP. > > I think for 40GE driver to provide offload flag support in vector mode but > not give indication of presence of VLAN tag is just wrong. This > make the offload flag support useless for VPP. > > Regards, > John > > -Original Message- > From: Ananyev, Konstantin [mailto:konstantin.ananyev at intel.com] > Sent: Wednesday, May 25, 2016 11:30 AM > To: John Lo (loj); Wiles, Keith; Chandrasekar Kannan > Cc: vpp-dev; Zhang, Helin > Subject: RE: [vpp-dev] VLAN packets dropped... ? > > > > > > I see what you are getting at, Konstantin. The VPP init code does not > > enable VLAN strip for Intel NICs as VLAN tag must be in the packet for > > sub-interface lookup by ethernet-input node. I agree if we enable VLAN tag > > strip for the i40e driver, we can get around this problem > but then all packets will be considered as received on the main interface. > > I see... > As far as I know, when VLAN stripping is disabled, i40e RXD doesn't contain > information does that packet contain a VLAN or not. > So, if enabling vlan stripping is not an option for you guys, then I don't > see any other way on i40e to recognise is that VLAN packet or > not, except then parse the packet in SW. > Helin, please correct me here, if I am missing something here. > Thanks > Konstantin > > > > > Regards, > > John > > > > -Original Message- > > From: Ananyev, Konstantin [mailto:konstantin.ananyev at intel.com] > > Sent: Wednesday, May 25, 2016 10:35 AM > > To: John Lo (loj); Wiles, Keith; Chandrasekar Kannan > > Cc: vpp-dev > > Subject: RE: [vpp-dev] VLAN packets dropped... ? > > > > > > > > > > Since this is the XL710 40GE NIC, I suppose the DPDK driver involved > > > would be the i40e driver and not ixgbe for 10GE NICs. > > > > Yes, I understand that you are facing problem on i40e, not ixgbe. > > And the problem is that for i40e PKT_RX_VLAN_PKT flag is not set in > > mbuf->ol_flags, correct? > > That's why I asked: are you running it with > > rte_eth_conf.rxmode.hw_vlan_strip==0 or not? > > If yes, you can try with rte_eth_conf.rxmode.hw_vlan_strip=1 and see would > > it help you. > > > > > > > > As explained before, ixgbe driver had the inverse patch added. It > > > does recognize VLAN tag in the packet and set PKT_RX_VLAN_PKT offload > > > flag properly: > > > > That patch has nothing to do with PKT_RX_VLAN_PKT and i40e. > > So I don't think it is related to that problem at all. > > Konstantin > > > > > > > > 00:01:02:132370: dpdk-input > > > TenGigabitEthernet5/0/0 rx queue 0 > > > buffer 0x44cff: current data 0, length 96, free-list 0, totlen-nifb 0, > > > trace 0x0 > > > PKT MBUF: port 3, nb_segs 1, pkt_len 96 > > > buf_len 2176, data_len 96, ol_flags 0x1, > > > packet_type 0x210 > > > Packet Offload
