[vpp-dev] VPP as IPsec gateway with destination packets for application process on same NUMA node

2017-11-16 Thread Ran Yaniv
Hi,
We want to use VPP for terminating an IPsec tunnel, and forward the inner IP 
packets to another (application) process on the same NUMA node. 
What are the options for doing that, other than forwarding the packets through 
the Kernel ip stack? 
The application process itself is built to receive packets using a DPDK polling 
thread.

Thanks!
Ran

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev


[vpp-dev] vpp continuous integration on armv8

2017-11-16 Thread Gabriel Ganne
Hi,


We've been working on preparing vpp for armv8 continuous testing (See 
https://wiki.fd.io/view/VPP/AArch64),

and we think that we now have everything which is required to add arm as ci 
platform in the vpp review process (build, test and packaging). All the test 
have been done on "native".

Also 3 thunderX platforms sent by ARM should have arrived yesterday in the fdio 
lab.


I *think* that all that is required should be to set the platforms with VMs on 
it, and add them as build slaves.


How should we proceed from here ?


--

Gabriel Ganne

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Flowprobe Question

2017-11-16 Thread MUEDSAM, JOHAN
Thanks Ole, got it working after running the tests and digging through the test 
code. I'm able to capture and parse the IPFIX output from the Flowprobe plugin.

I have another question. I'm going through the examples, specifically the 
"Progressive Tutorial - Source NAT" and "VPP/Configure VPP As A Router Between 
Namespaces".

I get the examples working as is, however they only allow ICMP traffic through, 
TCP and UDP gets dropped somewhere and can't get through.

Do I need to change the setup to get TCP/UDP to go through? 

/Johan 

On 11/13/17, 10:53 AM, "Ole Troan"  wrote:

Hi Johan,

You have a route to 192.168.65.2?
Nothing shows up in "show error"?

You can look at test/test_flowprobe.py
for examples. And you might also try a make test TEST=flowprobe to ensure 
your build works.

On second pass on your configuration.
You have enabled flow collection in the L2 path, if you are IP forwarding 
you need to enable it in the L3 path.
> vppctl flowprobe feature add-del host-vpp1out l3

Cheers,
Ole


> On 14 Nov 2017, at 00:38, MUEDSAM, JOHAN  wrote:
> 
> Hi,
> 
> I'm trying to capture IPFIX records of traffic on my VPP managed 
interfaces. So far I haven't been able to see any templates or IPFIX records in 
my collector.
> 
> Here's my VPP setup (from the progressive tutorial), I'm using a docker 
container with Ubuntu 16.04 and the binary VPP master release:
> ip link add name vpp1out type veth peer name vpp1host
> ip link set dev vpp1out up
> ip link set dev vpp1host up
> ip addr add 10.10.1.1/24 dev vpp1host
> ip addr show vpp1host
> vppctl create host-interface name vpp1out
> vppctl show hardware
> vppctl set int state host-vpp1out up
> vppctl show int
> vppctl set int ip address host-vpp1out 10.10.1.2/24
> vppctl show int addr
> 
> Flowprobe setup, here I'm using non VPP managed IPs to setup source and 
collector addresses:
> vppctl flowprobe params record l2 l3 l4 active 20 passive 120
> vppctl flowprobe feature add-del host-vpp1out l2
> vppctl set ipfix exporter collector 192.168.65.2 src 192.168.65.2 
template-interval 20 port 4739 path-mtu 1450
> 
> I generate traffic by pinging the 10.10.1.2 address above.
> And I'm currently listening on the collector UDP port using this to 
detect IPFIX data coming from VPP: nc -l -u 192.168.65.2 -p 4739
> I can see traffic in the Flowprobe table but as I mentioned I get nothing 
on the UDP collector interface.
> 
> Any ideas of why I'm not seeing any IPFIX data (not even templates) on 
the UDP port?
> Is there a working e2e example of how to use Flowprobe I could start with?
> 
> Any pointers would be greatly appreciated.
> 
> Thanks,
> Johan
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev



___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] vpp continuous integration on armv8

2017-11-16 Thread Ed Warnicke
Gabriel,

This is awesome news!

Do I understand correctly that these ThunderX boards are intended to be
used for build/make test/packaging?  If so, I've cced in Vanessa, our
fearless sysadmin to help in figuring these things out :)

