Re: [vpp-dev] make test-all

[Gabriel Ganne]

Aside from this p2p_ethernet load test, the only failing extended test is the 
whole TestVxlanGpe class.

The reason is that scapy 2.3.3 does not know of layer VXLAN, and there is no 
scapy patch within vpp to address this.

How do you want to handle this ?


--

Gabriel Ganne


From: vpp-dev-boun...@lists.fd.io  on behalf of 
Brian Brooks 
Sent: Tuesday, November 14, 2017 1:27:47 PM
To: Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco); Ole Troan
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] make test-all

It does not complete within 20 minutes on other machines.

> I don't think we should do scale tests as part of verification tests.

Agree


-Original Message-
From: Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco) 
[mailto:ksek...@cisco.com]
Sent: Tuesday, November 14, 2017 2:47 AM
To: Ole Troan 
Cc: Dave Barach (dbarach) ; John Lo (loj) ; 
Pavel Kotucek -X (pkotucek - PANTHEON TECHNOLOGIES at Cisco) 
; vpp-dev@lists.fd.io; Brian Brooks 
Subject: Re: [vpp-dev] make test-all

It is ...

it takes ~10 seconds to create 1000 subifs on a beefy UCS and the case tries to 
create 10, so that would indicate a runtime of ~16minutes...

Quoting Ole Troan (2017-11-14 03:53:28)
> Klement,
>
> > I don't know what to tell you ... I was never a fan of getting the
> > API trace post test run and putting it into test log (which is the
> > cause of 25MB allocation in this case - it's the CLI output) - from
> > my POV this is duplicate information as every API call is already
> > logged in-place when it's executed... BUT I didn't saw any harm in
> > doing so (besides clutter) and since the "create bazillion
> > subinterfaces" test went in without me being part of review process, I 
> > wasn't aware of it...
>
> If this is in test_p2p_ethernet, let me take that out.
> I don't think we should do scale tests as part of verification tests.
> I do not like the path we're on with regards to test run time.
>
> Cheers,
> Ole
>
> > Quoting Dave Barach (dbarach) (2017-11-13 13:33:41)
> >> Try increasing the size of the shared-memory API segment. An allocation of 
> >> 25mb is failing. You might ask yourself how sane it is to generate that 
> >> much output.
> >>
> >> Thanks… Dave
> >>
> >> -Original Message-
> >> From: vpp-dev-boun...@lists.fd.io
> >> [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Klement Sekera -X
> >> (ksekera - PANTHEON TECHNOLOGIES at Cisco)
> >> Sent: Monday, November 13, 2017 5:27 AM
> >> To: John Lo (loj) ; Pavel Kotucek -X (pkotucek -
> >> PANTHEON TECHNOLOGIES at Cisco) ;
> >> vpp-dev@lists.fd.io; Brian Brooks 
> >> Subject: Re: [vpp-dev] make test-all
> >>
> >> So it seems that vpp coredumps while dumping the API trace after
> >> creating all the interfaces...
> >>
> >> (gdb) bt
> >> #0  0x7f14f4b1e428 in __GI_raise (sig=sig@entry=6) at
> >> ../sysdeps/unix/sysv/linux/raise.c:54
> >> #1  0x7f14f4b2002a in __GI_abort () at abort.c:89
> >> #2  0x00405d83 in os_panic () at
> >> /home/ksekera/vpp/build-data/../src/vpp/vnet/main.c:268
> >> #3  0x7f14f5fe5f86 in clib_mem_alloc_aligned_at_offset 
> >> (os_out_of_memory_on_failure=1, align_offset=0, align=1, size=25282098)
> >>at /home/ksekera/vpp/build-data/../src/vppinfra/mem.h:105
> >> #4  clib_mem_alloc (size=25282098) at
> >> /home/ksekera/vpp/build-data/../src/vppinfra/mem.h:114
> >> #5  vl_msg_api_alloc_internal (may_return_null=0, pool=, 
> >> nbytes=25282098)
> >>at
> >> /home/ksekera/vpp/build-data/../src/vlibmemory/memory_shared.c:176
> >> #6  vl_msg_api_alloc (nbytes=nbytes@entry=25282082) at
> >> /home/ksekera/vpp/build-data/../src/vlibmemory/memory_shared.c:207
> >> #7  0x00411392 in vl_api_cli_inband_t_handler
> >> (mp=0x300e2a0c) at
> >> /home/ksekera/vpp/build-data/../src/vpp/api/api.c:223
> >> #8  0x7f14f5fdfa23 in vl_msg_api_handler_with_vm_node 
> >> (am=am@entry=0x7f14f620d460 , the_msg=the_msg@entry=0x300e2a0c,
> >>vm=vm@entry=0x7f14f5fd6260 ,
> >> node=node@entry=0x7f14b410e000) at
> >> /home/ksekera/vpp/build-data/../src/vlibapi/api_shared.c:508
> >> #9  0x7f14f5fef35f in memclnt_process (vm=0x7f14f5fd6260 
> >> , node=0x7f14b410e000, f=)
> >>at
> >> /home/ksekera/vpp/build-data/../src/vlibmemory/memory_vlib.c:970
> >>
> >> (gdb) p input
> >> $5 = {buffer = 0x7f14b56f6558 "dump
> >> /tmp/vpp-unittest-P2PEthernetAPI-qRwMY6/vpp_api_trace.test_p2p_subi
> >> f_creation_10k.log\n",  index = 18446744073709551615, buffer_marks
> >> = 0x7f14b592a240, fill_buffer = 0x0, fill_buffer_arg = 0x0}
> >>
> >> I'm pretty sure that the history of this mess was:
> >>
> >> 1.) the test was added first as enhanced
> >> 2.) automatic dump of api trace was added, but only tested against 'make 
> >> test', not 'make test-all'
> >>
> >> Thanks,
> >> Klement
> >>
> >> Quoting Klement Sekera (2017-11-11 22:12:52)
> >>> Hi Brian,
> >>>
> >>> it should. Though I just tried running it on latest master and got
> >>> a timeout in test_p2p_ethe

