Re: [vpp-dev] [EXT] Re: [discuss] Question about VPP support for ARM 64

[Eric Chen]

Hi Brian,

I am trying to natively build vpp in aarch64 box as well, 

However when I "make install-dep", it report error -- "unable to locate package 
default-jdk-headless",

If you are using Ubuntu as well, could you share with me your apt-get source 
list?

Thanks
Eric

-Original Message-
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Brian Brooks
Sent: 2017年8月23日 12:31
To: George Zhao 
Cc: discuss ; csit-dev ; Damjan 
Marion (damarion) ; vpp-dev 
Subject: [EXT] Re: [vpp-dev] [discuss] Question about VPP support for ARM 64

External Email

--
Hi Damjan, George,

I just pulled lastest source and tried native build (platforms/vpp.mk) on ARMv8:

  cat: '/sys/bus/pci/devices/:00:01.0/uevent': No such file or directory

From dpdk/Makefile,

  ##
  # Intel x86
  ##
  ifeq ($(MACHINE),$(filter $(MACHINE),x86_64 i686))
  DPDK_TARGET   ?= $(MACHINE)-native-linuxapp-$(DPDK_CC)
  DPDK_MACHINE  ?= nhm
  DPDK_TUNE ?= core-avx2
  ##
  # Cavium ThunderX
  ##
  else ifneq (,$(findstring thunder,$(shell cat 
/sys/bus/pci/devices/:00:01.0/uevent | grep cavium)))
  export CROSS=""
  DPDK_TARGET   ?= arm64-thunderx-linuxapp-$(DPDK_CC)
  DPDK_MACHINE  ?= thunderx
  DPDK_TUNE ?= generic

So, I am thinking we need to modify this to support MACHINE=aarch64 and 
possibly rework thunder detection to not fail hard on non-thunder machines.

Regards,
Brian

On 08/22 17:55:20, George Zhao wrote:
> Thanks Demjan,
> 
> Confirmed that your patches worked on our system as well.
> 
> George
> 
> From: Damjan Marion (damarion) [mailto:damar...@cisco.com]
> Sent: Tuesday, August 22, 2017 5:03 AM
> To: George Zhao
> Cc: Dave Barach (dbarach); discuss; csit-dev; vpp-dev
> Subject: Re: [vpp-dev] [discuss] Question about VPP support for ARM 64
> 
> Dear George,
> 
> I tried on my Cavium ThunderX system with latest Ubuntu and after fixing few 
> minor issues (all patches submitted to master) I got VPP running.
> I use latest Ubuntu devel (17.10, mainly as I upgraded to new kernel 
> in my attempts to get system working)
> 
> For me it is hard to help you with your particular system, as I don’t have 
> access to similar one, but my guess is that it shouldn’’t be too hard to get 
> it working.
> 
> Thanks,
> 
> Damjan
> 
> On 20 Aug 2017, at 23:12, George Zhao 
> mailto:george.y.z...@huawei.com>> wrote:
> 
> Hi Damian,
> 
> IT is Applied Micro overdrive 1000, here are the uname -a output:
> 
> $>> uname -a
> Linux OD1K 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:10:33 UTC 
> 2017 aarch64 aarch64 aarch64 GNU/Linux
> 
> thanks
> George
> 发件人：Damjan Marion (damarion)
> 收件人：George Zhao
> 抄送：dbarach,discuss,csit-dev,vpp-dev
> 时间：2017-08-20 10:03:27
> 主题:Re: [vpp-dev] [discuss] Question about VPP support for ARM 64
> 
> 
> 
> George, are you using ThunderX platform?
> 
> I spent few hours today trying to install latest ubuntu on my ThunderX system 
> but no luck, kernel hangs at some point, both ubuntu provided and manually 
> compiled.
> 
> Can you share about more details about your system?
> 
> Thanks,
> 
> Damjan
> 
> 
> 
> > On 19 Aug 2017, at 22:48, George Zhao 
> > mailto:george.y.z...@huawei.com>> wrote:
> >
> > If a bug is filed, may I have the bug number, I would be love to trace this 
> > patch.
> >
> > BTW, how do I file a bug for VPP, I did a quick wiki search with no luck.
> >
> > Thanks,
> > George
> >
> > -Original Message-
> > From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
> > Sent: Saturday, August 19, 2017 7:42 AM
> > To: George Zhao 
> > mailto:george.y.z...@huawei.com>>
> > Cc: vpp-dev@lists.fd.io; 
> > disc...@lists.fd.io; 
> > csit-...@lists.fd.io; Damjan Marion 
> > (damarion) mailto:damar...@cisco.com>>
> > Subject: RE: [discuss] Question about VPP support for ARM 64
> >
> > +1, pls add the typedef...
> >
> > Thanks… Dave
> >
> > -Original Message-
> > From: Damjan Marion (damarion)
> > Sent: Saturday, August 19, 2017 9:09 AM
> > To: Dave Barach (dbarach) 
> > mailto:dbar...@cisco.com>>
> > Cc: George Zhao 
> > mailto:george.y.z...@huawei.com>>; 
> > vpp-dev@lists.fd.io; 
> > disc...@lists.fd.io; 
> > csit-...@lists.fd.io
> > Subject: Re: [discuss] Question about VPP support for ARM 64
> >
> >
> > GCC is able to compile ARM64 code with 256-bit vectors even if target 
> > platform have only 128-bit registers.
> >
> > I.e. for the u8x32 version of that function it

Re: [vpp-dev] [discuss] Question about VPP support for ARM 64

[Brian Brooks]

Hi Damjan, George,

I just pulled lastest source and tried native build (platforms/vpp.mk) on ARMv8:

  cat: '/sys/bus/pci/devices/:00:01.0/uevent': No such file or directory

From dpdk/Makefile,

  ##
  # Intel x86
  ##
  ifeq ($(MACHINE),$(filter $(MACHINE),x86_64 i686))
  DPDK_TARGET   ?= $(MACHINE)-native-linuxapp-$(DPDK_CC)
  DPDK_MACHINE  ?= nhm
  DPDK_TUNE ?= core-avx2
  ##
  # Cavium ThunderX
  ##
  else ifneq (,$(findstring thunder,$(shell cat 
/sys/bus/pci/devices/:00:01.0/uevent | grep cavium)))
  export CROSS=""
  DPDK_TARGET   ?= arm64-thunderx-linuxapp-$(DPDK_CC)
  DPDK_MACHINE  ?= thunderx
  DPDK_TUNE ?= generic

So, I am thinking we need to modify this to support MACHINE=aarch64 and possibly
rework thunder detection to not fail hard on non-thunder machines.

Regards,
Brian

On 08/22 17:55:20, George Zhao wrote:
> Thanks Demjan,
> 
> Confirmed that your patches worked on our system as well.
> 
> George
> 
> From: Damjan Marion (damarion) [mailto:damar...@cisco.com]
> Sent: Tuesday, August 22, 2017 5:03 AM
> To: George Zhao
> Cc: Dave Barach (dbarach); discuss; csit-dev; vpp-dev
> Subject: Re: [vpp-dev] [discuss] Question about VPP support for ARM 64
> 
> Dear George,
> 
> I tried on my Cavium ThunderX system with latest Ubuntu and after fixing few 
> minor issues (all patches submitted to master) I got VPP running.
> I use latest Ubuntu devel (17.10, mainly as I upgraded to new kernel in my 
> attempts to get system working)
> 
> For me it is hard to help you with your particular system, as I don’t have 
> access to similar one, but my guess is that it shouldn’’t be too hard to get 
> it working.
> 
> Thanks,
> 
> Damjan
> 
> On 20 Aug 2017, at 23:12, George Zhao 
> mailto:george.y.z...@huawei.com>> wrote:
> 
> Hi Damian,
> 
> IT is Applied Micro overdrive 1000, here are the uname -a output:
> 
> $>> uname -a
> Linux OD1K 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:10:33 UTC 2017 
> aarch64 aarch64 aarch64 GNU/Linux
> 
> thanks
> George
> 发件人：Damjan Marion (damarion)
> 收件人：George Zhao
> 抄送：dbarach,discuss,csit-dev,vpp-dev
> 时间：2017-08-20 10:03:27
> 主题:Re: [vpp-dev] [discuss] Question about VPP support for ARM 64
> 
> 
> 
> George, are you using ThunderX platform?
> 
> I spent few hours today trying to install latest ubuntu on my ThunderX system 
> but no luck, kernel hangs at some point, both ubuntu provided and manually 
> compiled.
> 
> Can you share about more details about your system?
> 
> Thanks,
> 
> Damjan
> 
> 
> 
> > On 19 Aug 2017, at 22:48, George Zhao 
> > mailto:george.y.z...@huawei.com>> wrote:
> >
> > If a bug is filed, may I have the bug number, I would be love to trace this 
> > patch.
> >
> > BTW, how do I file a bug for VPP, I did a quick wiki search with no luck.
> >
> > Thanks,
> > George
> >
> > -Original Message-
> > From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
> > Sent: Saturday, August 19, 2017 7:42 AM
> > To: George Zhao mailto:george.y.z...@huawei.com>>
> > Cc: vpp-dev@lists.fd.io; 
> > disc...@lists.fd.io; 
> > csit-...@lists.fd.io; Damjan Marion (damarion) 
> > mailto:damar...@cisco.com>>
> > Subject: RE: [discuss] Question about VPP support for ARM 64
> >
> > +1, pls add the typedef...
> >
> > Thanks… Dave
> >
> > -Original Message-
> > From: Damjan Marion (damarion)
> > Sent: Saturday, August 19, 2017 9:09 AM
> > To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>
> > Cc: George Zhao 
> > mailto:george.y.z...@huawei.com>>; 
> > vpp-dev@lists.fd.io; 
> > disc...@lists.fd.io; 
> > csit-...@lists.fd.io
> > Subject: Re: [discuss] Question about VPP support for ARM 64
> >
> >
> > GCC is able to compile ARM64 code with 256-bit vectors even if target 
> > platform have only 128-bit registers.
> >
> > I.e. for the u8x32 version of that function it generates:
> >
> > ARM64:
> > dpdk_buffer_init_from_template(void*, void*, void*, void*, void*):
> >ld1 {v0.16b - v1.16b}, [x4], 32
> >st1 {v0.16b - v1.16b}, [x3], 32
> >st1 {v0.16b - v1.16b}, [x2], 32
> >st1 {v0.16b - v1.16b}, [x1], 32
> >st1 {v0.16b - v1.16b}, [x0], 32
> >ld1 {v0.16b - v1.16b}, [x4]
> >st1 {v0.16b - v1.16b}, [x3]
> >st1 {v0.16b - v1.16b}, [x2]
> >st1 {v0.16b - v1.16b}, [x1]
> >st1 {v0.16b - v1.16b}, [x0]
> >ret
> >
> > intel x86-64 without AVX2:
> >
> > dpdk_buffer_init_from_template(void*, void*, void*, void*, void*):
> > 

Re: [vpp-dev] [discuss] Question about VPP support for ARM 64

[George Zhao]

Thanks Demjan,

Confirmed that your patches worked on our system as well.

George

From: Damjan Marion (damarion) [mailto:damar...@cisco.com]
Sent: Tuesday, August 22, 2017 5:03 AM
To: George Zhao
Cc: Dave Barach (dbarach); discuss; csit-dev; vpp-dev
Subject: Re: [vpp-dev] [discuss] Question about VPP support for ARM 64

Dear George,

