[dpdk-dev] [vpp-dev] VLAN packets dropped... ?

John Lo (loj) loj at cisco.com
Wed Jun 1 22:02:35 CEST 2016


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) <johndale at cisco.com<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 <konstantin.ananyev at intel.com<mailto:konstantin.ananyev at intel.com>>; Wiles, Keith
> <keith.wiles at intel.com<mailto:keith.wiles at intel.com>>; Chandrasekar Kannan <ckannan at console.to<mailto:ckannan at console.to>>
> Cc: vpp-dev <vpp-dev at lists.fd.io<mailto:vpp-dev at lists.fd.io>>; Zhang, Helin <helin.zhang at intel.com<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
> > 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<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<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 Flags
> > > >       PKT_RX_VLAN_PKT (0x0001) RX packet is a 802.1q VLAN packet
> > > >     Packet Types
> > > >       RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension
> headers
> > > >       RTE_PTYPE_L4_UDP (0x0200) UDP packet
> > > >   IP4: 00:00:00:00:00:aa -> 90:e2:ba:6e:e7:dc vlan 1101
> > > >   UDP: 28.0.0.1 -> 29.0.0.254
> > > >     tos 0x00, ttl 64, length 78, checksum 0x40a1
> > > >     fragment id 0x0000
> > > >   UDP: 63 -> 63
> > > >     length 58, checksum 0x5b76
> > > > 00:01:02:132391: ethernet-input
> > > >   IP4: 00:00:00:00:00:aa -> 90:e2:ba:6e:e7:dc vlan 1101
> > > > 00:01:02:132408: error-drop
> > > >   ethernet-input: unknown vlan
> > > >
> > > > You can see from above the packet was passed to ethernet-input
> > > > node and dropped because sub-interface for VLAN 1101 is not set up.
> > > >
> > > > Regards,
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: Ananyev, Konstantin [mailto:konstantin.ananyev at intel.com<mailto:konstantin.ananyev at intel.com>]
> > > > Sent: Wednesday, May 25, 2016 4:46 AM
> > > > To: John Lo (loj); Wiles, Keith; Chandrasekar Kannan
> > > > Cc: vpp-dev
> > > > Subject: RE: [vpp-dev] VLAN packets dropped... ?
> > > >
> > > >
> > > > Hi,
> > > > I don’t think ptype recognition on ixgbe vRX is somehow related to that.
> > > > Are you guys running FVL with
> rte_eth_conf.rxmode.hw_vlan_strip==0?
> > > > If so, can you set it to 1 and see would it help?
> > > > Konstantin
> > > >
> > > > From: vpp-dev-bounces at lists.fd.io<mailto:vpp-dev-bounces at lists.fd.io>
> > > > [mailto:vpp-dev-bounces at lists.fd.io<mailto:vpp-dev-bounces at lists.fd.io>]
> > > > On Behalf Of John Lo (loj)
> > > > Sent: Wednesday, May 25, 2016 1:56 AM
> > > > To: Wiles, Keith; Chandrasekar Kannan
> > > > Cc: vpp-dev
> > > > Subject: Re: [vpp-dev] VLAN packets dropped... ?
> > > >
> > > > I did put in a reverse patch, provided by Damjan, for this in fd.io<http://fd.io>:
> > > > https://gerrit.fd.io/r/#/c/941/1/dpdk/dpdk-16.04_patches/0013-Reve
> > > > rt -i xgbe-fix-packet-type-from-vector-Rx.patch
> > > >
> > > > I know this fixed the 10GE NIC behavior. Perhaps the 40GE NIC is using a
> different DPDK driver?
> > > >
> > > > Regards,
> > > > John
> > > >
> > > > From: Wiles, Keith [mailto:keith.wiles at intel.com<mailto:keith.wiles at intel.com>]
> > > > Sent: Tuesday, May 24, 2016 8:30 PM
> > > > To: John Lo (loj); Chandrasekar Kannan
> > > > Cc: vpp-dev
> > > > Subject: Re: [vpp-dev] VLAN packets dropped... ?
> > > >
> > > >
> > > > The commit ID is
> > > >
> > > > commit d9a2009a81089093645fea2e04b51dd37edf3e6f
> > > > Author: Konstantin Ananyev <konstantin.ananyev at intel.com<mailto:konstantin.ananyev at intel.com>>
> > > > Date:   Tue Mar 22 14:30:17 2016 +0000
> > > >
> > > >     ixgbe: fix packet type from vector Rx
> > > >
> > > >     Current vector RX can't always set the packet_type properly.
> > > >     To be more specific:
> > > >     a) it never sets RTE_PTYPE_L2_ETHER
> > > >     b) it doesn't handle tunnel ipv4/ipv6 case correctly.
> > > >     c) it doesn't check is IXGBE_RXDADV_PKTTYPE_ETQF set or not.
> > > >     While a) is pretty easy to fix, b) and c) are not that
> > > > straightforward
> > > >     in terms of SIMD ops (specially b).
> > > >     So far I wasn't able to make vRX support packet_type properly
> > > > without
> > > >     noticeable performance loss.
> > > >     So for now, just remove that functionality from vector RX and
> > > >     update dev_supported_ptypes_get().
> > > >
> > > >     Fixes: 396254175854 ("mbuf: redefine packet type")
> > > >
> > > >     Signed-off-by: Konstantin Ananyev
> > > > <konstantin.ananyev at intel.com<mailto:konstantin.ananyev at intel.com>>
> > > >     Acked-by: Cunming Liang <cunming.liang at intel.com<mailto:cunming.liang at intel.com>>
> > > >
> > > > It appears the change was only down to the vector version in the RX
> routine, could move to the none-vector version I guess.
> > > >
> > > > I would think adding a patch or adding the code to VPP DPDK init to use
> the RX callback to setup things correctly.
> > > >
> > > > Regards,
> > > > Keith
> > > >
> > > >
> > > > From: <vpp-dev-bounces at lists.fd.io<mailto:vpp-dev-bounces at lists.fd.io>> on behalf of Keith Wiles
> > > > <keith.wiles at intel.com<mailto:keith.wiles at intel.com>>
> > > > Date: Tuesday, May 24, 2016 at 7:19 PM
> > > > To: "John Lo (loj)" <loj at cisco.com<mailto:loj at cisco.com>>, Chandrasekar Kannan
> > > > <ckannan at console.to<mailto:ckannan at console.to>>
> > > > Cc: vpp-dev <vpp-dev at lists.fd.io<mailto:vpp-dev at lists.fd.io>>
> > > > Subject: Re: [vpp-dev] VLAN packets dropped... ?
> > > >
> > > >
> > > > Here is the starting thread:
> > > > http://dpdk.org/ml/archives/dev/2016-April/037837.html
> > > >
> > > >
> > > > Regards,
> > > > Keith
> > > >
> > > >
> > > > From: <vpp-dev-bounces at lists.fd.io<mailto:vpp-dev-bounces at lists.fd.io>> on behalf of Keith Wiles
> > > > <keith.wiles at intel.com<mailto:keith.wiles at intel.com>>
> > > > Date: Tuesday, May 24, 2016 at 7:16 PM
> > > > To: "John Lo (loj)" <loj at cisco.com<mailto:loj at cisco.com>>, Chandrasekar Kannan
> > > > <ckannan at console.to<mailto:ckannan at console.to>>
> > > > Cc: vpp-dev <vpp-dev at lists.fd.io<mailto:vpp-dev at lists.fd.io>>
> > > > Subject: Re: [vpp-dev] VLAN packets dropped... ?
> > > >
> > > > The flags in the rte_mbuf were changed a before 16.04, which
> > > > removed the ptype testing and possible setting this flag. I thought a
> patch to revert that change was done, did that not happen.
> > > >
> > > > The other solution is to add an option to DPDK to restore the
> > > > previous behavior for this type of problem. The only other way is
> > > > to have a installed in the PMD to setup the flags correctly for VPP.
> > > > This would require adding a routine to VPP and setting the call
> > > > back in the
> > > driver.
> > > >
> > > > I really thought a patch was created, does anyone know?
> > > >
> > > > Regards,
> > > > Keith
> > > >
> > > >
> > > > From: "John Lo (loj)" <loj at cisco.com<mailto:loj at cisco.com>>
> > > > Date: Tuesday, May 24, 2016 at 6:53 PM
> > > > To: Chandrasekar Kannan <ckannan at console.to<mailto:ckannan at console.to>>
> > > > Cc: Keith Wiles <keith.wiles at intel.com<mailto:keith.wiles at intel.com>>, vpp-dev
> > > > <vpp-dev at lists.fd.io<mailto:vpp-dev at lists.fd.io>>
> > > > Subject: RE: [vpp-dev] VLAN packets dropped... ?
> > > >
> > > > I believe the problem is due to 40GE DPDK driver not parsing VLAN
> > > > packet properly and setting the packet offload flag
> > > > PKT_RX_VLAN_PKT, causing dpdk-input node to send packet directly
> > > > to ip4-input instead of ethernet-input. If this flag is set, then
> > > > the packet will be passed to ethernet-input which will then parse
> > > > the VLAN tag in the
> > > packet to perform sub-interface lookup and find the start of IP
> > > header in the packet properly. Following is an example trace of a correctly
> marked packet:
> > > >
> > > > 23:11:09:855916: dpdk-input
> > > >   TenGigE0/0/0/0 rx queue 0
> > > >   buffer 0x23f6c0: current data 0, length 118, free-list 0,
> > > > totlen-nifb 0, trace 0x0
> > > >   PKT MBUF: port 0, nb_segs 1, pkt_len 118
> > > >     buf_len 2176, data_len 118, ol_flags 0x1,
> > > >     packet_type 0x10
> > > >     Packet Offload Flags
> > > >       PKT_RX_VLAN_PKT (0x0001) RX packet is a 802.1q VLAN packet
> > > >     Packet Types
> > > >       RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension
> > > > headers
> > > >   IP4: 74:a0:2f:e2:d5:14 -> 90:e2:ba:9f:8b:cc vlan 101
> > > >   ICMP: 130.1.1.1 -> 130.1.1.2
> > > >     tos 0x00, ttl 255, length 100, checksum 0xac4b
> > > >     fragment id 0x0948
> > > >   ICMP echo_request checksum 0x900d
> > > >
> > > > Hoping someone familiar with the 40GE DPDK driver can comment
> further.
> > > >
> > > > Regards,
> > > > John
> > > >
> > > > From: Chandrasekar Kannan [mailto:ckannan at console.to<mailto:ckannan at console.to>]
> > > > Sent: Tuesday, May 24, 2016 6:57 PM
> > > > To: John Lo (loj)
> > > > Cc: Wiles, Keith; vpp-dev
> > > > Subject: Re: [vpp-dev] VLAN packets dropped... ?
> > > >
> > > > Yes. Subinterface has been configured like this  ...
> > > >
> > > > vppctl set interface ip address del FortyGigabitEthernet83/0/0 all
> > > > vppctl create sub FortyGigabitEthernet83/0/0 900 vppctl set
> > > > interface ip address FortyGigabitEthernet83/0/0.900 6.0.0.1/24<http://6.0.0.1/24>
> > > > vppctl set interface ip address FortyGigabitEthernet83/0/0.900
> > > > 7.0.0.1/24<http://7.0.0.1/24> vppctl set interface state FortyGigabitEthernet83/0/0
> > > > up vppctl set interface state FortyGigabitEthernet83/0/0.900 up
> > > > vppctl set ip arp static
> > > > FortyGigabitEthernet83/0/0.900 7.0.0.2 3c:fd:fe:9c:c3:88
> > > >
> > > > --------------------------------------------------
> > > > Packet 4
> > > >
> > > > 00:02:23:366879: dpdk-input
> > > >   FortyGigabitEthernet83/0/0 rx queue 0
> > > >   buffer 0x10e6b: current data 14, length 50, free-list 0,
> > > > totlen-nifb 0, trace 0x3
> > > >   PKT MBUF: port 0, nb_segs 1, pkt_len 64
> > > >     buf_len 2176, data_len 64, ol_flags 0x0,
> > > >     packet_type 0x291
> > > >     Packet Types
> > > >       RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
> > > >       RTE_PTYPE_L3_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or
> > > > without extension headers
> > > >       RTE_PTYPE_L4_UDP (0x0200) UDP packet
> > > >   IP4: 3c:fd:fe:9c:c3:88 -> 3c:fd:fe:9d:a0:20 vlan 900
> > > >   UDP: 6.0.0.2 -> 7.0.0.2
> > > >     tos 0x00, ttl 64, length 46, checksum 0x2dbc
> > > >     fragment id 0x0000, flags DONT_FRAGMENT
> > > >   UDP: 1024 -> 2001
> > > >     length 26, checksum 0x0000
> > > > 00:02:23:366894: ip4-input-no-checksum
> > > >   IP6_HOP_BY_HOP_OPTIONS: 64.17.45.188 -> 6.0.0.2
> > > >     version 0, header length 12
> > > >     tos 0x84, ttl 0, length 2048, checksum 0x4000 (should be
> > > > 0xaf4d)
> > > >     fragment id 0x4500 offset 368, flags
> > > > 00:02:23:366910: error-drop
> > > >   ip4-input: ip4 length > l2 length
> > > >
> > > > --------------------------------------------------------------
> > > >
> > > >
> > > >
> > > > On Tue, May 24, 2016 at 3:12 PM, John Lo (loj) <loj at cisco.com<mailto:loj at cisco.com>> wrote:
> > > > Was a sub-interface created with the expected VLAN tag 900? An
> > > > example of creating a sub-interface and bring it up would be something
> like:
> > > >
> > > > create sub GigabitEthernet1/0/0 900 set int state
> > > > GigabitEthernet1/0/0 up set int state
> > > > GigabitEthernet1/0/0.900 up
> > > >
> > > > Regards,
> > > > John
> > > >
> > > >
> > > > From: vpp-dev-bounces at lists.fd.io<mailto:vpp-dev-bounces at lists.fd.io>
> > > > [mailto:vpp-dev-bounces at lists.fd.io<mailto:vpp-dev-bounces at lists.fd.io>]
> > > > On Behalf Of Wiles, Keith
> > > > Sent: Tuesday, May 24, 2016 5:59 PM
> > > > To: Chandrasekar Kannan; vpp-dev
> > > > Subject: Re: [vpp-dev] VLAN packets dropped... ?
> > > >
> > > > I am starting to think the unknown VLAN is not accounted for in the
> processing of the input frame in the VPP DPDK interface code.
> > > > vnet/vnet/devices/dpdk/node.c
> > > >
> > > > The version and header length are wrong in the output below, which
> > > > leads me to believe the starting IPv4 header location is wrong. I
> > > > have not parsed all of the code in node.c:dpdk_device_input() yet,
> > > > but I do not think the l3_offset is being adjusted to the correct
> > > offset????
> > > >
> > > > Regards,
> > > > Keith
> > > >
> > > >
> > > > From: <vpp-dev-bounces at lists.fd.io<mailto:vpp-dev-bounces at lists.fd.io>> on behalf of Chandrasekar
> > > > Kannan <ckannan at console.to<mailto:ckannan at console.to>>
> > > > Date: Tuesday, May 24, 2016 at 3:40 PM
> > > > To: vpp-dev <vpp-dev at lists.fd.io<mailto:vpp-dev at lists.fd.io>>
> > > > Subject: [vpp-dev] VLAN packets dropped... ?
> > > >
> > > > Hi,
> > > >
> > > > I was trying to setup VLAN subinterfaces with VPP but it appears
> > > > the packets are dropped at ingress.  I'm tried with both
> > > > pktgen-dpdk and trex for traffic generation just to rule out any
> > > > corruption with
> > > pkt generation. But both are producing the same errors with vpp.
> > > >
> > > > yaml file from trex...
> > > >
> > > > ------------------------------
> > > > [root at node04 scripts]# cat cap2/ipv4_vlan.yaml
> > > > - duration : 10
> > > >   generator :
> > > >           distribution : "seq"
> > > >           clients_start : "16.0.0.1"
> > > >           clients_end   : "16.0.1.255"
> > > >           servers_start : "48.0.0.1"
> > > >           servers_end   : "48.0.0.255"
> > > >           clients_per_gb : 201
> > > >           min_clients    : 101
> > > >           dual_port_mask : "1.0.0.0"
> > > >           tcp_aging      : 1
> > > >           udp_aging      : 1
> > > >   mac        : [0x0,0x0,0x0,0x1,0x0,0x00]
> > > >   vlan       : { enable : 1  ,  vlan0 : 900 , vlan1 : 1100 }
> > > >   cap_info :
> > > >      - name: cap2/udp_64B.pcap
> > > >        cps   : 1000.0
> > > >        ipg   : 10000
> > > >        rtt   : 10000
> > > >        w     : 4
> > > >        limit : 20
> > > > [root at node04 scripts]#
> > > > ---------------------------------------------------------------
> > > >
> > > > vpp trace...
> > > >
> > > > 00:02:21:576810: dpdk-input
> > > >   FortyGigabitEthernet83/0/0 rx queue 0
> > > >   buffer 0x10e6b: current data 14, length 50, free-list 0,
> > > > totlen-nifb 0, trace 0x1
> > > >   PKT MBUF: port 0, nb_segs 1, pkt_len 64
> > > >     buf_len 2176, data_len 64, ol_flags 0x0,
> > > >     packet_type 0x291
> > > >     Packet Types
> > > >       RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
> > > >       RTE_PTYPE_L3_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or
> > > > without extension headers
> > > >       RTE_PTYPE_L4_UDP (0x0200) UDP packet
> > > >   IP4: 3c:fd:fe:9c:c3:88 -> 3c:fd:fe:9d:a0:20 vlan 900
> > > >   UDP: 16.0.1.0 -> 48.0.0.128
> > > >     tos 0x00, ttl 64, length 46, checksum 0xf93f
> > > >     fragment id 0x0000, flags DONT_FRAGMENT
> > > >   UDP: 1024 -> 2001
> > > >     length 26, checksum 0x0000
> > > > 00:02:21:576817: ip4-input-no-checksum
> > > >   IP6_HOP_BY_HOP_OPTIONS: 64.17.249.63 -> 16.0.1.0
> > > >     version 0, header length 12
> > > >     tos 0x84, ttl 0, length 2048, checksum 0x4000 (should be
> > > > 0xaf4d)
> > > >     fragment id 0x4500 offset 368, flags
> > > > 00:02:21:576828: error-drop
> > > >   ip4-input: ip4 length > l2 length
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >



More information about the dev mailing list