Re: [vpp-dev] TCP Options: tcp_header_t and tcp_options_t

[Florin Coras]

Hi Justin, 

The expectation until now has been that options are not parsed until hitting 
the tcp related nodes. If tcp_options_parse is enough, then make it public and 
use it.  That function just expects a tcp_options_t struct for outputting the 
results so no need for a tcp_connection_t. Now, if you need your special 
function to both read, match and update in place the options, then I recommend 
you write your own options parser. 

Hope this helps,
Florin

> On Nov 14, 2017, at 5:13 AM, Justin Iurman  wrote:
> 
> Hi Dave,
> 
> Thanks (again) for your reply.
> 
>> Brief commercial: hopefully you added your node to the ip4 unicast feature 
>> arc,
>> configured to grab pkts, pre-ip4/6-lookup.
> 
> Indeed, I added my node to the ip4-unicast feature arc.
> 
>> In feature-arc land, the following one-liner sets next0 so pkts will visit 
>> the
>> next enabled feature. The last node in the ip4-unicast feature arc is
>> ip4-lookup...
>> 
>> /* Next node in unicast feature arc */
>>vnet_get_config_data (em->config_main[table_index],
>>  &b0->current_config_index, &next0,
>>  /* # bytes of config data */ 0);
>> 
>> Check the ip protocol and ignore any non-TCP pkts:
>> 
>> ip40 = vlib_buffer_get_current (b0);
>> if (ip40->protocol != IP_PROTOCOL_TCP)
>>   goto trace0;
>> 
>> Then use ip4_next_header() to find the tcp layer, etc. etc.
> 
> Actually, I'm already able to access L3 and L4 structures. But, when I have 
> the following, for instance:
> 
> ip40 = vlib_buffer_get_current (b0);
> if (ip40->protocol == IP_PROTOCOL_TCP)
> {
>  tcp_header_t *tcp = ip4_next_header(ip40);
>  // where are options (tcp_options_t) ?
> }
> 
> How am I able to access TCP options for each packet ? I mean, I could 
> directly parse them by moving the data pointer but I've also seen a function 
> called tcp_options_parse (see my previous email) that already does this job. 
> How would you proceed to do this ? The expected behavior is to match some 
> options and strip them.
> 
> Thanks,
> 
> Justin
> ___
> 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 with DPDK external build

[Marco Varlese]