I tried on my Cavium ThunderX system with latest Ubuntu and after fixing few 
minor issues (all patches submitted to master) I got VPP running.
I use latest Ubuntu devel (17.10, mainly as I upgraded to new kernel in my 
attempts to get system working)

For me it is hard to help you with your particular system, as I don’t have 
access to similar one, but my guess is that it shouldn’’t be too hard to get it 
working.

Thanks,

Damjan

On 20 Aug 2017, at 23:12, George Zhao 
mailto:george.y.z...@huawei.com>> wrote:

Hi Damian,

IT is Applied Micro overdrive 1000, here are the uname -a output:

$>> uname -a
Linux OD1K 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:10:33 UTC 2017 
aarch64 aarch64 aarch64 GNU/Linux

thanks
George
发件人：Damjan Marion (damarion)
收件人：George Zhao
抄送：dbarach,discuss,csit-dev,vpp-dev
时间：2017-08-20 10:03:27
主题:Re: [vpp-dev] [discuss] Question about VPP support for ARM 64



George, are you using ThunderX platform?

I spent few hours today trying to install latest ubuntu on my ThunderX system 
but no luck, kernel hangs at some point, both ubuntu provided and manually 
compiled.

Can you share about more details about your system?

Thanks,

Damjan



> On 19 Aug 2017, at 22:48, George Zhao 
> mailto:george.y.z...@huawei.com>> wrote:
>
> If a bug is filed, may I have the bug number, I would be love to trace this 
> patch.
>
> BTW, how do I file a bug for VPP, I did a quick wiki search with no luck.
>
> Thanks,
> George
>
> -Original Message-
> From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
> Sent: Saturday, August 19, 2017 7:42 AM
> To: George Zhao mailto:george.y.z...@huawei.com>>
> Cc: vpp-dev@lists.fd.io; 
> disc...@lists.fd.io; 
> csit-...@lists.fd.io; Damjan Marion (damarion) 
> mailto:damar...@cisco.com>>
> Subject: RE: [discuss] Question about VPP support for ARM 64
>
> +1, pls add the typedef...
>
> Thanks… Dave
>
> -Original Message-
> From: Damjan Marion (damarion)
> Sent: Saturday, August 19, 2017 9:09 AM
> To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>
> Cc: George Zhao mailto:george.y.z...@huawei.com>>; 
> vpp-dev@lists.fd.io; 
> disc...@lists.fd.io; 
> csit-...@lists.fd.io
> Subject: Re: [discuss] Question about VPP support for ARM 64
>
>
> GCC is able to compile ARM64 code with 256-bit vectors even if target 
> platform have only 128-bit registers.
>
> I.e. for the u8x32 version of that function it generates:
>
> ARM64:
> dpdk_buffer_init_from_template(void*, void*, void*, void*, void*):
>ld1 {v0.16b - v1.16b}, [x4], 32
>st1 {v0.16b - v1.16b}, [x3], 32
>st1 {v0.16b - v1.16b}, [x2], 32
>st1 {v0.16b - v1.16b}, [x1], 32
>st1 {v0.16b - v1.16b}, [x0], 32
>ld1 {v0.16b - v1.16b}, [x4]
>st1 {v0.16b - v1.16b}, [x3]
>st1 {v0.16b - v1.16b}, [x2]
>st1 {v0.16b - v1.16b}, [x1]
>st1 {v0.16b - v1.16b}, [x0]
>ret
>
> intel x86-64 without AVX2:
>
> dpdk_buffer_init_from_template(void*, void*, void*, void*, void*):
> push   %rbp
> mov%rsp,%rbp
> and$0xffe0,%rsp
> lea0x10(%rsp),%rsp
> movdqa (%r8),%xmm1
> movdqa 0x10(%r8),%xmm0
> movdqa %xmm0,0x10(%rcx)
> movdqa %xmm1,(%rcx)
> movdqa %xmm1,(%rdx)
> movdqa %xmm0,0x10(%rdx)
> movdqa %xmm1,(%rsi)
> movdqa %xmm0,0x10(%rsi)
> movdqa %xmm1,(%rdi)
> movdqa %xmm0,0x10(%rdi)
> movdqa 0x20(%r8),%xmm1
> movdqa 0x30(%r8),%xmm0
> movdqa %xmm0,0x30(%rcx)
> movdqa %xmm1,0x20(%rcx)
> movdqa %xmm1,0x20(%rdx)
> movdqa %xmm0,0x30(%rdx)
> movdqa %xmm1,0x20(%rsi)
> movdqa %xmm0,0x30(%rsi)
> movdqa %xmm1,0x20(%rdi)
> movdqa %xmm0,0x30(%rdi)
> leaveq
> retq
>
>
> So i think here it is only about missing typedef….
>
>
>> On 19 Aug 2017, at 14:51, Dave Barach (dbarach) 
>> mailto:dbar...@cisco.com>> wrote:
>>
>> Dear George,
>>
>> This specific issue isn’t anywhere near as bad as you might think. As given, 
>> the code confuses 128-bit vectors with 256-bit vectors, and 64-bit vectors 
>> with 128-bit vectors.
>>
>> Question: does the hardware involved support 256-bit vectors? Probably 
>> not... It almost certainly does support 128-bit vectors.
>>
>> To make progress, use the known-good u8x16 / 128-bit vector code:
>>
>> static_always_inline void
>> dpdk_buffer_init_from_template (void *d0, void *d1, void *d2, void *d3,
>>  void *s)
>> {
>> #if defined(CLIB_HAVE_VEC128)
>>  int i;
>>  for (i = 0; i < 4; i++)
>>{
>>  *(u8x16 *) (((u8 *) d0) + i * 16) =
>> *(u8x16 *

Re: [vpp-dev] 回复：compiling error when build fd.io_odp4vpp with cross_compiler for aarch64 target

[Burt Silverman]

Thanks, Dave, and Eric. I ran into this 3 days ago doing some strange stuff
-- I did not realize that I was compiling without

-DWITHLIBSSL=

where x is a positive number .

Freely translated, I did not realize I was compiling ipsec_output.c with
non-default options.

That said, I see only one issue, not two, and Dave's recommended change
should fix it

OH NOW I REMEMBER... I was trying last year to build with a C++ compiler
and it was necessary to restructure the macros, but that was a general
issue not at all related to this special case of two nodes given the same
parameter.

Burt

On Tue, Aug 22, 2017 at 7:51 AM, Dave Barach (dbarach) 
wrote:

> Did you try changing the data structure names so they don’t conflict?
>
>
>
> VLIB_REGISTER_NODE (ipsec_output4_node) + VLIB_REGISTER_NODE
> (ipsec_output6_node).
>
>
>
> Feel free to submit a patch. (😉)...
>
>
>
> Thanks… Dave
>
>
>
> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
> Behalf Of *Eric Chen
> *Sent:* Tuesday, August 22, 2017 6:19 AM
> *To:* vpp-dev 
> *Cc:* odp4vpp-...@lists.fd.io
> *Subject:* [vpp-dev] 回复：compiling error when build fd.io_odp4vpp with
> cross_compiler for aarch64 target
>
>
>
>
>
>
>
> HI
>
>
>
> I try to build odp4vpp on a x86 host with the cross-compiler for machine
> of aarch64.
>
>
>
> But encounter below errors, could you help me out?
>
>
>
> 1)
>
> vpp/build-root/install-armada-a8k_debug-aarch64/vlib/include/vlib/node.h:147:13:
> error: redefinition of '__vlib_add_node_registration_ipsec_output_node'
>
> static void __vlib_add_node_registration_##x (void)
>
>
>
>
>
> *node.h:147*
>
>
>
> #define VLIB_REGISTER_NODE(x,...)   \
>
> __VA_ARGS__ vlib_node_registration_t x; \
>
> static void __vlib_add_node_registration_##x (void) \
>
> __attribute__((__constructor__)) ;  \
>
> static void __vlib_add_node_registration_##x (void) \
>
> {   \
>
> vlib_main_t * vm = vlib_get_main(); \
>
> x.next_registration = vm->node_main.node_registrations; \
>
> vm->node_main.node_registrations = &x;  \
>
> }   \
>
> __VA_ARGS__ vlib_node_registration_t x
>
>
>
>
>
> 2)
>
>
>
> *In ./vpp/vnet/vnet/ipsec/ipsec_output.c*
>
>
>
> If -DIPSEC=0, (--without-ipsec)  then below will cause redefinition error
> as well,
>
>
>
> /* *INDENT-OFF* */
>
> VLIB_REGISTER_NODE (ipsec_output_node) = {
>
>   .vector_size = sizeof (u32),
>
>   .function = ipsec_output_node_fn,
>
>   .name = "ipsec-output-ip4",
>
> };
>
>
>
> VLIB_REGISTER_NODE (ipsec_output_node) = {
>
>   .vector_size = sizeof (u32),
>
>   .function = ipsec_output_node_fn,
>
>   .name = "ipsec-output-ip6",
>
> };
>
>
>
>
>
>
>
>
> ___
> 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] Packet loss on use of API & cmdline

[Colin Tregenza Dancer via vpp-dev]

With my current setup (a fairly modest 2Mpps of background traffic each way 
between a pair of 10G ports on an Intel X520 NIC, with baremetal Ubuntu 16, vpp 
17.01 and a couple of cores per NIC), I observed a range of different packet 
loss scenarios:


  *   1K-80K packets lost if I issue any of a range of stats/info commands from 
the telnet command line: “show hard”, “show int”, “show ip arp”, “show ip fib”, 
“show fib path”.   (I haven’t yet tried the same calls via the API, but from 
code reading would expect similar results.)
  *   Issuing an “ip route add” / “ip route del” pair from the telnet command 
line, I see 0.5K-30K packets dropped, mainly on the del.
  *   Using the API, if I issue a close sequence of commands to create a new 
GRE tunnel and setup individual forwarding entries for 64 endpoints at the 
other end of that tunnel, I see 100K-500K packets dropped.

Cheers,

Colin.

P.S. Have fun on the beach!


From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: 22 August 2017 14:35
To: Colin Tregenza Dancer ; Florin Coras 

Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Packet loss on use of API & cmdline


Hi Colin,

Your comments were not taken as criticism ☺ constructive comments are always 
greatly appreciated.

Apart from the non-MP safe APIs Florin mentioned, and the route add/del cases I 
covered, the consensus is certainly that packet loss should not occur during a 
‘typical’ update and we will do what we can to address it.
Could you give us* some specific examples of the operations you do where you 
see packet loss?

Thanks,
Neale

*I say us not me as I’m about to hit the beach for a couple of weeks.


From: Colin Tregenza Dancer mailto:c...@metaswitch.com>>
Date: Tuesday, 22 August 2017 at 14:24
To: "Neale Ranns (nranns)" mailto:nra...@cisco.com>>, Florin 
Coras mailto:fcoras.li...@gmail.com>>
Cc: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: RE: [vpp-dev] Packet loss on use of API & cmdline

Hi neale,

Thanks for the reply, and please don’t take my comments as a criticism of what 
I think is a great project.  I’m just trying to understand whether the packet 
loss I’m observing when I do thinks like add new tunnels, setup routes, etc, is 
generally viewed as acceptable, or whether it’s an area where there is an 
interest in changing.

Specifically I’m looking at a range of tunnel/gateway applications, and am 
finding that whilst static operation is great from a packet loss perspective, 
when I add/remove tunnels, routes, etc (something which in my application is to 
be expected on a regular basis) the existing flows undergo significant packet 
loss.  For comparison, with most hardware based router/gateway this doesn’t 
occur, and existing flows continue unaffected.