Do you have opinions about which Linux distributions you want to package
for (Ubuntu?, Centos?) and versions?

Ed

On Thu, Nov 16, 2017 at 5:27 AM Gabriel Ganne 
wrote:

> Hi,
>
>
> We've been working on preparing vpp for armv8 continuous testing (See
> https://wiki.fd.io/view/VPP/AArch64),
>
> and we think that we now have everything which is required to add arm as
> ci platform in the vpp review process (build, test and packaging). All the
> test have been done on "native".
>
> Also 3 thunderX platforms sent by ARM should have arrived yesterday in the
> fdio lab.
>
> I *think* that all that is required should be to set the platforms with
> VMs on it, and add them as build slaves.
>
>
> How should we proceed from here ?
>
>
> --
> Gabriel Ganne
>
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] vpp continuous integration on armv8

2017-11-16 Thread Gabriel Ganne
Yes, they are.

I estimate it should take about 40 minutes to build and test with 8 cores in 
release mode, therefore I do not think that using all 3 ThunderX is necessary.

I do not have access to a ThunderX platform on my side (I ran my tests on NXP 
and Hierofalcon platforms), if needed please see with Tina Tsou (in CC) for the 
specifics of ThunderX.


I was thinking about duplicating the *vpp-verify-master-ubuntu1604* target as a 
first step.

Ubuntu 16.04 is a LTS for armv8 and is one of the distributions already used 
for vpp x86 continuous testing.


If all goes well, I was thinking about using fedora-26 (or above) as rhel-based 
distribution, since it also has aarch64 official support.

But since it's not one of the distros already used in ci, let's keep it for 
later.


Regards,


--

Gabriel Ganne


From: Ed Warnicke 
Sent: Thursday, November 16, 2017 4:47:14 PM
To: Gabriel Ganne
Cc: vpp-dev; Dave Barach (dbarach); Nicolas Bouthors; csit-...@lists.fd.io; 
Vanessa Valderrama
Subject: Re: [vpp-dev] vpp continuous integration on armv8

Gabriel,

This is awesome news!

Do I understand correctly that these ThunderX boards are intended to be used 
for build/make test/packaging?  If so, I've cced in Vanessa, our fearless 
sysadmin to help in figuring these things out :)

Do you have opinions about which Linux distributions you want to package for 
(Ubuntu?, Centos?) and versions?

Ed

On Thu, Nov 16, 2017 at 5:27 AM Gabriel Ganne 
mailto:gabriel.ga...@enea.com>> wrote:

Hi,


We've been working on preparing vpp for armv8 continuous testing (See 
https://wiki.fd.io/view/VPP/AArch64),

and we think that we now have everything which is required to add arm as ci 
platform in the vpp review process (build, test and packaging). All the test 
have been done on "native".

Also 3 thunderX platforms sent by ARM should have arrived yesterday in the fdio 
lab.


I *think* that all that is required should be to set the platforms with VMs on 
it, and add them as build slaves.


How should we proceed from here ?


--

Gabriel Ganne


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] FOSDEM 2018

2017-11-16 Thread Kinsella, Ray

Folks,

The Call for Content for FOSDEM 2018 is closing today!
The "SDN and NFV room" at FOSDEM is great way to get the FD.io message 
out there.


Last minute submissions would be most welcome!
To submit see,

https://blogs.gnome.org/bolsh/2017/11/01/fosdem-2018-sdnnfv-devroom-call-for-content/

Thanks,

Ray K

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev


[vpp-dev] Mapping multiple FIBs from Linux to VPP

2017-11-16 Thread Michael Borokhovich
Hi,

I can see in "vppsb/netlink/librtnl/mapper.h" that each Linux namespace is
mapped to a separate FIB in VPP.

However, the 4.6 Linux kernel has support for VRFs (e.g., using "ip link
add dev NAME type vrf table ID").

If we use the second (VRFs) approach to create multiple FIBs in Linux, can
the Router-Plugin synchronize them with the VPP FIBs? Or we must use
namespaces approach in Linux?

Thanks,
Michael.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] vpp continuous integration on armv8

2017-11-16 Thread Ed Warnicke
Gabriel,

We do need to have multiple workers to service the verify queue... having
the queue back up behind a single server wouldn't be good.  Do you know if
these boxes are installed with Ubuntu 16.04 already?

Ed