On Tue, 2017-11-14 at 12:45 +, Shachar Beiser wrote:
>  
> 
>  
> 
> 
> 
> 
> From: Marco Varlese [mailto:mvarl...@suse.de] 
> 
> Sent: Tuesday, November 14, 2017 1:29 PM
> 
> To: Shachar Beiser ; vpp-dev@lists.fd.io
> 
> Cc: Amir Zeidner ; Shahaf Shuler ;
> Eyal Lavee 
> 
> Subject: Re: [vpp-dev] VPP with DPDK external build
> 
> 
> 
>  
> 
> 
> It looks like you didn't build the dpdk plugin (dpdk_plugin.so) in VPP...
> 
> 
> 
>  
> 
> 
> 
> The first command you ran
> 
> 
> 
> >  root@kickseed:/home/shacharbe/vpp.dlopen# sudo
> > ./src/bin/vpp -c ${PWD}/src/vpp/conf/startup.conf
> 
>  
> is correct but the DPDK plugin is not loaded (I can't see it listed in the
> output you shared)
> 
> 
> 
> 
> 
> > load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
> > load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow per Packet)
> > load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> > load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
> > addressing for IPv6)
> > load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
> > load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
> > load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
> > load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid
> > Deployment on IPv4 Infrastructure (RFC5969))
> > load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory Interface
> > (experimetal))
> > load_one_plugin:184: Loaded plugin: nat_plugin.so (Network Address
> > Translation)
> > load_one_plugin:184: Loaded plugin: pppoe_plugin.so (PPPoE)
> 
>  
> 
> Hence you get the error about an "unrecognized option" while parsing the
> configuration file.
> 
> 
> 
> > vlib_call_all_config_functions: unknown input `dpdk  dev :03:00.0 { num-
> > rx-queues 2 } no-multi-seg socket-mem 2048,2048 '
> 
>  
> 
> 
> 
> 
> Can you check that you have the dpdk plugin (file: dpdk_plugin.so) in the
> folder you currently use as your plugin directory? As per your output below
> 
> 
> 
> 
> > vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
> 
> 
> 
> I believe it's /usr/lib/vpp_plugins
> 
>  
> 
>  
> 
> [S.B]
> 
> Yes it is in the /usr/lib/vpp_plugins , but I am using dpdk external and the
> library path is probably different ?!
Not, at all. As I told you in my previous email, I build VPP using DPDK-shared
mode too. Where the plugins are being "installed" does not depend on whether you
use shared or non-shared DPDK...
> root@kickseed:/home/shacharbe/vpp.dlopen# ls /usr/lib/vpp_plugins
> acl_plugin.so   flowprobe_plugin.so  ila_plugin.so   ixge_plugin.so 
> libsixrd_plugin.so  nat_plugin.so
>   dpdk_plugin.so  gtpu_plugin.so   ioam_plugin.so  lb_plugin.so   
> memif_plugin.so pppoe_plugin.so
>  
> 
> 
> 
> My plugins are in the directory:
> 
> /home/shacharbe/vpp.dlopen/src/plugins/.libs/dpdk_plugin.so
I am puzzled at how you got the plugins into the /usr/lib/vpp_plugins directory
if you still run VPP from within the folder where you build it.Did you manually
copy the plugins .so to the /usr/lib/vpp_plugins ? From your previous command,
you simply execute "make -j 32" and that does not do any "install of execs/libs
on the filesystem".
>  
> 
> Anyway setting in the startup.conf the plugin path resolves this issue.
Sure, adding the correct path helps but - somehow - in your previous execution
you were not "executing" either the right VPP (e.g. a vpp executable built
without DPDK support) or executing VPP with the DPDK plugin disabled (that is an
option you can specify in the startup.conf file) or - finally - pointing to a
folder without the dpdk plugin .so file otherwise the error couldn't be
explained...
>  
> 
> 
>  
> 
> 
> Cheers,
> 
> 
> Marco
> 
> 
>  
> 
> 
> On Tue, 2017-11-14 at 10:07 +, Shachar Beiser wrote:
> 
> > Hi ,
> >  
> >I have successfully build the DPDK by:
> > make T=x86_64-native-linuxapp-gcc install CPU_CFLAGS="-g
> > -fpic"
> >then I compiled successfully the vpp with the DPDK external by
> > following the procedure :
> > cd vpp/
> > sed -i '/vpp_uses_dpdk_mlx5_pmd/s/^# //g' build-data/platforms/vpp.mk
> > cd src/
> > autoreconf -fis
> > export CFLAGS="-g -DFORTIFY_SOURCE=2 -fstack-protector -fPIC
> > -march=sandybridge -O2 -I/home/shacharbe/dpdk.org/x86_64-native-linuxapp-
> > gcc/include -L/home/shacharbe/dpdk.org/x86_64-native-linuxapp-gcc/lib"
> > ./configure --disable-japi
> > make -j32
> >  
> > now I have an issue while I try to run the vpp with startup.conf .
> > 
> > What is the right command that I should use ?
> >   
> >  -Shachar Beiser
> >  
> > Different commands that  I have tried :
> >  
> > root@kickseed:/home/shacharbe/vpp.dlopen# sudo ./src/bin/vpp -c
> > ${PWD}/src/vpp/conf/startup.conf
> > vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
> > load_one_plugin:184: Loaded plug

Re: [vpp-dev] hi vpp-dev, need you help!

[Luke, Chris]

Likely you ran out of memory. A patch was merged last night that should help 
alleviate this by reducing the number of parallel builds.

The new C++ stuff is a hog and is triggering this for several people. If you 
don't intend to use it, then perhaps looking for this section in 
builds-data/platforms/vpp.mk will help too:

+# To disable the VPP object model build - and save about half the build time -
+# uncomment the following...
+# vpp_configure_args_vpp += --disable-vom

Chris.

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of wanghongbo
Sent: Tuesday, November 14, 2017 7:33 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] hi vpp-dev, need you help!

Hi vpp-dev:

  Excuse me. Could you give me a hand?  I have a problem when I build vpp. 
My environment is vmware workstation + centos7.4 . The capture as follows. Was 
this error caused by "make build-release".



[??: cid:image001.png@01D35D70.582DE740]

 I used this command "./build-root/vagrant/build.sh". The building 
didn't have error. Is it right?

[??: cid:image002.png@01D35D73.62DCDC20]


 Thank you very much!
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] TCP Options: tcp_header_t and tcp_options_t

[Justin Iurman]

Hi Dave,

Thanks (again) for your reply.

> Brief commercial: hopefully you added your node to the ip4 unicast feature 
> arc,
> configured to grab pkts, pre-ip4/6-lookup.

Indeed, I added my node to the ip4-unicast feature arc.

> In feature-arc land, the following one-liner sets next0 so pkts will visit the
> next enabled feature. The last node in the ip4-unicast feature arc is
> ip4-lookup...
> 
>  /* Next node in unicast feature arc */
> vnet_get_config_data (em->config_main[table_index],
>   &b0->current_config_index, &next0,
>   /* # bytes of config data */ 0);
> 
> Check the ip protocol and ignore any non-TCP pkts:
> 
>  ip40 = vlib_buffer_get_current (b0);
>  if (ip40->protocol != IP_PROTOCOL_TCP)
>goto trace0;
> 
> Then use ip4_next_header() to find the tcp layer, etc. etc.

Actually, I'm already able to access L3 and L4 structures. But, when I have the 
following, for instance:

ip40 = vlib_buffer_get_current (b0);
if (ip40->protocol == IP_PROTOCOL_TCP)
{
  tcp_header_t *tcp = ip4_next_header(ip40);
  // where are options (tcp_options_t) ?
}

How am I able to access TCP options for each packet ? I mean, I could directly 
parse them by moving the data pointer but I've also seen a function called 
tcp_options_parse (see my previous email) that already does this job. How would 
you proceed to do this ? The expected behavior is to match some options and 
strip them.

Thanks,

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

Re: [vpp-dev] VPP with DPDK external build

[Shachar Beiser]

From: Marco Varlese [mailto:mvarl...@suse.de]
Sent: Tuesday, November 14, 2017 1:29 PM
To: Shachar Beiser ; vpp-dev@lists.fd.io
Cc: Amir Zeidner ; Shahaf Shuler ; 
Eyal Lavee 
Subject: Re: [vpp-dev] VPP with DPDK external build

It looks like you didn't build the dpdk plugin (dpdk_plugin.so) in VPP...

The first command you ran
 
root@kickseed:/home/shacharbe/vpp.dlopen#
 sudo ./src/bin/vpp -c ${PWD}/src/vpp/conf/startup.conf

is correct but the DPDK plugin is not loaded (I can't see it listed in the 
output you shared)
load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow per Packet)
load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator 
addressing for IPv6)
load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid Deployment 
on IPv4 Infrastructure (RFC5969))
load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory Interface 
(experimetal))
load_one_plugin:184: Loaded plugin: nat_plugin.so (Network Address Translation)
load_one_plugin:184: Loaded plugin: pppoe_plugin.so (PPPoE)

Hence you get the error about an "unrecognized option" while parsing the 
configuration file.
vlib_call_all_config_functions: unknown input `dpdk  dev :03:00.0 { 
num-rx-queues 2 } no-multi-seg socket-mem 2048,2048 '