Cheers,

Colin.

From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: 22 August 2017 13:44
To: Colin Tregenza Dancer mailto:c...@metaswitch.com>>; 
Florin Coras mailto:fcoras.li...@gmail.com>>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Packet loss on use of API & cmdline

Hi Colin,

The instances of barrier syncs you have correctly identified, occur only in the 
exceptional cases of route addition/deletion and not in the typical case.


  *   adj_last_lock_gone () is called when that adjacency is no longer 
required, i.e. we are removing the last route, or probably the ARP entry, for a 
neighbour we presumably no longer have
  *   adj_nbr_update_rewrite_internal() is called when the adjacency 
transitions from incomplete (not associated MAC rewrite) to complete.
  *   The fix for 892 occurs when a route is added that is the first to create 
a new edge/arc in the VLIB node graph. In the case of that JIRA ticket, it was 
the first recursive route. Edges are never removed, so this is a once 
per-reboot event.

But in the typical case of adding routes, e.g. a BGP/OSPF convergence event, 
the adjacencies are present and complete and the VLIB graph is already setup, 
so the routes will be added in a lock/barrier free manner.

Pre-building the VLIB graph of all possibilities is wasteful IMHO, and given 
the one-time only lock, an acceptable trade off.
Adjacencies are more complicated. The state of the adjacency, incomplete or 
complete, determines the VLIB node the packet should go to. So one needs to 
atomically change the state of the adjacency and the state of the routes that 
use it - hence the barrier. We could solve that with indirection, but it would 
be indirection in the data-path and that costs cycles. So, again, given the 
relatively rarity of such an adjacency state change, the trade-off was to 
barrier sync.

Hth,
neale


From: mailto:vpp-dev-boun...@lists.fd.io>> on 
behalf of Colin Tregenza Dancer via vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Reply-To: Colin Tregenza Dancer 
mailto:c...@metaswitch.com>>
Date: Tuesday, 22 August 2017 at 12:25
To: Florin Coras mailto:fcoras.li...@gmail.com>>
Cc: "vpp-dev@lists.fd.io

Re: [vpp-dev] VPP Performance drop from 17.04 to 17.07

[John Lo (loj)]

I submitted a patch to increase the MAC learn limit from 1M to 8M for 1707 
which is now merged:
https://gerrit.fd.io/r/#/c/8132/

I submitted a separate patch for master to make default MAC learn limit 8M and 
tighter check for MAC learn limit:
https://gerrit.fd.io/r/#/c/8159/

Regards,
John

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of John Lo (loj)
Sent: Friday, August 18, 2017 1:29 AM
To: Billy McFall 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP Performance drop from 17.04 to 17.07

Hi Billy,

Thanks for the follow up information. VPP does have a MAC learn limit of around 
1M for quite a while. It is controlled by 2 variables global_learn_limit and 
global_learn_count defined in l2_learn.h.  At init time, global_learn_limit is 
set to about 1M in the function l2_learn_init() in l2_learn.c:
  mp->global_learn_limit = L2FIB_NUM_BUCKETS * 16;

The variable global_learn_count is kept to track current learned MACs. For 
1707, we added display of global_learn_count in the output of “show l2fib”. 
There were minor fixes in this area between 1704 and 1707 and I suppose it 
makes the learn limit check more effective in 1707 while not in 1704. 
Unfortunately, there is no API/CLI to change this limit at runtime. We need to 
change this limit to 4M or more for your 1M flow test case.

The learn limit, however, cannot fully explain the performance difference you 
observed for 10K flows. Perhaps we should concentrate on the 10K flow case as 
to why 1707 performance is low. Did you also observe similar flooding behavior 
for packet forwarding with 10K flows?

I see that the test is done with two bridge domains (BDs) with a PNIC and a 
vHost port in each BD. A few more questions on the test setup and script:

·Are there any other BDs or ethernet ports involved in the test?

·Is MAC aging enabled on the BDs? I assume not as it is not enabled by 
default.

·Is VPP running with multiple worker threads? If so, how many?

·Are all MACs learned? Is VPP API/CLI used to add/delete MACs in L2FIB? 
If so, are these MACs added as static MAC?

·Is there any calls to VPP API/CLI to clear or flush L2FIB?

It will be helpful to get the following information:

·The output of CLI “show bridge”

·The output of CLI “show bridge  details” for each BD.

It will be helpful to get the following information for 1704 and 1707 while the 
100K flow test is running in its optimal forwarding MPPS state:

·Use the CLI “clear node counters”, wait 2 seconds, get the output of 
“show node counters”

·Use the CLI “clear run”, wait 2 seconds, get the output of “show run”.

The “show node counters” output will give indication of how much learning or 
flooding is ongoing. The “show run” output will tell us, for the time period 
between clear-run and show-run, which VPP nodes were called, how many calls to 
each node, how many packets were processed for each call, average clocks used 
by each node to process a packet. We can then compare the difference between 
1704 and 1707 to get more clues.

Regards,
John

From: Billy McFall [mailto:bmcf...@redhat.com]
Sent: Thursday, August 17, 2017 2:14 PM
To: John Lo (loj) mailto:l...@cisco.com>>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP Performance drop from 17.04 to 17.07



On Tue, Aug 15, 2017 at 8:05 AM, John Lo (loj) 
mailto:l...@cisco.com>> wrote:
Hi Billy,

The output of “show l2fib” is showing how many MAC entries exist in the L2FIB 
and is not relevant to the size of L2FIB table. The L2FIB table size is not 
configurable. It is a bi-hash table with size set by the following #def’s in 
l2_fib.h and has not changed for quite a while, definitely not between 1704, 
1707 and current master:
/*
* The size of the hash table
*/
#define L2FIB_NUM_BUCKETS (64 * 1024)
#define L2FIB_MEMORY_SIZE (256<<20)

I previously looked through the git tree for recent changes and noticed that 
these did not change. I was hoping these were more a MAX size but I guess not.

It is interesting to note that at the end of the test run, there is different 
number of MAC entries in the L2FIB. I think this may have to do with a change 
in 1707 where an interface up/down would cause MACs learned on that interface 
to be flushed. So when the interface come back up, the MACs needs to be learned 
again.  With 1704, the stale learned MACs from an interface will remain in 
L2FIB even if the interface is down or deleted unless aging is enabled to 
removed them at the BD aging interval.

Our test team reexamined scripts and re-ran some tests and they don't believe 
the interfaces are going up and down throughout the test. Here is there finding:

I've looked over our code and I don't see how we might be causing any up/down 
or device add/delete actions during the course of a test.

I ran some more tests yesterday where I did more fine grained flow scaling.  I 
ran the following flow counts (N):

Re: [vpp-dev] Packet loss on use of API & cmdline

[Neale Ranns (nranns)]

Hi Colin,

Your comments were not taken as criticism ☺ constructive comments are always 
greatly appreciated.

Apart from the non-MP safe APIs Florin mentioned, and the route add/del cases I 
covered, the consensus is certainly that packet loss should not occur during a 
‘typical’ update and we will do what we can to address it.
Could you give us* some specific examples of the operations you do where you 
see packet loss?

Thanks,
Neale

*I say us not me as I’m about to hit the beach for a couple of weeks.


From: Colin Tregenza Dancer 
Date: Tuesday, 22 August 2017 at 14:24
To: "Neale Ranns (nranns)" , Florin Coras 

Cc: "vpp-dev@lists.fd.io" 
Subject: RE: [vpp-dev] Packet loss on use of API & cmdline

Hi neale,

Thanks for the reply, and please don’t take my comments as a criticism of what 
I think is a great project.  I’m just trying to understand whether the packet 
loss I’m observing when I do thinks like add new tunnels, setup routes, etc, is 
generally viewed as acceptable, or whether it’s an area where there is an 
interest in changing.

Specifically I’m looking at a range of tunnel/gateway applications, and am 
finding that whilst static operation is great from a packet loss perspective, 
when I add/remove tunnels, routes, etc (something which in my application is to 
be expected on a regular basis) the existing flows undergo significant packet 
loss.  For comparison, with most hardware based router/gateway this doesn’t 
occur, and existing flows continue unaffected.

Cheers,

Colin.

From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: 22 August 2017 13:44
To: Colin Tregenza Dancer ; Florin Coras 

Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Packet loss on use of API & cmdline

Hi Colin,

The instances of barrier syncs you have correctly identified, occur only in the 
exceptional cases of route addition/deletion and not in the typical case.

-  adj_last_lock_gone () is called when that adjacency is no longer 
required, i.e. we are removing the last route, or probably the ARP entry, for a 
neighbour we presumably no longer have
-  adj_nbr_update_rewrite_internal() is called when the adjacency 
transitions from incomplete (not associated MAC rewrite) to complete.
-  The fix for 892 occurs when a route is added that is the first to 
create a new edge/arc in the VLIB node graph. In the case of that JIRA ticket, 
it was the first recursive route. Edges are never removed, so this is a once 
per-reboot event.

But in the typical case of adding routes, e.g. a BGP/OSPF convergence event, 
the adjacencies are present and complete and the VLIB graph is already setup, 
so the routes will be added in a lock/barrier free manner.

Pre-building the VLIB graph of all possibilities is wasteful IMHO, and given 
the one-time only lock, an acceptable trade off.
Adjacencies are more complicated. The state of the adjacency, incomplete or 
complete, determines the VLIB node the packet should go to. So one needs to 
atomically change the state of the adjacency and the state of the routes that 
use it - hence the barrier. We could solve that with indirection, but it would 
be indirection in the data-path and that costs cycles. So, again, given the 
relatively rarity of such an adjacency state change, the trade-off was to 
barrier sync.

Hth,
neale


From: mailto:vpp-dev-boun...@lists.fd.io>> on 
behalf of Colin Tregenza Dancer via vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Reply-To: Colin Tregenza Dancer 
mailto:c...@metaswitch.com>>
Date: Tuesday, 22 August 2017 at 12:25
To: Florin Coras mailto:fcoras.li...@gmail.com>>
Cc: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Packet loss on use of API & cmdline

Hi Florin,

Thanks for the quick, and very useful reply.

I’d been looking at the mp_safe flags, and had concluded that I’d need the 
calls I was interested in to be at least marked mp_safe.

However, I was thinking that wasn’t sufficient, as it appeared that some calls 
marked as mp_safe invoke barrier_sync lower down the call stacks.  For instance 
the internal functions adj_last_lock_gone(),  adj_nbr_update_rewrite_internal() 
and vlib_node_serialize() all seem to call vlib_worker_thread_barrier_sync(), 
and the fix for defect 892 
https://jira.fd.io/browse/VPP-892?gerritReviewStatus=All#gerrit-reviews-left-panel
 involves adding barrier calls in code related to the mp_safe ADD_DEL_ROUTE 
(which fits with packet loss I’d observed during testing of deleting routes).

I think the raw lossless packet processing which vpp has achieved on static 
configs is truly amazing, but I guess what I’m trying to understand is whether 
it is viewed as important to achieve similar behaviour when the system is being 
reconfigured.  Personally I think many of the potential uses of a software 
dataplane include the need to do limited impact dynamic reconfiguration, 
however, maybe the kind of applications I have in mind are in a minority?

More than any

Re: [vpp-dev] Packet loss on use of API & cmdline

[Colin Tregenza Dancer via vpp-dev]

Hi neale,