On Thu, Nov 16, 2017 at 9:03 AM Gabriel Ganne 
wrote:

> Yes, they are.
>
> I estimate it should take about 40 minutes to build and test with 8 cores
> in release mode, therefore I do not think that using all 3 ThunderX is
> necessary.
>
> I do not have access to a ThunderX platform on my side (I ran my tests on
> NXP and Hierofalcon platforms), if needed please see with Tina Tsou (in CC)
> for the specifics of ThunderX.
>
>
> I was thinking about duplicating the *vpp-verify-master-ubuntu1604*
> target as a first step.
>
> Ubuntu 16.04 is a LTS for armv8 and is one of the distributions already
> used for vpp x86 continuous testing.
>
>
> If all goes well, I was thinking about using fedora-26 (or above) as
> rhel-based distribution, since it also has aarch64 official support.
>
> But since it's not one of the distros already used in ci, let's keep it
> for later.
>
>
> Regards,
>
>
> --
>
> Gabriel Ganne
> --
> *From:* Ed Warnicke 
> *Sent:* Thursday, November 16, 2017 4:47:14 PM
> *To:* Gabriel Ganne
> *Cc:* vpp-dev; Dave Barach (dbarach); Nicolas Bouthors;
> csit-...@lists.fd.io; Vanessa Valderrama
> *Subject:* Re: [vpp-dev] vpp continuous integration on armv8
>
> Gabriel,
>
> This is awesome news!
>
> Do I understand correctly that these ThunderX boards are intended to be
> used for build/make test/packaging?  If so, I've cced in Vanessa, our
> fearless sysadmin to help in figuring these things out :)
>
> Do you have opinions about which Linux distributions you want to package
> for (Ubuntu?, Centos?) and versions?
>
> Ed
>
> On Thu, Nov 16, 2017 at 5:27 AM Gabriel Ganne 
> wrote:
>
> Hi,
>
>
> We've been working on preparing vpp for armv8 continuous testing (See
> https://wiki.fd.io/view/VPP/AArch64
> 
> ),
>
> and we think that we now have everything which is required to add arm as
> ci platform in the vpp review process (build, test and packaging). All the
> test have been done on "native".
>
> Also 3 thunderX platforms sent by ARM should have arrived yesterday in the
> fdio lab.
>
> I *think* that all that is required should be to set the platforms with
> VMs on it, and add them as build slaves.
>
>
> How should we proceed from here ?
>
>
> --
> Gabriel Ganne
>
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
> 
>
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] vpp continuous integration on armv8

2017-11-16 Thread Tina Tsou
Dear Ed,

What arrived in Canada yesterday were 3x OD1000 for build only.

3 ThunderX are still in process, waiting to be quoted, billed, and shipped, 
they are also for VPP build only.
3x http://b2b.gigabyte.com/ARM-Server/R150-T60-rev-110#ov


Thank you,
Tina Tsou
Enterprise Architect
Arm
tina.t...@arm.com
+1 (408)931-3833

From: Ed Warnicke [mailto:hagb...@gmail.com]
Sent: Thursday, November 16, 2017 3:32 PM
To: Gabriel Ganne 
Cc: vpp-dev ; Dave Barach (dbarach) ; 
Nicolas Bouthors ; csit-...@lists.fd.io; Vanessa 
Valderrama ; Tina Tsou 
Subject: Re: [vpp-dev] vpp continuous integration on armv8

Gabriel,

We do need to have multiple workers to service the verify queue... having the 
queue back up behind a single server wouldn't be good.  Do you know if these 
boxes are installed with Ubuntu 16.04 already?

Ed

On Thu, Nov 16, 2017 at 9:03 AM Gabriel Ganne 
mailto:gabriel.ga...@enea.com>> wrote:

Yes, they are.

I estimate it should take about 40 minutes to build and test with 8 cores in 
release mode, therefore I do not think that using all 3 ThunderX is necessary.

I do not have access to a ThunderX platform on my side (I ran my tests on NXP 
and Hierofalcon platforms), if needed please see with Tina Tsou (in CC) for the 
specifics of ThunderX.



I was thinking about duplicating the *vpp-verify-master-ubuntu1604* target as a 
first step.

Ubuntu 16.04 is a LTS for armv8 and is one of the distributions already used 
for vpp x86 continuous testing.