Can you check that you have the dpdk plugin (file: dpdk_plugin.so) in the 
folder you currently use as your plugin directory? As per your output below
vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
I believe it's /usr/lib/vpp_plugins


[S.B]
Yes it is in the /usr/lib/vpp_plugins , but I am using dpdk external and the 
library path is probably different ?!
root@kickseed:/home/shacharbe/vpp.dlopen# ls /usr/lib/vpp_plugins
acl_plugin.so   flowprobe_plugin.so  ila_plugin.so   ixge_plugin.so  
libsixrd_plugin.so  nat_plugin.so
  dpdk_plugin.so  gtpu_plugin.so   ioam_plugin.so  lb_plugin.so
memif_plugin.so pppoe_plugin.so

My plugins are in the directory:
/home/shacharbe/vpp.dlopen/src/plugins/.libs/dpdk_plugin.so

Anyway setting in the startup.conf the plugin path resolves this issue.


Cheers,
Marco

On Tue, 2017-11-14 at 10:07 +, Shachar Beiser wrote:
Hi ,

   I have successfully build the DPDK by:
make T=x86_64-native-linuxapp-gcc install CPU_CFLAGS="-g -fpic"
   then I compiled successfully the vpp with the DPDK external by following 
the procedure :
cd vpp/
sed -i '/vpp_uses_dpdk_mlx5_pmd/s/^# //g' build-data/platforms/vpp.mk
cd src/
autoreconf -fis
export CFLAGS="-g -DFORTIFY_SOURCE=2 -fstack-protector -fPIC -march=sandybridge 
-O2 -I/home/shacharbe/dpdk.org/x86_64-native-linuxapp-gcc/include 
-L/home/shacharbe/dpdk.org/x86_64-native-linuxapp-gcc/lib"
./configure --disable-japi
make -j32

now I have an issue while I try to run the vpp with startup.conf .
What is the right command that I should use ?

 -Shachar Beiser

Different commands that  I have tried :
 
root@kickseed:/home/shacharbe/vpp.dlopen#
 sudo ./src/bin/vpp -c ${PWD}/src/vpp/conf/startup.conf
vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow per Packet)
load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator 
addressing for IPv6)
load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid Deployment 
on IPv4 Infrastructure (RFC5969))
load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory Interface 
(experimetal))
load_one_plugin:184: Loaded plugin: nat_plugin.so (Network Address Translation)
load_one_plugin:184: Loaded plugin: pppoe_plugin.so (PPPoE)
vlib_call_all_config_functions: unknown input `dpdk  dev :03:00.0 { 
num-rx-queues 2 } no-multi-seg socket-mem 2048,2048 '
root@kickseed:/home/shacharbe/vpp.dlopen#
 sudo ./src/bin/vpp -c ${PWD}/src/vpp/conf/startup.conf plugin_path 
${PWD}/plugins/.libs/
vlib_plugin_early_init:356: plugin path 
/home/shacharbe/vpp.dlopen/plugins/.libs/
vlib_call_all_config_functions: unknown input `-c 
/home/shacharbe/vpp.dlopen/src/vpp/conf/startup.conf'
root@kickseed:/home/shacharbe/vpp.dlopen#

Re: [vpp-dev] TCP Options: tcp_header_t and tcp_options_t

[Dave Barach (dbarach)]

Dear Justin,

Brief commercial: hopefully you added your node to the ip4 unicast feature arc, 
configured to grab pkts, pre-ip4/6-lookup. 

In feature-arc land, the following one-liner sets next0 so pkts will visit the 
next enabled feature. The last node in the ip4-unicast feature arc is 
ip4-lookup...

  /* Next node in unicast feature arc */
  vnet_get_config_data (em->config_main[table_index],
&b0->current_config_index, &next0,
/* # bytes of config data */ 0);

Check the ip protocol and ignore any non-TCP pkts:

  ip40 = vlib_buffer_get_current (b0);
  if (ip40->protocol != IP_PROTOCOL_TCP)
goto trace0;

Then use ip4_next_header() to find the tcp layer, etc. etc.

HTH... Dave

-Original Message-
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Justin Iurman
Sent: Monday, November 13, 2017 5:30 PM
To: vpp-dev 
Subject: [vpp-dev] TCP Options: tcp_header_t and tcp_options_t

Guys,

My node is located right before ip4_lookup. What's the fastest/cleanest way to 
get options related to a TCP packet, having access to a tcp_header_t structure 
(which is not directly linked to its options) ? Actually, I'd like to modify or 
remove some options on the fly. 

Do I have to call tcp_options_parse function from src/vnet/tcp/tcp_input.c ? 
But I guess it would duplicate the job, since it is already called at one 
moment. 

Or should I get the TCP connection, which connects both tcp_header_t and 
tcp_options_t ? Or should I directly modify options "in" the packet, by moving 
the data pointer (a sort-of copy of what tcp_options_parse already does) ?

Thanks for your help !

Justin
___
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] hi vpp-dev, need you help!

[wanghongbo]

Hi vpp-dev:

  

  Excuse me. Could you give me a hand?  I have a problem when I build
vpp. My environment is vmware workstation + centos7.4 . The capture as
follows. Was this error caused by “make build-release”.

 

 

 

说明: cid:image001.png@01D35D70.582DE740

 

 I used this command “./build-root/vagrant/build.sh”. The building
didn’t have error. Is it right?

 