Thanks for the reply, and please don’t take my comments as a criticism of what 
I think is a great project.  I’m just trying to understand whether the packet 
loss I’m observing when I do thinks like add new tunnels, setup routes, etc, is 
generally viewed as acceptable, or whether it’s an area where there is an 
interest in changing.

Specifically I’m looking at a range of tunnel/gateway applications, and am 
finding that whilst static operation is great from a packet loss perspective, 
when I add/remove tunnels, routes, etc (something which in my application is to 
be expected on a regular basis) the existing flows undergo significant packet 
loss.  For comparison, with most hardware based router/gateway this doesn’t 
occur, and existing flows continue unaffected.

Cheers,

Colin.

From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: 22 August 2017 13:44
To: Colin Tregenza Dancer ; Florin Coras 

Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Packet loss on use of API & cmdline

Hi Colin,

The instances of barrier syncs you have correctly identified, occur only in the 
exceptional cases of route addition/deletion and not in the typical case.


  *   adj_last_lock_gone () is called when that adjacency is no longer 
required, i.e. we are removing the last route, or probably the ARP entry, for a 
neighbour we presumably no longer have
  *   adj_nbr_update_rewrite_internal() is called when the adjacency 
transitions from incomplete (not associated MAC rewrite) to complete.
  *   The fix for 892 occurs when a route is added that is the first to create 
a new edge/arc in the VLIB node graph. In the case of that JIRA ticket, it was 
the first recursive route. Edges are never removed, so this is a once 
per-reboot event.

But in the typical case of adding routes, e.g. a BGP/OSPF convergence event, 
the adjacencies are present and complete and the VLIB graph is already setup, 
so the routes will be added in a lock/barrier free manner.

Pre-building the VLIB graph of all possibilities is wasteful IMHO, and given 
the one-time only lock, an acceptable trade off.
Adjacencies are more complicated. The state of the adjacency, incomplete or 
complete, determines the VLIB node the packet should go to. So one needs to 
atomically change the state of the adjacency and the state of the routes that 
use it - hence the barrier. We could solve that with indirection, but it would 
be indirection in the data-path and that costs cycles. So, again, given the 
relatively rarity of such an adjacency state change, the trade-off was to 
barrier sync.

Hth,
neale


From: mailto:vpp-dev-boun...@lists.fd.io>> on 
behalf of Colin Tregenza Dancer via vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Reply-To: Colin Tregenza Dancer 
mailto:c...@metaswitch.com>>
Date: Tuesday, 22 August 2017 at 12:25
To: Florin Coras mailto:fcoras.li...@gmail.com>>
Cc: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Packet loss on use of API & cmdline

Hi Florin,

Thanks for the quick, and very useful reply.

I’d been looking at the mp_safe flags, and had concluded that I’d need the 
calls I was interested in to be at least marked mp_safe.

However, I was thinking that wasn’t sufficient, as it appeared that some calls 
marked as mp_safe invoke barrier_sync lower down the call stacks.  For instance 
the internal functions adj_last_lock_gone(),  adj_nbr_update_rewrite_internal() 
and vlib_node_serialize() all seem to call vlib_worker_thread_barrier_sync(), 
and the fix for defect 892 
https://jira.fd.io/browse/VPP-892?gerritReviewStatus=All#gerrit-reviews-left-panel
 involves adding barrier calls in code related to the mp_safe ADD_DEL_ROUTE 
(which fits with packet loss I’d observed during testing of deleting routes).

I think the raw lossless packet processing which vpp has achieved on static 
configs is truly amazing, but I guess what I’m trying to understand is whether 
it is viewed as important to achieve similar behaviour when the system is being 
reconfigured.  Personally I think many of the potential uses of a software 
dataplane include the need to do limited impact dynamic reconfiguration, 
however, maybe the kind of applications I have in mind are in a minority?

More than anything,  given the number of areas which would likely be touched by 
the required changes, I wanted to understand if there is a consensus that such 
change was even needed?

Thanks in advance for any insight you (or others) can offer.

Cheers,

Colin.



From: Florin Coras [mailto:fcoras.li...@gmail.com]
Sent: 22 August 2017 09:40
To: Colin Tregenza Dancer mailto:c...@metaswitch.com>>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Packet loss on use of API & cmdline

Hi Colin,

Your assumption was right. Most often than not, a binary API/CLI call results 
in a vlib_worker_thread_barrier_sync because most handlers and cli are not mp 
safe. As a consequence, vpp may experience packet loss.

One

Re: [vpp-dev] 回复：compiling error when build fd.io_odp4vpp with cross_compiler for aarch64 target

[Eric Chen]

David,

As you suggested, “try combining the function declaration with the 
implementation”

Below can pass the compiling,
Thanks a lot.


#define VLIB_REGISTER_NODE(x,...)   \
__VA_ARGS__ vlib_node_registration_t x; \
__attribute__((__constructor__))  static void 
__vlib_add_node_registration_##x (void) \
{   \
vlib_main_t * vm = vlib_get_main(); \
x.next_registration = vm->node_main.node_registrations; \
vm->node_main.node_registrations = &x;  \
}   \
__VA_ARGS__ vlib_node_registration_t x



From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Eric Chen
Sent: 2017年8月22日 20:49
To: Dave Barach (dbarach) ; vpp-dev 
Cc: odp4vpp-...@lists.fd.io
Subject: [EXT] Re: [vpp-dev] 回复：compiling error when build fd.io_odp4vpp with 
cross_compiler for aarch64 target

External Email

Hi David,

It’s marvell cross-compiler.

~/work/git_work/fd.io_odp4vpp/vpp$ 
/home/ericxh/work/toolchain/marvell-gcc-5.2.1-16.02.0-armv8/armv8/le/aarch64v8-marvell-linux-gnu-5.2.1_i686_20151110/bin/aarch64-marvell-linux-gnu-gcc
 -v
Using built-in specs.
COLLECT_GCC=/home/ericxh/work/toolchain/marvell-gcc-5.2.1-16.02.0-armv8/armv8/le/aarch64v8-marvell-linux-gnu-5.2.1_i686_20151110/bin/aarch64-marvell-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/mnt/disk1/ericxh/work/toolchain/marvell-gcc-5.2.1-16.02.0-armv8/armv8/le/aarch64v8-marvell-linux-gnu-5.2.1_i686_20151110/bin/../libexec/gcc/aarch64-linux-gnu/5.2.1/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /home/gccbuilder-i386/release/mgcc5.0/src/gcc-src/configure 
--host=i686-linux-gnu --build=i686-linux-gnu --target=aarch64-linux-gnu 
--prefix=/home/gccbuilder-i386/release/mgcc5.0/Release/install/aarch64v8-marvell-linux-gnu-5.2.1_i686
 --enable-libssp --enable-shared --enable-threads --enable-lto --enable-libgomp 
--enable-gnu-indirect-function --enable-languages=c,c++ --with-gnu-as 
--with-gnu-ld --with-pkgversion='Marvell GCC release 20151110-a53c013d' 
--with-bugurl=mailto:mrvlgcc...@gmail.com 
--with-sysroot=/home/gccbuilder-i386/release/mgcc5.0/Release/install/aarch64v8-marvell-linux-gnu-5.2.1_i686/aarch64-linux-gnu/libc
 
--with-build-sysroot=/home/gccbuilder-i386/release/mgcc5.0/Release/install/aarch64v8-marvell-linux-gnu-5.2.1_i686/aarch64-linux-gnu/libc
 --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' 
--with-build-time-tools=/home/gccbuilder-i386/release/mgcc5.0/Release/install/aarch64v8-marvell-linux-gnu-5.2.1_i686/aarch64-linux-gnu/bin
 --enable-poison-system-directories --enable-symvers=gnu --enable-__cxa_atexit 
--enable-multiarch --enable-linker-build-id --disable-nls 
--disable-libstdcxx-pch --disable-libcc1 
--with-specs='%{funwind-tables|fno-unwind-tables|ffreestanding|nostdlib:;:-funwind-tables}'
 --disable-multilib
Thread model: posix
gcc version 5.2.1 20151103 (Marvell GCC release 20151110-a53c013d)


if via weak attribution, it reported below since the func is static,

/mnt/disk1/ericxh/work/git_work/fd.io_odp4vpp/vpp/build-data/../vlib/vlib/node.h:145:13:
 error: weak declaration of 
'__vlib_add_node_registration_misc_drop_buffers_node' must be public
static void __vlib_add_node_registration_##x (void)

if removing the declaration,  it can pass the compiling,  but any side affect 
if  lost __attribute__((__constructor__)) ?

From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
Sent: 2017年8月22日 20:23
To: Eric Chen mailto:eri...@marvell.com>>; vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Cc: odp4vpp-...@lists.fd.io
Subject: [EXT] RE: 回复：compiling error when build fd.io_odp4vpp with 
cross_compiler for aarch64 target

External Email

Which compiler are you using?

Gcc-5.4 on x86_64, i686, and aarch64-le - as well as clang - are perfectly 
happy to compile that idiom. I don’t see it as an error.

You might try combining the function declaration with the implementation, but 
be advised that there are numerous instances of a related idiom which will 
probably not compile, either:

void foo(void) __attribute__((weak)); void foo(void) { return 0;}

Thanks… Dave

From: Eric Chen [mailto:eri...@marvell.com]
Sent: Tuesday, August 22, 2017 8:16 AM
To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>; 
vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: odp4vpp-...@lists.fd.io
Subject: RE: 回复：compiling error when build fd.io_odp4vpp with cross_compiler 
for aarch64 target

Yes, Dave,

But issue #1,  first declare the func, (marked as yellow)
then define it,  my cross_compler report an error,
how to fix it?


#define VLIB_REGISTER_NODE(x,...)   \
__VA_ARGS__ vlib_node_regis

Re: [vpp-dev] 回复：compiling error when build fd.io_odp4vpp with cross_compiler for aarch64 target

[Eric Chen]

Hi David,

It’s marvell cross-compiler.

~/work/git_work/fd.io_odp4vpp/vpp$ 
/home/ericxh/work/toolchain/marvell-gcc-5.2.1-16.02.0-armv8/armv8/le/aarch64v8-marvell-linux-gnu-5.2.1_i686_20151110/bin/aarch64-marvell-linux-gnu-gcc
 -v
Using built-in specs.
COLLECT_GCC=/home/ericxh/work/toolchain/marvell-gcc-5.2.1-16.02.0-armv8/armv8/le/aarch64v8-marvell-linux-gnu-5.2.1_i686_20151110/bin/aarch64-marvell-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/mnt/disk1/ericxh/work/toolchain/marvell-gcc-5.2.1-16.02.0-armv8/armv8/le/aarch64v8-marvell-linux-gnu-5.2.1_i686_20151110/bin/../libexec/gcc/aarch64-linux-gnu/5.2.1/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /home/gccbuilder-i386/release/mgcc5.0/src/gcc-src/configure 
--host=i686-linux-gnu --build=i686-linux-gnu --target=aarch64-linux-gnu 
--prefix=/home/gccbuilder-i386/release/mgcc5.0/Release/install/aarch64v8-marvell-linux-gnu-5.2.1_i686
 --enable-libssp --enable-shared --enable-threads --enable-lto --enable-libgomp 
--enable-gnu-indirect-function --enable-languages=c,c++ --with-gnu-as 
--with-gnu-ld --with-pkgversion='Marvell GCC release 20151110-a53c013d' 
--with-bugurl=mailto:mrvlgcc...@gmail.com 
--with-sysroot=/home/gccbuilder-i386/release/mgcc5.0/Release/install/aarch64v8-marvell-linux-gnu-5.2.1_i686/aarch64-linux-gnu/libc
 
--with-build-sysroot=/home/gccbuilder-i386/release/mgcc5.0/Release/install/aarch64v8-marvell-linux-gnu-5.2.1_i686/aarch64-linux-gnu/libc
 --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' 
--with-build-time-tools=/home/gccbuilder-i386/release/mgcc5.0/Release/install/aarch64v8-marvell-linux-gnu-5.2.1_i686/aarch64-linux-gnu/bin
 --enable-poison-system-directories --enable-symvers=gnu --enable-__cxa_atexit 
--enable-multiarch --enable-linker-build-id --disable-nls 
--disable-libstdcxx-pch --disable-libcc1 
--with-specs='%{funwind-tables|fno-unwind-tables|ffreestanding|nostdlib:;:-funwind-tables}'
 --disable-multilib
Thread model: posix
gcc version 5.2.1 20151103 (Marvell GCC release 20151110-a53c013d)


if via weak attribution, it reported below since the func is static,

/mnt/disk1/ericxh/work/git_work/fd.io_odp4vpp/vpp/build-data/../vlib/vlib/node.h:145:13:
 error: weak declaration of 
'__vlib_add_node_registration_misc_drop_buffers_node' must be public
static void __vlib_add_node_registration_##x (void)

if removing the declaration,  it can pass the compiling,  but any side affect 
if  lost __attribute__((__constructor__)) ?

From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
Sent: 2017年8月22日 20:23
To: Eric Chen ; vpp-dev 
Cc: odp4vpp-...@lists.fd.io
Subject: [EXT] RE: 回复：compiling error when build fd.io_odp4vpp with 
cross_compiler for aarch64 target

External Email

Which compiler are you using?

Gcc-5.4 on x86_64, i686, and aarch64-le - as well as clang - are perfectly 
happy to compile that idiom. I don’t see it as an error.

You might try combining the function declaration with the implementation, but 
be advised that there are numerous instances of a related idiom which will 
probably not compile, either:

void foo(void) __attribute__((weak)); void foo(void) { return 0;}

Thanks… Dave

From: Eric Chen [mailto:eri...@marvell.com]
Sent: Tuesday, August 22, 2017 8:16 AM
To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>; 
vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: odp4vpp-...@lists.fd.io
Subject: RE: 回复：compiling error when build fd.io_odp4vpp with cross_compiler 
for aarch64 target

Yes, Dave,

But issue #1,  first declare the func, (marked as yellow)
then define it,  my cross_compler report an error,
how to fix it?


#define VLIB_REGISTER_NODE(x,...)   \
__VA_ARGS__ vlib_node_registration_t x; \
static void __vlib_add_node_registration_##x (void) \
__attribute__((__constructor__)) ;  \
static void __vlib_add_node_registration_##x (void) \
{   \
vlib_main_t * vm = vlib_get_main(); \
x.next_registration = vm->node_main.node_registrations; \
vm->node_main.node_registrations = &x;  \
}   \
__VA_ARGS__ vlib_node_registration_t x


From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
Sent: 2017年8月22日 20:10
To: Eric Chen mailto:eri...@marvell.com>>; vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Cc: odp4vpp-...@lists.fd.io
Subject: [EXT] RE: 回复：compiling error when build fd.io_odp4vpp with 
cross_compiler for aarch64 target

External Email

The multiply-defined constructor function takes its name from the 
VLIB_REGISTER_NODE macro argument...


From: Eric Chen [mailto:eri...@marvell.com]
Sent: Tuesday, August 22, 2017 8:05 AM
To: Dave 

Re: [vpp-dev] Packet loss on use of API & cmdline

[Neale Ranns (nranns)]

Hi Colin,

The instances of barrier syncs you have correctly identified, occur only in the 
exceptional cases of route addition/deletion and not in the typical case.


-  adj_last_lock_gone () is called when that adjacency is no longer 
required, i.e. we are removing the last route, or probably the ARP entry, for a 
neighbour we presumably no longer have

-  adj_nbr_update_rewrite_internal() is called when the adjacency 
transitions from incomplete (not associated MAC rewrite) to complete.

-  The fix for 892 occurs when a route is added that is the first to 
create a new edge/arc in the VLIB node graph. In the case of that JIRA ticket, 
it was the first recursive route. Edges are never removed, so this is a once 
per-reboot event.

But in the typical case of adding routes, e.g. a BGP/OSPF convergence event, 
the adjacencies are present and complete and the VLIB graph is already setup, 
so the routes will be added in a lock/barrier free manner.

Pre-building the VLIB graph of all possibilities is wasteful IMHO, and given 
the one-time only lock, an acceptable trade off.
Adjacencies are more complicated. The state of the adjacency, incomplete or 
complete, determines the VLIB node the packet should go to. So one needs to 
atomically change the state of the adjacency and the state of the routes that 
use it - hence the barrier. We could solve that with indirection, but it would 
be indirection in the data-path and that costs cycles. So, again, given the 
relatively rarity of such an adjacency state change, the trade-off was to 
barrier sync.

Hth,
neale


From:  on behalf of Colin Tregenza Dancer via 
vpp-dev 
Reply-To: Colin Tregenza Dancer 
Date: Tuesday, 22 August 2017 at 12:25
To: Florin Coras 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] Packet loss on use of API & cmdline

Hi Florin,

Thanks for the quick, and very useful reply.

I’d been looking at the mp_safe flags, and had concluded that I’d need the 
calls I was interested in to be at least marked mp_safe.

However, I was thinking that wasn’t sufficient, as it appeared that some calls 
marked as mp_safe invoke barrier_sync lower down the call stacks.  For instance 
the internal functions adj_last_lock_gone(),  adj_nbr_update_rewrite_internal() 
and vlib_node_serialize() all seem to call vlib_worker_thread_barrier_sync(), 
and the fix for defect 892 
https://jira.fd.io/browse/VPP-892?gerritReviewStatus=All#gerrit-reviews-left-panel
 involves adding barrier calls in code related to the mp_safe ADD_DEL_ROUTE 
(which fits with packet loss I’d observed during testing of deleting routes).

I think the raw lossless packet processing which vpp has achieved on static 
configs is truly amazing, but I guess what I’m trying to understand is whether 
it is viewed as important to achieve similar behaviour when the system is being 
reconfigured.  Personally I think many of the potential uses of a software 
dataplane include the need to do limited impact dynamic reconfiguration, 
however, maybe the kind of applications I have in mind are in a minority?

More than anything,  given the number of areas which would likely be touched by 
the required changes, I wanted to understand if there is a consensus that such 
change was even needed?

Thanks in advance for any insight you (or others) can offer.

Cheers,

Colin.



From: Florin Coras [mailto:fcoras.li...@gmail.com]
Sent: 22 August 2017 09:40
To: Colin Tregenza Dancer 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Packet loss on use of API & cmdline

Hi Colin,

Your assumption was right. Most often than not, a binary API/CLI call results 
in a vlib_worker_thread_barrier_sync because most handlers and cli are not mp 
safe. As a consequence, vpp may experience packet loss.

One way around this issue, for binary APIs, is to make sure the handler you’re 
interested in is thread safe and then mark it is_mp_safe in api_main. See, for 
instance, VL_API_IP_ADD_DEL_ROUTE.

Hope this helps,
Florin

On Aug 22, 2017, at 1:11 AM, Colin Tregenza Dancer via vpp-dev 
mailto:vpp-dev@lists.fd.io>> wrote:

I might have just missed it, but looking through the ongoing regression tests I 
can’t see anything that explicitly tests for packet loss during CLI/API 
commands, so I’m wondering whether minimization of packet loss during 
configuration is viewed as a goal for vpp?

Many/most of the real world applications I’ve been exploring require the 
ability to reconfigure live systems without impacting the existing flows 
related to stable elements (route updates, tunnel add/remove, VM 
addition/removal), and it would be great to understand how this fit with vpp 
use cases.

Thanks again,

Colin.

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Colin Tregenza Dancer via 
vpp-dev
Sent: 19 August 2017 12:17
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Packet loss on use of API & cmdline

Hi,

I’ve been doing some pr

Re: [vpp-dev] set dpdk interface placement

[Billy McFall]

The command was renamed to:
   set/show interface rx-placement

On Tue, Aug 22, 2017 at 5:39 AM, 真我风采 <1534057...@qq.com> wrote:

> there is no the commad "vppctl set dpdk interface placement" in
> version17.07, but exist in version 17.04, this command has been abrogate
> ???
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>



-- 
*Billy McFall*
SDN Group
Office of Technology
*Red Hat*
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] 回复：compiling error when build fd.io_odp4vpp with cross_compiler for aarch64 target

[Dave Barach (dbarach)]

Which compiler are you using?

Gcc-5.4 on x86_64, i686, and aarch64-le - as well as clang - are perfectly 
happy to compile that idiom. I don’t see it as an error.

You might try combining the function declaration with the implementation, but 
be advised that there are numerous instances of a related idiom which will 
probably not compile, either:

void foo(void) __attribute__((weak)); void foo(void) { return 0;}

Thanks… Dave

From: Eric Chen [mailto:eri...@marvell.com]
Sent: Tuesday, August 22, 2017 8:16 AM
To: Dave Barach (dbarach) ; vpp-dev 
Cc: odp4vpp-...@lists.fd.io
Subject: RE: 回复：compiling error when build fd.io_odp4vpp with cross_compiler 
for aarch64 target

Yes, Dave,

But issue #1,  first declare the func, (marked as yellow)
then define it,  my cross_compler report an error,
how to fix it?


#define VLIB_REGISTER_NODE(x,...)   \
__VA_ARGS__ vlib_node_registration_t x; \
static void __vlib_add_node_registration_##x (void) \
__attribute__((__constructor__)) ;  \
static void __vlib_add_node_registration_##x (void) \
{   \
vlib_main_t * vm = vlib_get_main(); \
x.next_registration = vm->node_main.node_registrations; \
vm->node_main.node_registrations = &x;  \
}   \
__VA_ARGS__ vlib_node_registration_t x


From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
Sent: 2017年8月22日 20:10
To: Eric Chen mailto:eri...@marvell.com>>; vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Cc: odp4vpp-...@lists.fd.io
Subject: [EXT] RE: 回复：compiling error when build fd.io_odp4vpp with 
cross_compiler for aarch64 target

External Email

The multiply-defined constructor function takes its name from the 
VLIB_REGISTER_NODE macro argument...


From: Eric Chen [mailto:eri...@marvell.com]
Sent: Tuesday, August 22, 2017 8:05 AM
To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>; 
vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: odp4vpp-...@lists.fd.io
Subject: RE: 回复：compiling error when build fd.io_odp4vpp with cross_compiler 
for aarch64 target

Dave,

Yes, sure,
For issue#2,  either -DIPSEC=0, goes to different branch, or changes to 
different node name,  it can remove the error,  but if it’s the case, should 
anyone meet such failure before.

How about the issue #1?  Any compiling flags help?

Thanks
Eric

From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
Sent: 2017年8月22日 19:51
To: Eric Chen mailto:eri...@marvell.com>>; vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Cc: odp4vpp-...@lists.fd.io
Subject: [EXT] RE: 回复：compiling error when build fd.io_odp4vpp with 
cross_compiler for aarch64 target

External Email

Did you try changing the data structure names so they don’t conflict?

VLIB_REGISTER_NODE (ipsec_output4_node) + VLIB_REGISTER_NODE 
(ipsec_output6_node).

Feel free to submit a patch. (😉)...

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Eric Chen
Sent: Tuesday, August 22, 2017 6:19 AM
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: odp4vpp-...@lists.fd.io
Subject: [vpp-dev] 回复：compiling error when build fd.io_odp4vpp with 
cross_compiler for aarch64 target



HI

I try to build odp4vpp on a x86 host with the cross-compiler for machine of 
aarch64.

But encounter below errors, could you help me out?

1)
vpp/build-root/install-armada-a8k_debug-aarch64/vlib/include/vlib/node.h:147:13:
 error: redefinition of '__vlib_add_node_registration_ipsec_output_node'
static void __vlib_add_node_registration_##x (void)


node.h:147

#define VLIB_REGISTER_NODE(x,...)   \
__VA_ARGS__ vlib_node_registration_t x; \
static void __vlib_add_node_registration_##x (void) \
__attribute__((__constructor__)) ;  \
static void __vlib_add_node_registration_##x (void) \
{   \
vlib_main_t * vm = vlib_get_main(); \
x.next_registration = vm->node_main.node_registrations; \
vm->node_main.node_registrations = &x;  \
}   \
__VA_ARGS__ vlib_node_registration_t x


2)

In ./vpp/vnet/vnet/ipsec/ipsec_output.c

If -DIPSEC=0, (--without-ipsec)  then below will cause redefinition error as 
well,

/* *INDENT-OFF* */
VLIB_REGISTER_NODE (ipsec_output_node) = {
  .vector_size = sizeof (u32),

Re: [vpp-dev] 回复：compiling error when build fd.io_odp4vpp with cross_compiler for aarch64 target

[Eric Chen]

Yes, Dave,

But issue #1,  first declare the func, (marked as yellow)
then define it,  my cross_compler report an error,
how to fix it?


#define VLIB_REGISTER_NODE(x,...)   \
__VA_ARGS__ vlib_node_registration_t x; \
static void __vlib_add_node_registration_##x (void) \
__attribute__((__constructor__)) ;  \
static void __vlib_add_node_registration_##x (void) \
{   \
vlib_main_t * vm = vlib_get_main(); \
x.next_registration = vm->node_main.node_registrations; \
vm->node_main.node_registrations = &x;  \
}   \
__VA_ARGS__ vlib_node_registration_t x


From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
Sent: 2017年8月22日 20:10
To: Eric Chen ; vpp-dev 
Cc: odp4vpp-...@lists.fd.io
Subject: [EXT] RE: 回复：compiling error when build fd.io_odp4vpp with 
cross_compiler for aarch64 target

External Email

The multiply-defined constructor function takes its name from the 
VLIB_REGISTER_NODE macro argument...


From: Eric Chen [mailto:eri...@marvell.com]
Sent: Tuesday, August 22, 2017 8:05 AM
To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>; 
vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: odp4vpp-...@lists.fd.io
Subject: RE: 回复：compiling error when build fd.io_odp4vpp with cross_compiler 
for aarch64 target

Dave,

Yes, sure,
For issue#2,  either -DIPSEC=0, goes to different branch, or changes to 
different node name,  it can remove the error,  but if it’s the case, should 
anyone meet such failure before.

How about the issue #1?  Any compiling flags help?

Thanks
Eric

From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
Sent: 2017年8月22日 19:51
To: Eric Chen mailto:eri...@marvell.com>>; vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Cc: odp4vpp-...@lists.fd.io
Subject: [EXT] RE: 回复：compiling error when build fd.io_odp4vpp with 
cross_compiler for aarch64 target

External Email

Did you try changing the data structure names so they don’t conflict?

VLIB_REGISTER_NODE (ipsec_output4_node) + VLIB_REGISTER_NODE 
(ipsec_output6_node).

Feel free to submit a patch. (😉)...

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Eric Chen
Sent: Tuesday, August 22, 2017 6:19 AM
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: odp4vpp-...@lists.fd.io
Subject: [vpp-dev] 回复：compiling error when build fd.io_odp4vpp with 
cross_compiler for aarch64 target



HI

I try to build odp4vpp on a x86 host with the cross-compiler for machine of 
aarch64.

But encounter below errors, could you help me out?

1)
vpp/build-root/install-armada-a8k_debug-aarch64/vlib/include/vlib/node.h:147:13:
 error: redefinition of '__vlib_add_node_registration_ipsec_output_node'
static void __vlib_add_node_registration_##x (void)


node.h:147

#define VLIB_REGISTER_NODE(x,...)   \
__VA_ARGS__ vlib_node_registration_t x; \
static void __vlib_add_node_registration_##x (void) \
__attribute__((__constructor__)) ;  \
static void __vlib_add_node_registration_##x (void) \
{   \
vlib_main_t * vm = vlib_get_main(); \
x.next_registration = vm->node_main.node_registrations; \
vm->node_main.node_registrations = &x;  \
}   \
__VA_ARGS__ vlib_node_registration_t x


2)

In ./vpp/vnet/vnet/ipsec/ipsec_output.c

If -DIPSEC=0, (--without-ipsec)  then below will cause redefinition error as 
well,

/* *INDENT-OFF* */
VLIB_REGISTER_NODE (ipsec_output_node) = {
  .vector_size = sizeof (u32),
  .function = ipsec_output_node_fn,
  .name = "ipsec-output-ip4",
};

VLIB_REGISTER_NODE (ipsec_output_node) = {
  .vector_size = sizeof (u32),
  .function = ipsec_output_node_fn,
  .name = "ipsec-output-ip6",
};



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

Re: [vpp-dev] 回复：compiling error when build fd.io_odp4vpp with cross_compiler for aarch64 target

[Dave Barach (dbarach)]

The multiply-defined constructor function takes its name from the 
VLIB_REGISTER_NODE macro argument...


From: Eric Chen [mailto:eri...@marvell.com]
Sent: Tuesday, August 22, 2017 8:05 AM
To: Dave Barach (dbarach) ; vpp-dev 
Cc: odp4vpp-...@lists.fd.io
Subject: RE: 回复：compiling error when build fd.io_odp4vpp with cross_compiler 
for aarch64 target

Dave,

Yes, sure,
For issue#2,  either -DIPSEC=0, goes to different branch, or changes to 
different node name,  it can remove the error,  but if it’s the case, should 
anyone meet such failure before.

How about the issue #1?  Any compiling flags help?

Thanks
Eric

From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
Sent: 2017年8月22日 19:51
To: Eric Chen mailto:eri...@marvell.com>>; vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Cc: odp4vpp-...@lists.fd.io
Subject: [EXT] RE: 回复：compiling error when build fd.io_odp4vpp with 
cross_compiler for aarch64 target

External Email

Did you try changing the data structure names so they don’t conflict?

VLIB_REGISTER_NODE (ipsec_output4_node) + VLIB_REGISTER_NODE 
(ipsec_output6_node).

Feel free to submit a patch. (😉)...

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Eric Chen
Sent: Tuesday, August 22, 2017 6:19 AM
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: odp4vpp-...@lists.fd.io
Subject: [vpp-dev] 回复：compiling error when build fd.io_odp4vpp with 
cross_compiler for aarch64 target



HI

I try to build odp4vpp on a x86 host with the cross-compiler for machine of 
aarch64.

But encounter below errors, could you help me out?

1)
vpp/build-root/install-armada-a8k_debug-aarch64/vlib/include/vlib/node.h:147:13:
 error: redefinition of '__vlib_add_node_registration_ipsec_output_node'
static void __vlib_add_node_registration_##x (void)


node.h:147

#define VLIB_REGISTER_NODE(x,...)   \
__VA_ARGS__ vlib_node_registration_t x; \
static void __vlib_add_node_registration_##x (void) \
__attribute__((__constructor__)) ;  \
static void __vlib_add_node_registration_##x (void) \
{   \
vlib_main_t * vm = vlib_get_main(); \
x.next_registration = vm->node_main.node_registrations; \
vm->node_main.node_registrations = &x;  \
}   \
__VA_ARGS__ vlib_node_registration_t x


2)

In ./vpp/vnet/vnet/ipsec/ipsec_output.c

If -DIPSEC=0, (--without-ipsec)  then below will cause redefinition error as 
well,

/* *INDENT-OFF* */
VLIB_REGISTER_NODE (ipsec_output_node) = {
  .vector_size = sizeof (u32),
  .function = ipsec_output_node_fn,
  .name = "ipsec-output-ip4",
};

VLIB_REGISTER_NODE (ipsec_output_node) = {
  .vector_size = sizeof (u32),
  .function = ipsec_output_node_fn,
  .name = "ipsec-output-ip6",
};



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

Re: [vpp-dev] 回复：compiling error when build fd.io_odp4vpp with cross_compiler for aarch64 target

[Eric Chen]

Dave,

Yes, sure,
For issue#2,  either -DIPSEC=0, goes to different branch, or changes to 
different node name,  it can remove the error,  but if it’s the case, should 
anyone meet such failure before.

How about the issue #1?  Any compiling flags help?

Thanks
Eric

From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
Sent: 2017年8月22日 19:51
To: Eric Chen ; vpp-dev 
Cc: odp4vpp-...@lists.fd.io
Subject: [EXT] RE: 回复：compiling error when build fd.io_odp4vpp with 
cross_compiler for aarch64 target

External Email

Did you try changing the data structure names so they don’t conflict?

VLIB_REGISTER_NODE (ipsec_output4_node) + VLIB_REGISTER_NODE 
(ipsec_output6_node).

Feel free to submit a patch. (😉)...

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Eric Chen
Sent: Tuesday, August 22, 2017 6:19 AM
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: odp4vpp-...@lists.fd.io
Subject: [vpp-dev] 回复：compiling error when build fd.io_odp4vpp with 
cross_compiler for aarch64 target



HI

I try to build odp4vpp on a x86 host with the cross-compiler for machine of 
aarch64.

But encounter below errors, could you help me out?

1)
vpp/build-root/install-armada-a8k_debug-aarch64/vlib/include/vlib/node.h:147:13:
 error: redefinition of '__vlib_add_node_registration_ipsec_output_node'
static void __vlib_add_node_registration_##x (void)


node.h:147

#define VLIB_REGISTER_NODE(x,...)   \
__VA_ARGS__ vlib_node_registration_t x; \
static void __vlib_add_node_registration_##x (void) \
__attribute__((__constructor__)) ;  \
static void __vlib_add_node_registration_##x (void) \
{   \
vlib_main_t * vm = vlib_get_main(); \
x.next_registration = vm->node_main.node_registrations; \
vm->node_main.node_registrations = &x;  \
}   \
__VA_ARGS__ vlib_node_registration_t x


2)

In ./vpp/vnet/vnet/ipsec/ipsec_output.c

If -DIPSEC=0, (--without-ipsec)  then below will cause redefinition error as 
well,

/* *INDENT-OFF* */
VLIB_REGISTER_NODE (ipsec_output_node) = {
  .vector_size = sizeof (u32),
  .function = ipsec_output_node_fn,
  .name = "ipsec-output-ip4",
};

VLIB_REGISTER_NODE (ipsec_output_node) = {
  .vector_size = sizeof (u32),
  .function = ipsec_output_node_fn,
  .name = "ipsec-output-ip6",
};



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

Re: [vpp-dev] [discuss] Question about VPP support for ARM 64

[Damjan Marion (damarion)]

Dear George,

I tried on my Cavium ThunderX system with latest Ubuntu and after fixing few 
minor issues (all patches submitted to master) I got VPP running.
I use latest Ubuntu devel (17.10, mainly as I upgraded to new kernel in my 
attempts to get system working)