If all goes well, I was thinking about using fedora-26 (or above) as rhel-based 
distribution, since it also has aarch64 official support.

But since it's not one of the distros already used in ci, let's keep it for 
later.



Regards,



--

Gabriel Ganne


From: Ed Warnicke mailto:hagb...@gmail.com>>
Sent: Thursday, November 16, 2017 4:47:14 PM
To: Gabriel Ganne
Cc: vpp-dev; Dave Barach (dbarach); Nicolas Bouthors; 
csit-...@lists.fd.io; Vanessa Valderrama
Subject: Re: [vpp-dev] vpp continuous integration on armv8

Gabriel,

This is awesome news!

Do I understand correctly that these ThunderX boards are intended to be used 
for build/make test/packaging?  If so, I've cced in Vanessa, our fearless 
sysadmin to help in figuring these things out :)

Do you have opinions about which Linux distributions you want to package for 
(Ubuntu?, Centos?) and versions?

Ed

On Thu, Nov 16, 2017 at 5:27 AM Gabriel Ganne 
mailto:gabriel.ga...@enea.com>> wrote:

Hi,



We've been working on preparing vpp for armv8 continuous testing (See 
https://wiki.fd.io/view/VPP/AArch64),

and we think that we now have everything which is required to add arm as ci 
platform in the vpp review process (build, test and packaging). All the test 
have been done on "native".

Also 3 thunderX platforms sent by ARM should have arrived yesterday in the fdio 
lab.


I *think* that all that is required should be to set the platforms with VMs on 
it, and add them as build slaves.



How should we proceed from here ?



--
Gabriel Ganne


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [csit-dev] vpp continuous integration on armv8

2017-11-16 Thread Luke, Chris
Ed,

Based on Tina saying the ones delivered are OD1000’s, Overdrive machines seem 
to come from the factory with Suse on them according to their website.

Chris.

From: csit-dev-boun...@lists.fd.io [mailto:csit-dev-boun...@lists.fd.io] On 
Behalf Of Ed Warnicke
Sent: Thursday, November 16, 2017 18:32
To: Gabriel Ganne 
Cc: csit-...@lists.fd.io; Dave Barach (dbarach) ; Tina Tsou 
; vpp-dev ; Nicolas Bouthors 

Subject: Re: [csit-dev] [vpp-dev] vpp continuous integration on armv8

Gabriel,

We do need to have multiple workers to service the verify queue... having the 
queue back up behind a single server wouldn't be good.  Do you know if these 
boxes are installed with Ubuntu 16.04 already?

Ed

On Thu, Nov 16, 2017 at 9:03 AM Gabriel Ganne 
mailto:gabriel.ga...@enea.com>> wrote:

Yes, they are.

I estimate it should take about 40 minutes to build and test with 8 cores in 
release mode, therefore I do not think that using all 3 ThunderX is necessary.

I do not have access to a ThunderX platform on my side (I ran my tests on NXP 
and Hierofalcon platforms), if needed please see with Tina Tsou (in CC) for the 
specifics of ThunderX.



I was thinking about duplicating the *vpp-verify-master-ubuntu1604* target as a 
first step.

Ubuntu 16.04 is a LTS for armv8 and is one of the distributions already used 
for vpp x86 continuous testing.



If all goes well, I was thinking about using fedora-26 (or above) as rhel-based 
distribution, since it also has aarch64 official support.

But since it's not one of the distros already used in ci, let's keep it for 
later.



Regards,



--

Gabriel Ganne


From: Ed Warnicke mailto:hagb...@gmail.com>>
Sent: Thursday, November 16, 2017 4:47:14 PM
To: Gabriel Ganne
Cc: vpp-dev; Dave Barach (dbarach); Nicolas Bouthors; 
csit-...@lists.fd.io; Vanessa Valderrama
Subject: Re: [vpp-dev] vpp continuous integration on armv8

Gabriel,

This is awesome news!

Do I understand correctly that these ThunderX boards are intended to be used 
for build/make test/packaging?  If so, I've cced in Vanessa, our fearless 
sysadmin to help in figuring these things out :)

Do you have opinions about which Linux distributions you want to package for 
(Ubuntu?, Centos?) and versions?

Ed

On Thu, Nov 16, 2017 at 5:27 AM Gabriel Ganne 
mailto:gabriel.ga...@enea.com>> wrote:

Hi,



We've been working on preparing vpp for armv8 continuous testing (See 
https://wiki.fd.io/view/VPP/AArch64),

and we think that we now have everything which is required to add arm as ci 
platform in the vpp review process (build, test and packaging). All the test 
have been done on "native".

Also 3 thunderX platforms sent by ARM should have arrived yesterday in the fdio 
lab.


I *think* that all that is required should be to set the platforms with VMs on 
it, and add them as build slaves.



How should we proceed from here ?



--
Gabriel Ganne


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [csit-dev] vpp continuous integration on armv8

2017-11-16 Thread George Zhao
If I understand this correctly,  Tina wants these Arm machines to be used as 
build/HW validation. I am cc-ing our folks in Huawei, who are going to work in 
the community on CSIT to see if they can provide any help, contact person would 
be Appana Prasad and Khemendra Kumar.

Thanks,
George

From: csit-dev-boun...@lists.fd.io [mailto:csit-dev-boun...@lists.fd.io] On 
Behalf Of Luke, Chris
Sent: Thursday, November 16, 2017 4:45 PM
To: Ed Warnicke ; Gabriel Ganne 
Cc: csit-...@lists.fd.io; Dave Barach (dbarach) ; Tina Tsou 
; vpp-dev ; Nicolas Bouthors 

Subject: Re: [csit-dev] [vpp-dev] vpp continuous integration on armv8

Ed,

Based on Tina saying the ones delivered are OD1000’s, Overdrive machines seem 
to come from the factory with Suse on them according to their website.

Chris.

From: csit-dev-boun...@lists.fd.io 
[mailto:csit-dev-boun...@lists.fd.io] On Behalf Of Ed Warnicke
Sent: Thursday, November 16, 2017 18:32
To: Gabriel Ganne mailto:gabriel.ga...@enea.com>>
Cc: csit-...@lists.fd.io; Dave Barach (dbarach) 
mailto:dbar...@cisco.com>>; Tina Tsou 
mailto:tina.t...@arm.com>>; vpp-dev 
mailto:vpp-dev@lists.fd.io>>; Nicolas Bouthors 
mailto:nicolas.bouth...@enea.com>>
Subject: Re: [csit-dev] [vpp-dev] vpp continuous integration on armv8

Gabriel,

We do need to have multiple workers to service the verify queue... having the 
queue back up behind a single server wouldn't be good.  Do you know if these 
boxes are installed with Ubuntu 16.04 already?

Ed

On Thu, Nov 16, 2017 at 9:03 AM Gabriel Ganne 
mailto:gabriel.ga...@enea.com>> wrote:

Yes, they are.

I estimate it should take about 40 minutes to build and test with 8 cores in 
release mode, therefore I do not think that using all 3 ThunderX is necessary.

I do not have access to a ThunderX platform on my side (I ran my tests on NXP 
and Hierofalcon platforms), if needed please see with Tina Tsou (in CC) for the 
specifics of ThunderX.



I was thinking about duplicating the *vpp-verify-master-ubuntu1604* target as a 
first step.

Ubuntu 16.04 is a LTS for armv8 and is one of the distributions already used 
for vpp x86 continuous testing.



If all goes well, I was thinking about using fedora-26 (or above) as rhel-based 
distribution, since it also has aarch64 official support.

But since it's not one of the distros already used in ci, let's keep it for 
later.



Regards,



--

Gabriel Ganne


From: Ed Warnicke mailto:hagb...@gmail.com>>
Sent: Thursday, November 16, 2017 4:47:14 PM
To: Gabriel Ganne
Cc: vpp-dev; Dave Barach (dbarach); Nicolas Bouthors; 
csit-...@lists.fd.io; Vanessa Valderrama
Subject: Re: [vpp-dev] vpp continuous integration on armv8

Gabriel,

This is awesome news!

Do I understand correctly that these ThunderX boards are intended to be used 
for build/make test/packaging?  If so, I've cced in Vanessa, our fearless 
sysadmin to help in figuring these things out :)

Do you have opinions about which Linux distributions you want to package for 
(Ubuntu?, Centos?) and versions?

Ed

On Thu, Nov 16, 2017 at 5:27 AM Gabriel Ganne 
mailto:gabriel.ga...@enea.com>> wrote:

Hi,