说明: cid:image002.png@01D35D73.62DCDC20

 

 

 Thank you very much!

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

[vpp-dev] vpp-dev, need you help!

[wanghongbo]

Hi vpp-dev:

  

  Excuse me. Could you give me a hand?  I have a problem when I build
vpp. My environment is vmware workstation + centos7.4 . The capture as
follows. Was this error caused by "make build-release".

 

 

 



 

 I used this command "./build-root/vagrant/build.sh". The building
didn't have error. Is it right?

 



 

 

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

Re: [vpp-dev] make test-all

[Brian Brooks]

It does not complete within 20 minutes on other machines.

> I don't think we should do scale tests as part of verification tests.

Agree


-Original Message-
From: Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco) 
[mailto:ksek...@cisco.com]
Sent: Tuesday, November 14, 2017 2:47 AM
To: Ole Troan 
Cc: Dave Barach (dbarach) ; John Lo (loj) ; 
Pavel Kotucek -X (pkotucek - PANTHEON TECHNOLOGIES at Cisco) 
; vpp-dev@lists.fd.io; Brian Brooks 
Subject: Re: [vpp-dev] make test-all

It is ...

it takes ~10 seconds to create 1000 subifs on a beefy UCS and the case tries to 
create 10, so that would indicate a runtime of ~16minutes...

Quoting Ole Troan (2017-11-14 03:53:28)
> Klement,
>
> > I don't know what to tell you ... I was never a fan of getting the
> > API trace post test run and putting it into test log (which is the
> > cause of 25MB allocation in this case - it's the CLI output) - from
> > my POV this is duplicate information as every API call is already
> > logged in-place when it's executed... BUT I didn't saw any harm in
> > doing so (besides clutter) and since the "create bazillion
> > subinterfaces" test went in without me being part of review process, I 
> > wasn't aware of it...
>
> If this is in test_p2p_ethernet, let me take that out.
> I don't think we should do scale tests as part of verification tests.
> I do not like the path we're on with regards to test run time.
>
> Cheers,
> Ole
>
> > Quoting Dave Barach (dbarach) (2017-11-13 13:33:41)
> >> Try increasing the size of the shared-memory API segment. An allocation of 
> >> 25mb is failing. You might ask yourself how sane it is to generate that 
> >> much output.
> >>
> >> Thanks… Dave
> >>
> >> -Original Message-
> >> From: vpp-dev-boun...@lists.fd.io
> >> [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Klement Sekera -X
> >> (ksekera - PANTHEON TECHNOLOGIES at Cisco)
> >> Sent: Monday, November 13, 2017 5:27 AM
> >> To: John Lo (loj) ; Pavel Kotucek -X (pkotucek -
> >> PANTHEON TECHNOLOGIES at Cisco) ;
> >> vpp-dev@lists.fd.io; Brian Brooks 
> >> Subject: Re: [vpp-dev] make test-all
> >>
> >> So it seems that vpp coredumps while dumping the API trace after
> >> creating all the interfaces...
> >>
> >> (gdb) bt
> >> #0  0x7f14f4b1e428 in __GI_raise (sig=sig@entry=6) at
> >> ../sysdeps/unix/sysv/linux/raise.c:54
> >> #1  0x7f14f4b2002a in __GI_abort () at abort.c:89
> >> #2  0x00405d83 in os_panic () at
> >> /home/ksekera/vpp/build-data/../src/vpp/vnet/main.c:268
> >> #3  0x7f14f5fe5f86 in clib_mem_alloc_aligned_at_offset 
> >> (os_out_of_memory_on_failure=1, align_offset=0, align=1, size=25282098)
> >>at /home/ksekera/vpp/build-data/../src/vppinfra/mem.h:105
> >> #4  clib_mem_alloc (size=25282098) at
> >> /home/ksekera/vpp/build-data/../src/vppinfra/mem.h:114
> >> #5  vl_msg_api_alloc_internal (may_return_null=0, pool=, 
> >> nbytes=25282098)
> >>at
> >> /home/ksekera/vpp/build-data/../src/vlibmemory/memory_shared.c:176
> >> #6  vl_msg_api_alloc (nbytes=nbytes@entry=25282082) at
> >> /home/ksekera/vpp/build-data/../src/vlibmemory/memory_shared.c:207
> >> #7  0x00411392 in vl_api_cli_inband_t_handler
> >> (mp=0x300e2a0c) at
> >> /home/ksekera/vpp/build-data/../src/vpp/api/api.c:223
> >> #8  0x7f14f5fdfa23 in vl_msg_api_handler_with_vm_node 
> >> (am=am@entry=0x7f14f620d460 , the_msg=the_msg@entry=0x300e2a0c,
> >>vm=vm@entry=0x7f14f5fd6260 ,
> >> node=node@entry=0x7f14b410e000) at
> >> /home/ksekera/vpp/build-data/../src/vlibapi/api_shared.c:508
> >> #9  0x7f14f5fef35f in memclnt_process (vm=0x7f14f5fd6260 
> >> , node=0x7f14b410e000, f=)
> >>at
> >> /home/ksekera/vpp/build-data/../src/vlibmemory/memory_vlib.c:970
> >>
> >> (gdb) p input
> >> $5 = {buffer = 0x7f14b56f6558 "dump
> >> /tmp/vpp-unittest-P2PEthernetAPI-qRwMY6/vpp_api_trace.test_p2p_subi
> >> f_creation_10k.log\n",  index = 18446744073709551615, buffer_marks
> >> = 0x7f14b592a240, fill_buffer = 0x0, fill_buffer_arg = 0x0}
> >>
> >> I'm pretty sure that the history of this mess was:
> >>
> >> 1.) the test was added first as enhanced
> >> 2.) automatic dump of api trace was added, but only tested against 'make 
> >> test', not 'make test-all'
> >>
> >> Thanks,
> >> Klement
> >>
> >> Quoting Klement Sekera (2017-11-11 22:12:52)
> >>> Hi Brian,
> >>>
> >>> it should. Though I just tried running it on latest master and got
> >>> a timeout in test_p2p_ethernet, which shouldn't happen. I see the
> >>> test was trying to create tens of thousands of interfaces... maybe
> >>> something is slower than usual?
> >>>
> >>> Thanks,
> >>> Klement
> >>>
> >>> Quoting Brian Brooks (2017-11-11 01:11:47)
>    Should “make test-all” pass?
> 
> 
> 
>    Thanks,
> 
>    Brian
> 
> 
> 
>    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 send

Re: [vpp-dev] VPP with DPDK external build

[Marco Varlese]

It looks like you didn't build the dpdk plugin (dpdk_plugin.so) in VPP...
The first command you ran
>  root@kickseed:/home/shacharbe/vpp.dlopen# sudo
> ./src/bin/vpp -c ${PWD}/src/vpp/conf/startup.conf

is correct but the DPDK plugin is not loaded (I can't see it listed in the
output you shared) 
> load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
> load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow per Packet)
> load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
> addressing for IPv6)
> load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
> load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
> load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
> load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid Deployment
> on IPv4 Infrastructure (RFC5969))
> load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory Interface
> (experimetal))
> load_one_plugin:184: Loaded plugin: nat_plugin.so (Network Address
> Translation)
> load_one_plugin:184: Loaded plugin: pppoe_plugin.so (PPPoE)

Hence you get the error about an "unrecognized option" while parsing the
configuration file.
> vlib_call_all_config_functions: unknown input `dpdk  dev :03:00.0 { num-
> rx-queues 2 } no-multi-seg socket-mem 2048,2048 '

Can you check that you have the dpdk plugin (file: dpdk_plugin.so) in the folder
you currently use as your plugin directory? As per your output below 
> vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
I believe it's /usr/lib/vpp_plugins

Cheers,Marco
On Tue, 2017-11-14 at 10:07 +, Shachar Beiser wrote:
> Hi ,
>  
>I have successfully build the DPDK by:
> make T=x86_64-native-linuxapp-gcc install CPU_CFLAGS="-g
> -fpic"
>then I compiled successfully the vpp with the DPDK external by
> following the procedure :
> cd vpp/
> sed -i '/vpp_uses_dpdk_mlx5_pmd/s/^# //g' build-data/platforms/vpp.mk
> cd src/
> autoreconf -fis
> export CFLAGS="-g -DFORTIFY_SOURCE=2 -fstack-protector -fPIC
> -march=sandybridge -O2 -I/home/shacharbe/dpdk.org/x86_64-native-linuxapp-
> gcc/include -L/home/shacharbe/dpdk.org/x86_64-native-linuxapp-gcc/lib"
> ./configure --disable-japi
> make -j32
>  
> now I have an issue while I try to run the vpp with startup.conf .
> 
> What is the right command that I should use ?
>   
>  -Shachar Beiser
>  
> Different commands that  I have tried :
>  root@kickseed:/home/shacharbe/vpp.dlopen#
> sudo ./src/bin/vpp -c ${PWD}/src/vpp/conf/startup.conf
> vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
> load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
> load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow per Packet)
> load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
> addressing for IPv6)
> load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
> load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
> load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
> load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid Deployment
> on IPv4 Infrastructure (RFC5969))
> load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory Interface
> (experimetal))
> load_one_plugin:184: Loaded plugin: nat_plugin.so (Network Address
> Translation)
> load_one_plugin:184: Loaded plugin: pppoe_plugin.so (PPPoE)
> vlib_call_all_config_functions: unknown input `dpdk  dev :03:00.0 { num-
> rx-queues 2 } no-multi-seg socket-mem 2048,2048 '
> root@kickseed:/home/shacharbe/vpp.dlopen# sudo ./src/bin/vpp -c
> ${PWD}/src/vpp/conf/startup.conf plugin_path ${PWD}/plugins/.libs/
> vlib_plugin_early_init:356: plugin path
> /home/shacharbe/vpp.dlopen/plugins/.libs/
> vlib_call_all_config_functions: unknown input `-c
> /home/shacharbe/vpp.dlopen/src/vpp/conf/startup.conf'
> root@kickseed:/home/shacharbe/vpp.dlopen# sudo ./src/bin/vpp unix -c
> ${PWD}/src/vpp/conf/startup.conf
> vlib_plugin_config: unknown input '/home/shacharbe/vpp.dlopen/src...'
> root@kickseed:/home/shacharbe/vpp.dlopen# sudo ./src/bin/vpp
> vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
> load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
> load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow per Packet)
> load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
> addressing for IPv6)
> load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
> load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
> load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
> load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid Deployment
>

Re: [vpp-dev] ACL

[Andrew Yourtchenko]

Cool!

Sure, you can use vat in that case as well.

--a

> On 13 Nov 2017, at 22:08, Yuliang Li  wrote:
> 
> It works! Thanks.
> 
> Another question: if I want to use ACL plugin in non-debug build (say, 
> build-release), is can I use vat? Or I need to use the python code?
> 
>> On Mon, Nov 13, 2017 at 12:06 PM, Andrew Yourtchenko  
>> wrote:
>> “Make build” in the VPP directory will get you a debug build. The $1 and 
>> such is just standard shell scripting, in case I need to pass some 
>> parameters to vat. I don’t think I had ever needed them...
>> 
>> --a
>> 
>>> On 13 Nov 2017, at 17:40, Yuliang Li  wrote:
>>> 
>>> Maybe this is a stupid question.. Does vat have to work with debug builds? 
>>> And how to do the debug builds? What are the $1~$5 in your script?
>>> 
>>> Thanks,
>>> Yuliang
>>> 
 On Mon, Nov 13, 2017 at 3:03 AM, Andrew Yourtchenko  
 wrote:
 When just running vat from within the source tree, it needs to know the 
 path for the plugins, for debug builds I usually have the following small 
 shell script which takes care of this without requiring me thinking every 
 time (of course needs to be launched from the vpp top directory since it 
 has relative paths:
 
 $ cat ~/bin/run-vat
 #!/bin/sh
 sudo ./build-root/install-vpp_debug-native/vpp/bin/vpp_api_test 
 plugin_path 
 ./build-root/install-vpp_debug-native/vpp/lib64/vpp_api_test_plugins/ $1 
 $2 $3 $4 $5
 
 Not sure about the error with build-vat, I will let other folks comment on 
 it if someone knows...
 
 —a
 
 > On 13 Nov 2017, at 03:14, Yuliang Li  wrote:
 >
 > Thanks for the quick reply.
 >
 > I still fail to use the vat to configure ACL. After make build-release, 
 > I use sudo build-root/build-vpp-native/vpp/vpp_api_test, but it tell me:
 > 'acl_plugin_get_version': function not found
 > Other ACL commands have the same problem.
 >
 > I also tried make build-vat, but it gives the following error:
 >  Arch for platform 'vpp' is native 
 >  Finding source for vpp-api-test 
 >  Package vpp-api-test not found with path /home/bright/tools/vpp 
 > Makefile:780: recipe for target 'vpp-api-test-find-source' failed
 > make[1]: *** [vpp-api-test-find-source] Error 1
 > make[1]: Leaving directory '/home/bright/tools/vpp/build-root'
 > Makefile:460: recipe for target 'build-vat' failed
 > make: *** [build-vat] Error 2
 >
 > Am I doing something wrong here?
 >
 > Thanks,
 > Yuliang
 >
 > On Sun, Nov 12, 2017 at 5:15 PM, Andrew 👽 Yourtchenko 
 >  wrote:
 > Hi Yuliang,
 >
 > You can look at the test/test_acl_plugin_*.py files for the examples
 > of interactions with plugin from python code.
 >
 > Alternatively, you can use VPP API test tool (vat) which is built
 > together with VPP and then issue the API calls directly from there.
 >
 > Shout if you have any questions, will be happy to answer! :)
 >
 > --a
 >
 > On 11/12/17, Yuliang Li  wrote:
 > > Hi,
 > >
 > > I want to use the ACL plugin 
 > > https://wiki.fd.io/view/VPP/SecurityGroups. It
 > > seems it can only be configured via API. I only used vppctl before. Can
 > > anyone please tell how to use the API to configure? Or is there other 
 > > ways
 > > to configre?
 > >
 > > Thanks,
 > > --
 > > Yuliang Li
 > > PhD student
 > > Department of Computer Science
 > > Yale University
 > >
 >
 >
 >
 > --
 > Yuliang Li
 > PhD student
 > Department of Computer Science
 > Yale University
 
>>> 
>>> 
>>> 
>>> -- 
>>> Yuliang Li
>>> PhD student
>>> Department of Computer Science
>>> Yale University
> 
> 
> 
> -- 
> Yuliang Li
> PhD student
> Department of Computer Science
> Yale University
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] VPP with DPDK external build

[Shachar Beiser]

Hi ,

   I have successfully build the DPDK by:
make T=x86_64-native-linuxapp-gcc install CPU_CFLAGS="-g -fpic"
   then I compiled successfully the vpp with the DPDK external by following 
the procedure :
cd vpp/
sed -i '/vpp_uses_dpdk_mlx5_pmd/s/^# //g' build-data/platforms/vpp.mk
cd src/
autoreconf -fis
export CFLAGS="-g -DFORTIFY_SOURCE=2 -fstack-protector -fPIC -march=sandybridge 
-O2 -I/home/shacharbe/dpdk.org/x86_64-native-linuxapp-gcc/include 
-L/home/shacharbe/dpdk.org/x86_64-native-linuxapp-gcc/lib"
./configure --disable-japi
make -j32

now I have an issue while I try to run the vpp with startup.conf .
What is the right command that I should use ?

 -Shachar Beiser

Different commands that  I have tried :
 root@kickseed:/home/shacharbe/vpp.dlopen# sudo 
./src/bin/vpp -c ${PWD}/src/vpp/conf/startup.conf
vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow per Packet)
load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator 
addressing for IPv6)
load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid Deployment 
on IPv4 Infrastructure (RFC5969))
load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory Interface 
(experimetal))
load_one_plugin:184: Loaded plugin: nat_plugin.so (Network Address Translation)
load_one_plugin:184: Loaded plugin: pppoe_plugin.so (PPPoE)
vlib_call_all_config_functions: unknown input `dpdk  dev :03:00.0 { 
num-rx-queues 2 } no-multi-seg socket-mem 2048,2048 '
root@kickseed:/home/shacharbe/vpp.dlopen# sudo ./src/bin/vpp -c 
${PWD}/src/vpp/conf/startup.conf plugin_path ${PWD}/plugins/.libs/
vlib_plugin_early_init:356: plugin path 
/home/shacharbe/vpp.dlopen/plugins/.libs/
vlib_call_all_config_functions: unknown input `-c 
/home/shacharbe/vpp.dlopen/src/vpp/conf/startup.conf'
root@kickseed:/home/shacharbe/vpp.dlopen# sudo ./src/bin/vpp unix -c 
${PWD}/src/vpp/conf/startup.conf
vlib_plugin_config: unknown input '/home/shacharbe/vpp.dlopen/src...'
root@kickseed:/home/shacharbe/vpp.dlopen# sudo ./src/bin/vpp
vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow per Packet)
load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator 
addressing for IPv6)
load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid Deployment 
on IPv4 Infrastructure (RFC5969))
load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory Interface 
(experimetal))
load_one_plugin:184: Loaded plugin: nat_plugin.so (Network Address Translation)
load_one_plugin:184: Loaded plugin: pppoe_plugin.so (PPPoE)



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

Re: [vpp-dev] make test-all

[Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)]

It is ...

it takes ~10 seconds to create 1000 subifs on a beefy UCS and the case
tries to create 10, so that would indicate a runtime of
~16minutes...

Quoting Ole Troan (2017-11-14 03:53:28)
> Klement,
> 
> > I don't know what to tell you ... I was never a fan of getting the API
> > trace post test run and putting it into test log (which is the cause
> > of 25MB allocation in this case - it's the CLI output) - from my POV
> > this is duplicate information as every API call is already logged
> > in-place when it's executed... BUT I didn't saw any harm in doing so
> > (besides clutter) and since the "create bazillion subinterfaces" test
> > went in without me being part of review process, I wasn't aware of it...
> 
> If this is in test_p2p_ethernet, let me take that out.
> I don't think we should do scale tests as part of verification tests.
> I do not like the path we're on with regards to test run time.
> 
> Cheers,
> Ole
> 
> > Quoting Dave Barach (dbarach) (2017-11-13 13:33:41)
> >> Try increasing the size of the shared-memory API segment. An allocation of 
> >> 25mb is failing. You might ask yourself how sane it is to generate that 
> >> much output.
> >> 
> >> Thanks… Dave
> >> 
> >> -Original Message-
> >> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
> >> Behalf Of Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)
> >> Sent: Monday, November 13, 2017 5:27 AM
> >> To: John Lo (loj) ; Pavel Kotucek -X (pkotucek - PANTHEON 
> >> TECHNOLOGIES at Cisco) ; vpp-dev@lists.fd.io; Brian 
> >> Brooks 
> >> Subject: Re: [vpp-dev] make test-all
> >> 
> >> So it seems that vpp coredumps while dumping the API trace after
> >> creating all the interfaces...
> >> 
> >> (gdb) bt
> >> #0  0x7f14f4b1e428 in __GI_raise (sig=sig@entry=6) at 
> >> ../sysdeps/unix/sysv/linux/raise.c:54
> >> #1  0x7f14f4b2002a in __GI_abort () at abort.c:89
> >> #2  0x00405d83 in os_panic () at 
> >> /home/ksekera/vpp/build-data/../src/vpp/vnet/main.c:268
> >> #3  0x7f14f5fe5f86 in clib_mem_alloc_aligned_at_offset 
> >> (os_out_of_memory_on_failure=1, align_offset=0, align=1, size=25282098)
> >>at /home/ksekera/vpp/build-data/../src/vppinfra/mem.h:105
> >> #4  clib_mem_alloc (size=25282098) at 
> >> /home/ksekera/vpp/build-data/../src/vppinfra/mem.h:114
> >> #5  vl_msg_api_alloc_internal (may_return_null=0, pool=, 
> >> nbytes=25282098)
> >>at /home/ksekera/vpp/build-data/../src/vlibmemory/memory_shared.c:176
> >> #6  vl_msg_api_alloc (nbytes=nbytes@entry=25282082) at 
> >> /home/ksekera/vpp/build-data/../src/vlibmemory/memory_shared.c:207
> >> #7  0x00411392 in vl_api_cli_inband_t_handler (mp=0x300e2a0c) at 
> >> /home/ksekera/vpp/build-data/../src/vpp/api/api.c:223
> >> #8  0x7f14f5fdfa23 in vl_msg_api_handler_with_vm_node 
> >> (am=am@entry=0x7f14f620d460 , the_msg=the_msg@entry=0x300e2a0c,
> >>vm=vm@entry=0x7f14f5fd6260 , 
> >> node=node@entry=0x7f14b410e000) at 
> >> /home/ksekera/vpp/build-data/../src/vlibapi/api_shared.c:508
> >> #9  0x7f14f5fef35f in memclnt_process (vm=0x7f14f5fd6260 
> >> , node=0x7f14b410e000, f=)
> >>at /home/ksekera/vpp/build-data/../src/vlibmemory/memory_vlib.c:970
> >> 
> >> (gdb) p input
> >> $5 = {buffer = 0x7f14b56f6558 "dump 
> >> /tmp/vpp-unittest-P2PEthernetAPI-qRwMY6/vpp_api_trace.test_p2p_subif_creation_10k.log\n",
> >>  index = 18446744073709551615, buffer_marks = 0x7f14b592a240, fill_buffer 
> >> = 0x0, fill_buffer_arg = 0x0}
> >> 
> >> I'm pretty sure that the history of this mess was:
> >> 
> >> 1.) the test was added first as enhanced
> >> 2.) automatic dump of api trace was added, but only tested against 'make 
> >> test', not 'make test-all'
> >> 
> >> Thanks,
> >> Klement
> >> 
> >> Quoting Klement Sekera (2017-11-11 22:12:52)
> >>> Hi Brian,
> >>> 
> >>> it should. Though I just tried running it on latest master and got a
> >>> timeout in test_p2p_ethernet, which shouldn't happen. I see the test was
> >>> trying to create tens of thousands of interfaces... maybe something is
> >>> slower than usual?
> >>> 
> >>> Thanks,
> >>> Klement
> >>> 
> >>> Quoting Brian Brooks (2017-11-11 01:11:47)
>    Should “make test-all” pass?
>  
>  
>  
>    Thanks,
>  
>    Brian
>  
>  
>  
>    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
> >> ___
> >> vpp-dev mailing list
> >> vpp-dev@lists.fd.io
> >> https://lists.fd.io/mailman/listinfo/vpp-dev
>