For me it is hard to help you with your particular system, as I don’t have 
access to similar one, but my guess is that it shouldn’’t be too hard to get it 
working.

Thanks,

Damjan

On 20 Aug 2017, at 23:12, George Zhao 
mailto:george.y.z...@huawei.com>> wrote:

Hi Damian,

IT is Applied Micro overdrive 1000, here are the uname -a output:

$>> uname -a
Linux OD1K 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:10:33 UTC 2017 
aarch64 aarch64 aarch64 GNU/Linux

thanks
George
发件人：Damjan Marion (damarion)
收件人：George Zhao
抄送：dbarach,discuss,csit-dev,vpp-dev
时间：2017-08-20 10:03:27
主题:Re: [vpp-dev] [discuss] Question about VPP support for ARM 64



George, are you using ThunderX platform?

I spent few hours today trying to install latest ubuntu on my ThunderX system 
but no luck, kernel hangs at some point, both ubuntu provided and manually 
compiled.

Can you share about more details about your system?

Thanks,

Damjan



> On 19 Aug 2017, at 22:48, George Zhao 
> mailto:george.y.z...@huawei.com>> wrote:
>
> If a bug is filed, may I have the bug number, I would be love to trace this 
> patch.
>
> BTW, how do I file a bug for VPP, I did a quick wiki search with no luck.
>
> Thanks,
> George
>
> -Original Message-
> From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
> Sent: Saturday, August 19, 2017 7:42 AM
> To: George Zhao mailto:george.y.z...@huawei.com>>
> Cc: vpp-dev@lists.fd.io; 
> disc...@lists.fd.io; 
> csit-...@lists.fd.io; Damjan Marion (damarion) 
> mailto:damar...@cisco.com>>
> Subject: RE: [discuss] Question about VPP support for ARM 64
>
> +1, pls add the typedef...
>
> Thanks… Dave
>
> -Original Message-
> From: Damjan Marion (damarion)
> Sent: Saturday, August 19, 2017 9:09 AM
> To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>
> Cc: George Zhao mailto:george.y.z...@huawei.com>>; 
> vpp-dev@lists.fd.io; 
> disc...@lists.fd.io; 
> csit-...@lists.fd.io
> Subject: Re: [discuss] Question about VPP support for ARM 64
>
>
> GCC is able to compile ARM64 code with 256-bit vectors even if target 
> platform have only 128-bit registers.
>
> I.e. for the u8x32 version of that function it generates:
>
> ARM64:
> dpdk_buffer_init_from_template(void*, void*, void*, void*, void*):
>ld1 {v0.16b - v1.16b}, [x4], 32
>st1 {v0.16b - v1.16b}, [x3], 32
>st1 {v0.16b - v1.16b}, [x2], 32
>st1 {v0.16b - v1.16b}, [x1], 32
>st1 {v0.16b - v1.16b}, [x0], 32
>ld1 {v0.16b - v1.16b}, [x4]
>st1 {v0.16b - v1.16b}, [x3]
>st1 {v0.16b - v1.16b}, [x2]
>st1 {v0.16b - v1.16b}, [x1]
>st1 {v0.16b - v1.16b}, [x0]
>ret
>
> intel x86-64 without AVX2:
>
> dpdk_buffer_init_from_template(void*, void*, void*, void*, void*):
> push   %rbp
> mov%rsp,%rbp
> and$0xffe0,%rsp
> lea0x10(%rsp),%rsp
> movdqa (%r8),%xmm1
> movdqa 0x10(%r8),%xmm0
> movdqa %xmm0,0x10(%rcx)
> movdqa %xmm1,(%rcx)
> movdqa %xmm1,(%rdx)
> movdqa %xmm0,0x10(%rdx)
> movdqa %xmm1,(%rsi)
> movdqa %xmm0,0x10(%rsi)
> movdqa %xmm1,(%rdi)
> movdqa %xmm0,0x10(%rdi)
> movdqa 0x20(%r8),%xmm1
> movdqa 0x30(%r8),%xmm0
> movdqa %xmm0,0x30(%rcx)
> movdqa %xmm1,0x20(%rcx)
> movdqa %xmm1,0x20(%rdx)
> movdqa %xmm0,0x30(%rdx)
> movdqa %xmm1,0x20(%rsi)
> movdqa %xmm0,0x30(%rsi)
> movdqa %xmm1,0x20(%rdi)
> movdqa %xmm0,0x30(%rdi)
> leaveq
> retq
>
>
> So i think here it is only about missing typedef….
>
>
>> On 19 Aug 2017, at 14:51, Dave Barach (dbarach) 
>> mailto:dbar...@cisco.com>> wrote:
>>
>> Dear George,
>>
>> This specific issue isn’t anywhere near as bad as you might think. As given, 
>> the code confuses 128-bit vectors with 256-bit vectors, and 64-bit vectors 
>> with 128-bit vectors.
>>
>> Question: does the hardware involved support 256-bit vectors? Probably 
>> not... It almost certainly does support 128-bit vectors.
>>
>> To make progress, use the known-good u8x16 / 128-bit vector code:
>>
>> static_always_inline void
>> dpdk_buffer_init_from_template (void *d0, void *d1, void *d2, void *d3,
>>  void *s)
>> {
>> #if defined(CLIB_HAVE_VEC128)
>>  int i;
>>  for (i = 0; i < 4; i++)
>>{
>>  *(u8x16 *) (((u8 *) d0) + i * 16) =
>> *(u8x16 *) (((u8 *) d1) + i * 16) =
>> *(u8x16 *) (((u8 *) d2) + i * 16) =
>> *(u8x16 *) (((u8 *) d3) + i * 16) = *(u8x16 *) (((u8 *) s) + i * 16);
>>}
>> #else
>> #error "CLIB_HAVE_VEC128 has to be defined"
>> #endif
>> }
>>
>> Responsible parties - they know who they are - will be back from PTO 
>> shortly. We need t

Re: [vpp-dev] 回复：compiling error when build fd.io_odp4vpp with cross_compiler for aarch64 target

[Dave Barach (dbarach)]

Did you try changing the data structure names so they don’t conflict?

VLIB_REGISTER_NODE (ipsec_output4_node) + VLIB_REGISTER_NODE 
(ipsec_output6_node).

Feel free to submit a patch. (😉)...

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Eric Chen
Sent: Tuesday, August 22, 2017 6:19 AM
To: vpp-dev 
Cc: odp4vpp-...@lists.fd.io
Subject: [vpp-dev] 回复：compiling error when build fd.io_odp4vpp with 
cross_compiler for aarch64 target




HI

I try to build odp4vpp on a x86 host with the cross-compiler for machine of 
aarch64.

But encounter below errors, could you help me out?

1)
vpp/build-root/install-armada-a8k_debug-aarch64/vlib/include/vlib/node.h:147:13:
 error: redefinition of '__vlib_add_node_registration_ipsec_output_node'
static void __vlib_add_node_registration_##x (void)


node.h:147

#define VLIB_REGISTER_NODE(x,...)   \
__VA_ARGS__ vlib_node_registration_t x; \
static void __vlib_add_node_registration_##x (void) \
__attribute__((__constructor__)) ;  \
static void __vlib_add_node_registration_##x (void) \
{   \
vlib_main_t * vm = vlib_get_main(); \
x.next_registration = vm->node_main.node_registrations; \
vm->node_main.node_registrations = &x;  \
}   \
__VA_ARGS__ vlib_node_registration_t x


2)

In ./vpp/vnet/vnet/ipsec/ipsec_output.c

If -DIPSEC=0, (--without-ipsec)  then below will cause redefinition error as 
well,

/* *INDENT-OFF* */
VLIB_REGISTER_NODE (ipsec_output_node) = {
  .vector_size = sizeof (u32),
  .function = ipsec_output_node_fn,
  .name = "ipsec-output-ip4",
};

VLIB_REGISTER_NODE (ipsec_output_node) = {
  .vector_size = sizeof (u32),
  .function = ipsec_output_node_fn,
  .name = "ipsec-output-ip6",
};



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

[vpp-dev] fd.io_odp4vpp running on top of an aarch64 box

[Eric Chen]

HI

I am trying to run fd.io_odp4vpp over marvell machhiatoBin(a community board 
based on marvell armada-a8k A72 SoC),
I am passing the compiling, but when I run vpp in the live board, shows below 
error:

I didn't change any code itself(only one to pass the compiling error, see 
below) , but add a new .mk,

Could anyone help me out?


(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /root/work/opnfv/fd.io_odp4vpp/vpp/bin/vpp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
unix_physmem_init: use huge pages
vlib_plugin_early_init:213: plugin path /usr/lib/vpp_plugins

Breakpoint 1, ppp_input_init (vm=0x7fb7f4d2c0 )
at 
/mnt/disk1/ericxh/work/git_work/fd.io_odp4vpp/vpp/build-data/../vnet/vnet/ppp/node.c:299
299 {
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /root/work/opnfv/fd.io_odp4vpp/vpp/bin/vpp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
unix_physmem_init: use huge pages
vlib_plugin_early_init:213: plugin path /usr/lib/vpp_plugins

Breakpoint 1, ppp_input_init (vm=0x7fb7f4d2c0 )
at 
/mnt/disk1/ericxh/work/git_work/fd.io_odp4vpp/vpp/build-data/../vnet/vnet/ppp/node.c:299
299 {
(gdb) n
303 clib_error_t *error = vlib_call_init_function (vm, ppp_init);
(gdb)
304 if (error)
(gdb)
308   ppp_setup_node (vm, ppp_input_node.index);
(gdb)
310   rt = vlib_node_get_runtime_data (vm, ppp_input_node.index);
(gdb)
312   rt->next_by_protocol = sparse_vec_new
(gdb)
316   vec_validate (rt->sparse_index_by_next_index, PPP_INPUT_NEXT_DROP);
(gdb) s
_vec_resize (v=0x7fb7ec60a0 , length_increment=2,
data_bytes=8, header_bytes=0, data_align=0)
at 
/mnt/disk1/ericxh/work/git_work/fd.io_odp4vpp/vpp/build-root/install-armada-a8k_debug-aarch64/vppinfra/include/vppinfra/vec.h:118
118 {
(gdb) n
119   vec_header_t *vh = _vec_find (v);
(gdb)
122   aligned_header_bytes = vec_header_bytes (header_bytes);
(gdb)
124   new_data_bytes = data_bytes + aligned_header_bytes;
(gdb)
126   if (PREDICT_TRUE (v != 0))
(gdb)
128   void *p = v - aligned_header_bytes;
(gdb)
131   ASSERT (clib_mem_is_heap_object (p));
(gdb)
0: 
/mnt/disk1/ericxh/work/git_work/fd.io_odp4vpp/vpp/build-root/install-armada-a8k_debug-aarch64/vppinfra/include/vppinfra/vec.h:131
 (_vec_resize) assertion `clib_mem_is_heap_object (p)' fails

Program received signal SIGABRT, Aborted.
0x007fb7472a4c in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:55
55  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) info stack
#0  0x007fb7472a4c in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:55
#1  0x007fb7473ea0 in __GI_abort () at abort.c:89
#2  0x0040b848 in os_panic ()
at 
/mnt/disk1/ericxh/work/git_work/fd.io_odp4vpp/vpp/build-data/../vpp/vnet/main.c:330
#3  0x007fb78865ec in debugger ()
at 
/mnt/disk1/ericxh/work/git_work/fd.io_odp4vpp/vpp/build-data/../vppinfra/vppinfra/error.c:84
#4  0x007fb7886a1c in _clib_error (how_to_die=2, function_name=0x0,
line_number=0, fmt=0x7fb7d7e638 "%s:%d (%s) assertion `%s' fails")
at 
/mnt/disk1/ericxh/work/git_work/fd.io_odp4vpp/vpp/build-data/../vppinfra/vppinfra/error.c:143
#5  0x007fb7a78250 in _vec_resize (
v=0x7fb7ec60a0 , length_increment=2,
data_bytes=8, header_bytes=0, data_align=0)
   at 
/mnt/disk1/ericxh/work/git_work/fd.io_odp4vpp/vpp/build-root/install-armada-a8k_debug-aarch64/vppinfra/include/vppinfra/vec.h:131
#6  0x007fb7a7a92c in ppp_input_init (vm=0x7fb7f4d2c0 )
at 
/mnt/disk1/ericxh/work/git_work/fd.io_odp4vpp/vpp/build-data/../vnet/vnet/ppp/node.c:316
#7  0x007fb7a7abd0 in ppp_register_input_protocol (
vm=0x7fb7f4d2c0 , protocol=PPP_PROTOCOL_osi,
---Type  to continue, or q  to quit---
node_index=0)
at 
/mnt/disk1/ericxh/work/git_work/fd.io_odp4vpp/vpp/build-data/../vnet/vnet/ppp/node.c:339
#8  0x007fb7b9a354 in osi_input_init (vm=0x7fb7f4d2c0 )
at 
/mnt/disk1/ericxh/work/git_work/fd.io_odp4vpp/vpp/build-data/../vnet/vnet/osi/node.c:282
#9  0x007fb7a8948c in llc_register_input_protocol (
vm=0x7fb7f4d2c0 , protocol=LLC_PROTOCOL_snap,
node_index=0)
at 
/mnt/disk1/ericxh/work/git_work/fd.io_odp4vpp/vpp/build-data/../vnet/vnet/llc/node.c:313
#10 0x007fb7a8e33c in snap_input_init (vm=0x7fb7f4d2c0 )
at 
/mnt/disk1/ericxh/work/git_work/fd.io_odp4vpp/vpp/build-data/../vnet/vnet/snap/node.c:303
#11 0x007fb7a8c53c in snap_init (vm=0x7fb7f4d2c0 )
at 
/mnt/disk1/ericxh/work/git_work/fd.io_odp4vpp/vpp/build-data/../vnet/vnet/snap/snap.c:192
#12 0x007fb7a8771c in llc_init (vm=0x7fb7f4d2c0 )
at 
/mnt/disk1/ericxh/work/git_work/fd.io_odp4vpp/vpp/build-data/../vnet/

[vpp-dev] vpp libpcap-based pmd

[????????]

Hi,
I am using VPP on SUSE??I know that the DPDK includes libpcap-based PMD??and I 
have already binded network interface
through --vdev. I want to know whether this way can be used in VPP and how to 
use it.
Thanks in advance.
Long Zhang___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] how to apt-get install default-jdk-headless

[Eric Chen]

Hi

I run "make install-dep" on top of an aarch64 box with Ubuntu 14.04 installed.
However it reminder of me - "the package of default-jdk-headless can not be 
located".

So anyone could tell me the apt-get source list  which include 
default-jdk-headless?

Thanks
Eric

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

[vpp-dev] set dpdk interface placement

[????????]

there is no the commad "vppctl set dpdk interface placement" in version17.07, 
but exist in version 17.04, this command has been abrogate ???___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Packet loss on use of API & cmdline

[Colin Tregenza Dancer via vpp-dev]

Hi Florin,

Thanks for the quick, and very useful reply.

I’d been looking at the mp_safe flags, and had concluded that I’d need the 
calls I was interested in to be at least marked mp_safe.

However, I was thinking that wasn’t sufficient, as it appeared that some calls 
marked as mp_safe invoke barrier_sync lower down the call stacks.  For instance 
the internal functions adj_last_lock_gone(),  adj_nbr_update_rewrite_internal() 
and vlib_node_serialize() all seem to call vlib_worker_thread_barrier_sync(), 
and the fix for defect 892 
https://jira.fd.io/browse/VPP-892?gerritReviewStatus=All#gerrit-reviews-left-panel
 involves adding barrier calls in code related to the mp_safe ADD_DEL_ROUTE 
(which fits with packet loss I’d observed during testing of deleting routes).

I think the raw lossless packet processing which vpp has achieved on static 
configs is truly amazing, but I guess what I’m trying to understand is whether 
it is viewed as important to achieve similar behaviour when the system is being 
reconfigured.  Personally I think many of the potential uses of a software 
dataplane include the need to do limited impact dynamic reconfiguration, 
however, maybe the kind of applications I have in mind are in a minority?

More than anything,  given the number of areas which would likely be touched by 
the required changes, I wanted to understand if there is a consensus that such 
change was even needed?

Thanks in advance for any insight you (or others) can offer.

Cheers,

Colin.



From: Florin Coras [mailto:fcoras.li...@gmail.com]
Sent: 22 August 2017 09:40
To: Colin Tregenza Dancer 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Packet loss on use of API & cmdline

Hi Colin,

Your assumption was right. Most often than not, a binary API/CLI call results 
in a vlib_worker_thread_barrier_sync because most handlers and cli are not mp 
safe. As a consequence, vpp may experience packet loss.

One way around this issue, for binary APIs, is to make sure the handler you’re 
interested in is thread safe and then mark it is_mp_safe in api_main. See, for 
instance, VL_API_IP_ADD_DEL_ROUTE.

Hope this helps,
Florin

On Aug 22, 2017, at 1:11 AM, Colin Tregenza Dancer via vpp-dev 
mailto:vpp-dev@lists.fd.io>> wrote:

I might have just missed it, but looking through the ongoing regression tests I 
can’t see anything that explicitly tests for packet loss during CLI/API 
commands, so I’m wondering whether minimization of packet loss during 
configuration is viewed as a goal for vpp?

Many/most of the real world applications I’ve been exploring require the 
ability to reconfigure live systems without impacting the existing flows 
related to stable elements (route updates, tunnel add/remove, VM 
addition/removal), and it would be great to understand how this fit with vpp 
use cases.

Thanks again,

Colin.

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Colin Tregenza Dancer via 
vpp-dev
Sent: 19 August 2017 12:17
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Packet loss on use of API & cmdline

Hi,

I’ve been doing some prototyping and load testing of the vpp dataplane, and 
have observed packet loss when I issue API requests or use the debug command 
line.  Is this to be expected given the use of the worker_thread_barrier, or 
might there be some way I could improve matters?

Currently I’m running a fairly modest 2Mpps throughput between a pair of 10G 
ports on an Intel X520 NIC, with baremetal Ubuntu 16, & vpp 17.01.

Thanks in advance,

Colin.
___
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] 回复：compiling error when build fd.io_odp4vpp with cross_compiler for aarch64 target

[Eric Chen]

HI

I try to build odp4vpp on a x86 host with the cross-compiler for machine of 
aarch64.

But encounter below errors, could you help me out?

1)
vpp/build-root/install-armada-a8k_debug-aarch64/vlib/include/vlib/node.h:147:13:
 error: redefinition of '__vlib_add_node_registration_ipsec_output_node'
static void __vlib_add_node_registration_##x (void)


node.h:147

#define VLIB_REGISTER_NODE(x,...)   \
__VA_ARGS__ vlib_node_registration_t x; \
static void __vlib_add_node_registration_##x (void) \
__attribute__((__constructor__)) ;  \
static void __vlib_add_node_registration_##x (void) \
{   \
vlib_main_t * vm = vlib_get_main(); \
x.next_registration = vm->node_main.node_registrations; \
vm->node_main.node_registrations = &x;  \
}   \
__VA_ARGS__ vlib_node_registration_t x


2)

In ./vpp/vnet/vnet/ipsec/ipsec_output.c

If -DIPSEC=0, (--without-ipsec)  then below will cause redefinition error as 
well,

/* *INDENT-OFF* */
VLIB_REGISTER_NODE (ipsec_output_node) = {
  .vector_size = sizeof (u32),
  .function = ipsec_output_node_fn,
  .name = "ipsec-output-ip4",
};

VLIB_REGISTER_NODE (ipsec_output_node) = {
  .vector_size = sizeof (u32),
  .function = ipsec_output_node_fn,
  .name = "ipsec-output-ip6",
};



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

Re: [vpp-dev] Packet loss on use of API & cmdline

[Florin Coras]

Hi Colin,

Your assumption was right. Most often than not, a binary API/CLI call results 
in a vlib_worker_thread_barrier_sync because most handlers and cli are not mp 
safe. As a consequence, vpp may experience packet loss.

One way around this issue, for binary APIs, is to make sure the handler you’re 
interested in is thread safe and then mark it is_mp_safe in api_main. See, for 
instance, VL_API_IP_ADD_DEL_ROUTE. 

Hope this helps, 
Florin 

> On Aug 22, 2017, at 1:11 AM, Colin Tregenza Dancer via vpp-dev 
>  wrote:
> 
> I might have just missed it, but looking through the ongoing regression tests 
> I can’t see anything that explicitly tests for packet loss during CLI/API 
> commands, so I’m wondering whether minimization of packet loss during 
> configuration is viewed as a goal for vpp?  
>  
> Many/most of the real world applications I’ve been exploring require the 
> ability to reconfigure live systems without impacting the existing flows 
> related to stable elements (route updates, tunnel add/remove, VM 
> addition/removal), and it would be great to understand how this fit with vpp 
> use cases.
>  
> Thanks again,
>  
> Colin.
>   <>
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
> Behalf Of Colin Tregenza Dancer via vpp-dev
> Sent: 19 August 2017 12:17
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Packet loss on use of API & cmdline
>  
> Hi,
>  
> I’ve been doing some prototyping and load testing of the vpp dataplane, and 
> have observed packet loss when I issue API requests or use the debug command 
> line.  Is this to be expected given the use of the worker_thread_barrier, or 
> might there be some way I could improve matters?
>  
> Currently I’m running a fairly modest 2Mpps throughput between a pair of 10G 
> ports on an Intel X520 NIC, with baremetal Ubuntu 16, & vpp 17.01.
>  
> Thanks in advance,
>  
> Colin. 
> ___
> 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] Packet loss on use of API & cmdline

[Colin Tregenza Dancer via vpp-dev]

I might have just missed it, but looking through the ongoing regression tests I 
can't see anything that explicitly tests for packet loss during CLI/API 
commands, so I'm wondering whether minimization of packet loss during 
configuration is viewed as a goal for vpp?

Many/most of the real world applications I've been exploring require the 
ability to reconfigure live systems without impacting the existing flows 
related to stable elements (route updates, tunnel add/remove, VM 
addition/removal), and it would be great to understand how this fit with vpp 
use cases.

Thanks again,

Colin.

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Colin Tregenza Dancer via vpp-dev
Sent: 19 August 2017 12:17
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Packet loss on use of API & cmdline

Hi,

I've been doing some prototyping and load testing of the vpp dataplane, and 
have observed packet loss when I issue API requests or use the debug command 
line.  Is this to be expected given the use of the worker_thread_barrier, or 
might there be some way I could improve matters?

Currently I'm running a fairly modest 2Mpps throughput between a pair of 10G 
ports on an Intel X520 NIC, with baremetal Ubuntu 16, & vpp 17.01.

Thanks in advance,

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