We've been working on preparing vpp for armv8 continuous testing (See 
https://wiki.fd.io/view/VPP/AArch64),

and we think that we now have everything which is required to add arm as ci 
platform in the vpp review process (build, test and packaging). All the test 
have been done on "native".

Also 3 thunderX platforms sent by ARM should have arrived yesterday in the fdio 
lab.


I *think* that all that is required should be to set the platforms with VMs on 
it, and add them as build slaves.



How should we proceed from here ?



--
Gabriel Ganne


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] network loop

2017-11-16 Thread yug...@telincn.com
Hi  all,
My version is 17.04, sometimes there will be  a large number of packets 
transmitted by vpp.
It looks like that vpp has network loop itself. Here is the stack when the loop 
happened. Any idea?


(gdb) c
Continuing.
^C
Thread 1 "vpp_main" received signal SIGINT, Interrupt.
eth_em_xmit_pkts (tx_queue=0x7a8227972d00, tx_pkts=, 
nb_pkts=)
at 
/home/wangzy/VBRASV100R001/vpp1704/dpdk/_build/dpdk-17.02/drivers/net/e1000/em_rxtx.c:625
625 return nb_tx;
(gdb) bt
#0  eth_em_xmit_pkts (tx_queue=0x7a8227972d00, tx_pkts=, 
nb_pkts=)
at 
/home/wangzy/VBRASV100R001/vpp1704/dpdk/_build/dpdk-17.02/drivers/net/e1000/em_rxtx.c:625
#1  0x7f81b02923cf in rte_eth_tx_burst (nb_pkts=, 
tx_pkts=, queue_id=0, port_id=)
at 
/home/wangzy/VBRASV100R001/vpp1704/dpdk/_install/include/dpdk/rte_ethdev.h:2858
#2  tx_burst_vector_internal (tx_vector=, xd=, 
vm=)
at 
/home/wangzy/VBRASV100R001/vpp1704/build-data/../src/plugins/dpdk/device/device.c:282
#3  dpdk_interface_tx (f=, node=, vm=)
at 
/home/wangzy/VBRASV100R001/vpp1704/build-data/../src/plugins/dpdk/device/device.c:559
#4  dpdk_interface_tx_avx2 (vm=, node=, 
frame=)
at 
/home/wangzy/VBRASV100R001/vpp1704/build-data/../src/plugins/dpdk/device/device.c:789
#5  0x7f81f47e0119 in dispatch_node (vm=0x7f81f4a332a0 , 
node=0x7f81b1eb8800, type=, 
dispatch_state=VLIB_NODE_STATE_POLLING, frame=, 
last_time_stamp=13589960530660)
at /home/wangzy/VBRASV100R001/vpp1704/build-data/../src/vlib/main.c:998
#6  0x7f81f47e040d in dispatch_pending_node (vm=vm@entry=0x7f81f4a332a0 
, p=0x7f81b52c3398, 
last_time_stamp=) at 
/home/wangzy/VBRASV100R001/vpp1704/build-data/../src/vlib/main.c:1144
#7  0x7f81f47e0e6d in vlib_main_or_worker_loop (is_main=1, 
vm=0x7f81f4a332a0 )
at /home/wangzy/VBRASV100R001/vpp1704/build-data/../src/vlib/main.c:1591
#8  vlib_main_loop (vm=0x7f81f4a332a0 ) at 
/home/wangzy/VBRASV100R001/vpp1704/build-data/../src/vlib/main.c:1611
#9  vlib_main (vm=vm@entry=0x7f81f4a332a0 , 
input=input@entry=0x7f81b1854fa0)
at /home/wangzy/VBRASV100R001/vpp1704/build-data/../src/vlib/main.c:1739
#10 0x7f81f4819f13 in thread0 (arg=140196131844768) at 
/home/wangzy/VBRASV100R001/vpp1704/build-data/../src/vlib/unix/main.c:507
#11 0x7f81f2a53cd0 in clib_calljmp () at 
/home/wangzy/VBRASV100R001/vpp1704/build-data/../src/vppinfra/longjmp.S:110
#12 0x7ffcb4160b00 in ?? ()
#13 0x7f81f481a92d in vlib_unix_main (argc=, argv=)
at /home/wangzy/VBRASV100R001/vpp1704/build-data/../src/vlib/unix/main.c:606


Regards,
Ewan


yug...@telincn.com
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev