Re: [vpp-dev] PPPoE plugin documentation/support

2018-10-24 Thread alp . arslan
Its working fine with VPP 17.10. I can see that a pppoe fib is created as
soon as the 1st PADI request arrives, which sets up the reverse path.
However, in VPP 18.07 & 18.10 there is no fib entry created and the PADO
packets are being dropped. 

The slides don't show a trace for the PADO replies. 

-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Ni,
Hongjun
Sent: Wednesday, October 24, 2018 1:38 PM
To: alp.ars...@xflowresearch.com; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] PPPoE plugin documentation/support

Hi Alp Arslan,

Please see below slides for more details. There is some packet trace for
your reference.

https://schd.ws/hosted_files/onsna18/cf/Accelerated%20Open%20Source%20vBRAS%
20Solution%20Based%20on%20OpenBRAS%20and%20VPP%26DPDK.PPTX

Thanks,
Hongjun

-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of
alp.ars...@xflowresearch.com
Sent: Wednesday, October 24, 2018 2:49 PM
To: Ni, Hongjun ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] PPPoE plugin documentation/support

Dell - Internal Use - Confidential  

Dear Hongjun, 

I was able to correctly set up the cp interface, my mistake as I was giving
the wrong interface index. 
Now the PADI packets are passed to cp interface. 

I started a pppoe-server on the Linux side (tap0) interface, but VPP is
dropping the PADO packets. 
Adding a trace on the virtio-input shows this: 

00:04:07:498195: virtio-input
  virtio: hw_if_index 2 next-index 4 vring 0 len 71
hdr: flags 0x00 gso_type 0x00 hdr_len 0 gso_size 0 csum_start 0
csum_offset 0 num_buffers 1
00:04:07:498204: ethernet-input
  PPPOE_DISCOVERY: f6:a0:85:84:98:e6 -> 3c:fd:fe:25:e6:20
00:04:07:498209: error-drop
  ethernet-input: l3 mac mismatch

The destination MAC address belongs to the pppoe-client, that's connected to
the 10G interface. However, VPP doesn't seem to know where to forward the
PADO replies. 
Also there are no entries in the pppoe fib for this client. Can you please
help me with this one? Please let me know if you need any more information. 

Regards,
Alp Arslan


-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Ni,
Hongjun
Sent: Tuesday, October 23, 2018 1:07 PM
To: alp.ars...@xflowresearch.com; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] PPPoE plugin documentation/support

Hi Alp Arslan,

To make tap_cli work, you need to revert the code as per this patch:
https://gerrit.fd.io/r/#/c/9467/ 

Thanks,
Hongjun

-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of
alp.ars...@xflowresearch.com
Sent: Tuesday, October 23, 2018 4:01 PM
To: Ni, Hongjun ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] PPPoE plugin documentation/support

Dell - Internal Use - Confidential  

Dear Hongjun, 

Thanks for the reply. 

I am using the VPP version 18.07. If the tap_cli is still present, can you
please point me towards what could be the problem with the existing plugin. 
I would like to see this one working a little bit, before starting to look
into tapv2.

Regards,
Alp Arslan

-Original Message-
From: Ni, Hongjun [mailto:hongjun...@intel.com]
Sent: Tuesday, October 23, 2018 12:51 PM
To: alp.ars...@xflowresearch.com; vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] PPPoE plugin documentation/support

Hi Alp Arslan,

Since tap_cli code is going to be deprecated in favour of tapv2.
I suggest you leverage tapv2, and also need some rework for PPPoE plugin.

Thanks,
Hongjun

-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of
alp.ars...@xflowresearch.com
Sent: Tuesday, October 23, 2018 3:08 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] PPPoE plugin documentation/support

Dear All, 

I am trying to evaluate the support of pppoe in vpp. However, I am facing
some issues, here is my startup conf file. 

unix {
  nodaemon
  log /var/log/vpp/vpp.log
  full-coredump
  cli-listen /run/vpp/cli.sock
  gid vpp
}
api-trace {
  on
}
api-segment {
  gid vpp
}
socksvr {
  default
}
cpu {
main-core 1
corelist-workers 2,4,3,5
}
dpdk {
dev :05:00.1
uio-driver vfio-pci
socket-mem 2048,2048
}
plugins {
plugin default { enable}
}
tuntap {
  enable
  ethernet
  name newtap
}

After that I run the following commands: 

vpp# set interface state TenGigabitEthernet5/0/1 up vpp# set interface state
local0 up

Now at this point if I try to connect from the pppoe client, I can see three
PADI request reaching VPP, and VPP trying to forward them at local0
interface. 
To forward this traffic to the tap port instead, I use this command. 

vpp# create pppoe cp cp-if-index 2

The help and the documentation for this command show this "create pppoe cp
if-name  [del]", which doesn't work.
Now at this moment, I was expecting the VPP to forward the PADI request to
tuntap-0 interface, but I don't see anything in the VPP counters, nor by
using tcpdump on interface 

[vpp-dev] TRex: unknown ip protocol

2018-10-24 Thread Ray Kinsella

Hi folks,

Testing with TRex and getting "unknown ip protocol" error in VPP.
Presume I am doing something blinding obvious wrong.

Any clues?

Ray K

$ FD.io VPP setup

set int ip address TenGigabitEthernet83/0/0 10.0.0.1/24
set int ip address TenGigabitEthernet83/0/1 11.0.0.1/24
set int state TenGigabitEthernet83/0/0 up
set int state TenGigabitEthernet83/0/1 up
set int mtu 9200 TenGigabitEthernet83/0/0
set int mtu 9200 TenGigabitEthernet83/0/1

$ cat traffic_config.yaml
 - duration: 10
   generator:
distribution: "seq"
clients_start: "10.0.0.2"
clients_end: "10.0.0.254"
servers_start: "11.0.0.1"
servers_end: "11.0.0.254"
   cap_info :
 - name: cap2/udp_10_pkts.pcap
   cps   : 1000.0
   ipg   : 1
   rtt   : 1
   w : 1
   limit : 200

$ cat /etc/trex_cfg.yaml
### Config file generated by dpdk_setup_ports.py ###

- port_limit: 2
  version: 2
  interfaces: ['04:00.0', '04:00.1']
  port_info:
   - ip: 10.0.0.2
 default_gw: 10.0.0.1
   - ip: 11.0.0.2
 default_gw: 11.0.0.1

  platform:
  master_thread_id: 0
  latency_thread_id: 18
  dual_if:
- socket: 0
  threads: 
[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53]

ro
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10955): https://lists.fd.io/g/vpp-dev/message/10955
Mute This Topic: https://lists.fd.io/mt/27617130/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] [tsc] VPP 18.10 is out!!!

2018-10-24 Thread Jerome Tollet via Lists.Fd.Io
Congratulations!

Le 24/10/2018 00:47, « t...@lists.fd.io au nom de Marco Varlese » 
 a écrit :

Dear all,

I am very happy to announce that release 18.10 is available.

Release artificats can be found on both Nexus and Packagecloud.

Thanks to all contributors for yet another great release!


Cheers,
-- 
Marco V

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10956): https://lists.fd.io/g/vpp-dev/message/10956
Mute This Topic: https://lists.fd.io/mt/27617131/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] Memory Performance issue #vpp

2018-10-24 Thread Dave Barach via Lists.Fd.Io
“show memory” looks at every object in the heap, with packet processing 
disabled for the duration.

From: vpp-dev@lists.fd.io  On Behalf Of 
david.leitch@gmail.com
Sent: Wednesday, October 24, 2018 4:58 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Memory Performance issue #vpp

hi Matus

I know it will take some time when add new deterministic mapping.
But why "show memory" command has drop rate
Or why adding new deterministic mapping cause drop rate

Thanks !
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10954): https://lists.fd.io/g/vpp-dev/message/10954
Mute This Topic: https://lists.fd.io/mt/27615950/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[vpp-dev] Regarding VLIB_REGISTER_NODE

2018-10-24 Thread Prashant Upadhyaya
Hi,

I have a registered node like the following --

VLIB_REGISTER_NODE (MyNode) = {
.name = "MyNode",
.
.
.n_next_nodes =N,
.next_nodes = {
[firstone] = "error-drop",
[secondone] = "ip4-lookup",
[thirdone] = "ip6-lookup",
[fourthone] = "may-or-may-not-be-loaded-node",
.
.

Now I want to be able to run the system whether the fourth one above
is loaded or not as a .so
The business logic in my code takes care that I never use the fourth
one in case it is not loaded. I have a private configuration which
tells me whether the fourth one is present in deployment or not.

But the VLIB_REGISTER_NODE requires the wiring at compile time like the above.
And the system will not startup if the fourth one is not actually
present in deployment

So I want to avoid mentioning the fourth one in the VLIB_REGISTER_NODE
of MyNode as one of the next_nodes.
And then how to add it as one of the next_nodes from runtime for
MyNode when my private configuration tells me that the fourthone
indeed is existing in the deployment ? I am looking for some API to
wink in the fourth one at runtime into .next_nodes of MyNode.

Regards
-Prashant
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10950): https://lists.fd.io/g/vpp-dev/message/10950
Mute This Topic: https://lists.fd.io/mt/27616631/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] Regarding VLIB_REGISTER_NODE

2018-10-24 Thread Dave Barach via Lists.Fd.Io
Use vlib_node_add_next(...) to create the graph arc at your convenience. 
Memorize the arc index when you create it, so you can set e.g. next0 to the 
correct value in MyNode.

HTH... Dave  

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Prashant Upadhyaya
Sent: Wednesday, October 24, 2018 2:15 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Regarding VLIB_REGISTER_NODE

Hi,

I have a registered node like the following --

VLIB_REGISTER_NODE (MyNode) = {
.name = "MyNode",
.
.
.n_next_nodes =N,
.next_nodes = {
[firstone] = "error-drop",
[secondone] = "ip4-lookup",
[thirdone] = "ip6-lookup",
[fourthone] = "may-or-may-not-be-loaded-node",
.
.

Now I want to be able to run the system whether the fourth one above is loaded 
or not as a .so The business logic in my code takes care that I never use the 
fourth one in case it is not loaded. I have a private configuration which tells 
me whether the fourth one is present in deployment or not.

But the VLIB_REGISTER_NODE requires the wiring at compile time like the above.
And the system will not startup if the fourth one is not actually present in 
deployment

So I want to avoid mentioning the fourth one in the VLIB_REGISTER_NODE of 
MyNode as one of the next_nodes.
And then how to add it as one of the next_nodes from runtime for MyNode when my 
private configuration tells me that the fourthone indeed is existing in the 
deployment ? I am looking for some API to wink in the fourth one at runtime 
into .next_nodes of MyNode.

Regards
-Prashant
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10953): https://lists.fd.io/g/vpp-dev/message/10953
Mute This Topic: https://lists.fd.io/mt/27616631/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] Memory Performance issue #vpp

2018-10-24 Thread david . leitch . vpp
[Edited Message Follows]

Do you mean it is impossible to have packet processing and memory operation at 
the same time,
for example doing vec_validate or vec_free when NAT plugin is working and 
create new session.

I have drop rate when vec_free or vec_vlidate for memory size greater than 3GB. 

What are your suggestions for such problems?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10959): https://lists.fd.io/g/vpp-dev/message/10959
Mute This Topic: https://lists.fd.io/mt/27615950/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] running VPP non-root broken

2018-10-24 Thread Damjan Marion via Lists.Fd.Io
no

-- 
Damjan

> On 24 Oct 2018, at 16:17, Marco Varlese  wrote:
> 
> Hi Damjan,
> 
> On Wed, 2018-10-24 at 16:14 +0200, Damjan Marion via Lists.Fd.Io wrote:
>> 
>> We merged patch which should fix things with 1G hugepages but I was not able 
>> to test it on arm, so please try...
> 
> Is this something which should go also on stable/1810 for a potential future 
> dot release?
> If so could you please cherry pick it to that branch?
> 
> 
>> 
>> -- 
>> Damjan
> 
> Cheers,
> Marco
> 
>> 
>>> On 24 Oct 2018, at 05:28, Sirshak Das >> > wrote:
>>> 2M works but 1G still fails.
>>>  
>>> I toned down the dpdk resource allocation to default:
>>> dpdk
>>> {
>>>   dev 0004:01:00.1
>>>   dev 0004:01:00.2
>>>   no-multi-seg
>>>   log-level debug
>>>   dev default
>>>   {
>>> num-rx-queues 1
>>> # num-tx-queues 4
>>> num-rx-desc 2048
>>> num-tx-desc 2048
>>>   }
>>>   # num-mbufs 128000
>>>   # socket-mem 2048,2048
>>>   no-tx-checksum-offload
>>>  
>>> But here is the problem (for 16G of Hugepage memory):
>>> With:
>>> 2MB (nr_hugepages: 8192)
>>> GRUB_CMDLINE_LINUX="default_hugepagesz=2M hugepagesz=1G hugepages=16 
>>> hugepagesz=2M hugepages=8192 iommu.passthrough=1 isolcpus=16-45 
>>> nohz_full=16-45 rcu_nocbs=16-45"
>>> vs 1GB (nr_hugepages: 16)
>>> GRUB_CMDLINE_LINUX="default_hugepagesz=1G hugepagesz=1G hugepages=16 
>>> hugepagesz=2M hugepages=8192 iommu.passthrough=1 isolcpus=16-45 
>>> nohz_full=16-45 rcu_nocbs=16-45"
>>>  
>>> I am getting a performance improvement of 49% when I use 1G hugepages 
>>> compared to 2MB.
>>> I am not an expert on hugepages to pinpoint the exact reason but it will 
>>> surely help if you can fix the 1G hugepage issue.
>>>  
>>> Thank you
>>> Sirshak Das 
>>> From: Damjan Marion mailto:dmar...@me.com>> 
>>> Sent: Tuesday, October 23, 2018 3:43 PM
>>> To: Sirshak Das mailto:sirshak@arm.com>>
>>> Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>; Honnappa 
>>> Nagarahalli >> >; Lijian Zhang (Arm Technology China) 
>>> mailto:lijian.zh...@arm.com>>; khemendra kumar 
>>> mailto:khemendra.kuma...@gmail.com>>; Juraj 
>>> Linkeš mailto:juraj.lin...@pantheon.tech>>
>>> Subject: Re: [vpp-dev] running VPP non-root broken
>>>  
>>>  
>>> OMG, you are good in wasting memory. 1G pages, 2G per socket given to dpdk 
>>> to hang empty :)
>>> 128K buffers
>>>  
>>> For a start can you switch default page size to 2M. newer x86 kernels 
>>> ignore it but maybe it behaves
>>> differently on aarch64...
>>>  
>>> In the meantime I will fix few coverity issues...
>>>  
>>> -- 
>>> Damjan
>>> 
>>> 
 On 23 Oct 2018, at 20:45, Sirshak Das >>> > wrote:
  
 Hi Damjan,
  
 I am getting the following error as well I don’t know if its related to 
 this issue:
 vlib_plugin_early_init:361: plugin path 
 /home/sirdas/code/commita/vpp/build-root/install-vpp-native/vpp/lib/vpp_plugins
 load_one_plugin:117: Plugin disabled (default): abf_plugin.so
 load_one_plugin:117: Plugin disabled (default): acl_plugin.so
 load_one_plugin:117: Plugin disabled (default): avf_plugin.so
 load_one_plugin:117: Plugin disabled (default): cdp_plugin.so
 load_one_plugin:189: Loaded plugin: dpdk_plugin.so (Data Plane Development 
 Kit (DPDK))
 load_one_plugin:117: Plugin disabled (default): flowprobe_plugin.so
 load_one_plugin:117: Plugin disabled (default): gbp_plugin.so
 load_one_plugin:117: Plugin disabled (default): gtpu_plugin.so
 load_one_plugin:117: Plugin disabled (default): igmp_plugin.so
 load_one_plugin:117: Plugin disabled (default): ila_plugin.so
 load_one_plugin:117: Plugin disabled (default): ioam_plugin.so
 load_one_plugin:117: Plugin disabled (default): ixge_plugin.so
 load_one_plugin:117: Plugin disabled (default): l2e_plugin.so
 load_one_plugin:117: Plugin disabled (default): lacp_plugin.so
 load_one_plugin:117: Plugin disabled (default): lb_plugin.so
 load_one_plugin:117: Plugin disabled (default): mactime_plugin.so
 load_one_plugin:117: Plugin disabled (default): map_plugin.so
 load_one_plugin:117: Plugin disabled (default): memif_plugin.so
 load_one_plugin:117: Plugin disabled (default): nat_plugin.so
 load_one_plugin:117: Plugin disabled (default): nsh_plugin.so
 load_one_plugin:117: Plugin disabled (default): nsim_plugin.so
 load_one_plugin:117: Plugin disabled (default): perfmon_plugin.so
 load_one_plugin:117: Plugin disabled (default): pppoe_plugin.so
 load_one_plugin:117: Plugin disabled (default): srv6ad_plugin.so
 load_one_plugin:117: Plugin disabled (default): srv6am_plugin.so
 load_one_plugin:117: Plugin disabled (default): srv6as_plugin.so
 load_one_plugin:117: Plugin disabled (default): stn_plugin.so
 load_one_plugin:117: Plugin disabled (default): svs_plugin.so
 load_one_plugin:117: Plugin disabled (default): tlsmbedtls_plugin.so
 

Re: [vpp-dev] Memory Performance issue #vpp

2018-10-24 Thread Dave Barach via Lists.Fd.Io
There is no such thing as a free lunch.

If you force a fresh allocation measured in gigabytes, the memory allocator 
will mmap(...) a bunch of (4k) pages which will incur (expensive) pagefaults as 
they’re populated. Vec_validate(...) copies data when necessary. When 
structures grow to gigabytes, that takes a measurable amount of time and will 
almost certainly result in packet drops.

Preallocation is the only strategy for avoiding packet drops when data 
structures expand beyond a certain size. Either that, or simply accept 
vector-size excursions until vpp reaches steady state: at that point, data 
structures shouldn’t have to expand, and you shouldn’t drop any more packets.

Note that vec_reset_length(v) is highly preferable to constant cycling of fresh 
large vectors from vec_validate(...) / vec_add1(...) to vec_free(...).

HTH... D.


From: vpp-dev@lists.fd.io  On Behalf Of 
david.leitch@gmail.com
Sent: Wednesday, October 24, 2018 11:06 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Memory Performance issue #vpp


[Edited Message Follows]
Do you mean it is impossible to have packet processing and memory operation at 
the same time,
for example doing vec_validate or vec_free when NAT plugin is working and 
create new session.

I have drop rate when vec_free or vec_vlidate for memory size greater than 3GB.

What are your suggestions for such problems?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10961): https://lists.fd.io/g/vpp-dev/message/10961
Mute This Topic: https://lists.fd.io/mt/27615950/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] [csit-dev] VPP 18.10 is out!!!

2018-10-24 Thread Florin Coras
Awesome! Thanks, Marco!

Florin

> On Oct 24, 2018, at 12:46 AM, Marco Varlese  wrote:
> 
> Dear all,
> 
> I am very happy to announce that release 18.10 is available.
> 
> Release artificats can be found on both Nexus and Packagecloud.
> 
> Thanks to all contributors for yet another great release!
> 
> 
> Cheers,
> -- 
> Marco V
> 
> SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#3140): https://lists.fd.io/g/csit-dev/message/3140
> Mute This Topic: https://lists.fd.io/mt/27615759/675152
> Group Owner: csit-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/csit-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10962): https://lists.fd.io/g/vpp-dev/message/10962
Mute This Topic: https://lists.fd.io/mt/27619099/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] running VPP non-root broken

2018-10-24 Thread Marco Varlese
Hi Damjan,
On Wed, 2018-10-24 at 16:14 +0200, Damjan Marion via Lists.Fd.Io wrote:
> We merged patch which should fix things with 1G hugepages but I was not able
> to test it on arm, so please try...

Is this something which should go also on stable/1810 for a potential future dot
release?
If so could you please cherry pick it to that branch?


> -- 
> Damjan

Cheers,
Marco

> 
> 
> > On 24 Oct 2018, at 05:28, Sirshak Das  wrote:
> > 2M works but 1G still fails.
> >  
> > I toned down the dpdk resource allocation to default:
> > dpdk
> > {
> >   dev 0004:01:00.1
> >   dev 0004:01:00.2
> >   no-multi-seg
> >   log-level debug
> >   dev default
> >   {
> > num-rx-queues 1
> > # num-tx-queues 4
> > num-rx-desc 2048
> > num-tx-desc 2048
> >   }
> >   # num-mbufs 128000
> >   # socket-mem 2048,2048
> >   no-tx-checksum-offload
> >  
> > But here is the problem (for 16G of Hugepage memory):
> > With:
> > 2MB (nr_hugepages: 8192)
> > GRUB_CMDLINE_LINUX="default_hugepagesz=2M hugepagesz=1G hugepages=16
> > hugepagesz=2M hugepages=8192 iommu.passthrough=1 isolcpus=16-45
> > nohz_full=16-45 rcu_nocbs=16-45"
> > vs 1GB (nr_hugepages: 16)
> > GRUB_CMDLINE_LINUX="default_hugepagesz=1G hugepagesz=1G hugepages=16
> > hugepagesz=2M hugepages=8192 iommu.passthrough=1 isolcpus=16-45
> > nohz_full=16-45 rcu_nocbs=16-45"
> >  
> > I am getting a performance improvement of 49% when I use 1G hugepages
> > compared to 2MB.
> > I am not an expert on hugepages to pinpoint the exact reason but it will
> > surely help if you can fix the 1G hugepage issue.
> >  
> > Thank you
> > Sirshak Das 
> > From: Damjan Marion  
> > Sent: Tuesday, October 23, 2018 3:43 PM
> > To: Sirshak Das 
> > Cc: vpp-dev ; Honnappa Nagarahalli <
> > honnappa.nagaraha...@arm.com>; Lijian Zhang (Arm Technology China) <
> > lijian.zh...@arm.com>; khemendra kumar ; Juraj
> > Linkeš 
> > Subject: Re: [vpp-dev] running VPP non-root broken
> >  
> >  
> > OMG, you are good in wasting memory. 1G pages, 2G per socket given to dpdk
> > to hang empty :)
> > 128K buffers
> >  
> > For a start can you switch default page size to 2M. newer x86 kernels ignore
> > it but maybe it behaves
> > differently on aarch64...
> >  
> > In the meantime I will fix few coverity issues...
> >  
> > -- 
> > Damjan
> > 
> > 
> > > On 23 Oct 2018, at 20:45, Sirshak Das  wrote:
> > >  
> > > Hi Damjan,
> > >  
> > > I am getting the following error as well I don’t know if its related to
> > > this issue:
> > > vlib_plugin_early_init:361: plugin path
> > > /home/sirdas/code/commita/vpp/build-root/install-vpp-
> > > native/vpp/lib/vpp_plugins
> > > load_one_plugin:117: Plugin disabled (default): abf_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): acl_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): avf_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): cdp_plugin.so
> > > load_one_plugin:189: Loaded plugin: dpdk_plugin.so (Data Plane Development
> > > Kit (DPDK))
> > > load_one_plugin:117: Plugin disabled (default): flowprobe_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): gbp_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): gtpu_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): igmp_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): ila_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): ioam_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): ixge_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): l2e_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): lacp_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): lb_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): mactime_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): map_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): memif_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): nat_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): nsh_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): nsim_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): perfmon_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): pppoe_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): srv6ad_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): srv6am_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): srv6as_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): stn_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): svs_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): tlsmbedtls_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): tlsopenssl_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): unittest_plugin.so
> > > load_one_plugin:117: Plugin disabled (default): vmxnet3_plugin.so
> > > clib_elf_parse_file: open `linux-vdso.so.1': No such file or directory
> > > load_one_vat_plugin:67: 

Re: [vpp-dev] [tsc] [csit-dev] VPP 18.10 is out!!!

2018-10-24 Thread Damjan Marion via Lists.Fd.Io

Jan,

vpp-ext-deps is not official vpp package, it is just helper package for 
developers.
It is not needed or intended to be used by end users

Why do you need it?

--
Damjan

On 24 Oct 2018, at 10:59, via Lists.Fd.Io 
mailto:jgelety=cisco@lists.fd.io>> wrote:

Hello Macro,

Great and thanks for the info!

Unfortunately, vpp-ext-deps packages are missing there [0] - is it possible to 
fix it, please?

Thanks,
Jan

[0] https://packagecloud.io/app/fdio/release/search?q=vpp-ext-deps

-Original Message-
From: csit-...@lists.fd.io 
mailto:csit-...@lists.fd.io>> On Behalf Of Marco Varlese
Sent: Wednesday, October 24, 2018 9:47 AM
To: vpp-dev@lists.fd.io; 
csit-...@lists.fd.io
Cc: t...@lists.fd.io
Subject: [csit-dev] VPP 18.10 is out!!!

Dear all,

I am very happy to announce that release 18.10 is available.

Release artificats can be found on both Nexus and Packagecloud.

Thanks to all contributors for yet another great release!


Cheers,
--
Marco V

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 
(AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#863): https://lists.fd.io/g/tsc/message/863
Mute This Topic: https://lists.fd.io/mt/27619232/675241
Group Owner: tsc+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/tsc/unsub  
[damar...@cisco.com]
-=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10964): https://lists.fd.io/g/vpp-dev/message/10964
Mute This Topic: https://lists.fd.io/mt/27619893/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] Memory Performance issue #vpp

2018-10-24 Thread david . leitch . vpp
Do you mean it is impossible to have packet processing and memory operation at 
the same time,
for example doing vec_validate or vec_free when NAT plugging is working and 
create new session.

I have drop rate when vec_free or vec_vlidate for memory size greater than 3GB. 

What are your suggestions for such problems?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10959): https://lists.fd.io/g/vpp-dev/message/10959
Mute This Topic: https://lists.fd.io/mt/27615950/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] running VPP non-root broken

2018-10-24 Thread Sirshak Das
FYI just to be on same page things are not broken in 1810 so I don’t think its 
needed. Its only broken in current master.

From: Marco Varlese 
Sent: Wednesday, October 24, 2018 9:18 AM
To: dmar...@me.com; Sirshak Das 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] running VPP non-root broken

Hi Damjan,

On Wed, 2018-10-24 at 16:14 +0200, Damjan Marion via Lists.Fd.Io wrote:

We merged patch which should fix things with 1G hugepages but I was not able to 
test it on arm, so please try...

Is this something which should go also on stable/1810 for a potential future 
dot release?
If so could you please cherry pick it to that branch?



--
Damjan

Cheers,
Marco



On 24 Oct 2018, at 05:28, Sirshak Das 
mailto:sirshak@arm.com>> wrote:
2M works but 1G still fails.

I toned down the dpdk resource allocation to default:
dpdk
{
  dev 0004:01:00.1
  dev 0004:01:00.2
  no-multi-seg
  log-level debug
  dev default
  {
num-rx-queues 1
# num-tx-queues 4
num-rx-desc 2048
num-tx-desc 2048
  }
  # num-mbufs 128000
  # socket-mem 2048,2048
  no-tx-checksum-offload

But here is the problem (for 16G of Hugepage memory):
With:
2MB (nr_hugepages: 8192)
GRUB_CMDLINE_LINUX="default_hugepagesz=2M hugepagesz=1G hugepages=16 
hugepagesz=2M hugepages=8192 iommu.passthrough=1 isolcpus=16-45 nohz_full=16-45 
rcu_nocbs=16-45"
vs 1GB (nr_hugepages: 16)
GRUB_CMDLINE_LINUX="default_hugepagesz=1G hugepagesz=1G hugepages=16 
hugepagesz=2M hugepages=8192 iommu.passthrough=1 isolcpus=16-45 nohz_full=16-45 
rcu_nocbs=16-45"

I am getting a performance improvement of 49% when I use 1G hugepages compared 
to 2MB.
I am not an expert on hugepages to pinpoint the exact reason but it will surely 
help if you can fix the 1G hugepage issue.

Thank you
Sirshak Das
From: Damjan Marion mailto:dmar...@me.com>>
Sent: Tuesday, October 23, 2018 3:43 PM
To: Sirshak Das mailto:sirshak@arm.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>; Honnappa 
Nagarahalli 
mailto:honnappa.nagaraha...@arm.com>>; Lijian 
Zhang (Arm Technology China) 
mailto:lijian.zh...@arm.com>>; khemendra kumar 
mailto:khemendra.kuma...@gmail.com>>; Juraj Linkeš 
mailto:juraj.lin...@pantheon.tech>>
Subject: Re: [vpp-dev] running VPP non-root broken


OMG, you are good in wasting memory. 1G pages, 2G per socket given to dpdk to 
hang empty :)
128K buffers

For a start can you switch default page size to 2M. newer x86 kernels ignore it 
but maybe it behaves
differently on aarch64...

In the meantime I will fix few coverity issues...

--
Damjan



On 23 Oct 2018, at 20:45, Sirshak Das 
mailto:sirshak@arm.com>> wrote:

Hi Damjan,

I am getting the following error as well I don’t know if its related to this 
issue:
vlib_plugin_early_init:361: plugin path 
/home/sirdas/code/commita/vpp/build-root/install-vpp-native/vpp/lib/vpp_plugins
load_one_plugin:117: Plugin disabled (default): abf_plugin.so
load_one_plugin:117: Plugin disabled (default): acl_plugin.so
load_one_plugin:117: Plugin disabled (default): avf_plugin.so
load_one_plugin:117: Plugin disabled (default): cdp_plugin.so
load_one_plugin:189: Loaded plugin: dpdk_plugin.so (Data Plane Development Kit 
(DPDK))
load_one_plugin:117: Plugin disabled (default): flowprobe_plugin.so
load_one_plugin:117: Plugin disabled (default): gbp_plugin.so
load_one_plugin:117: Plugin disabled (default): gtpu_plugin.so
load_one_plugin:117: Plugin disabled (default): igmp_plugin.so
load_one_plugin:117: Plugin disabled (default): ila_plugin.so
load_one_plugin:117: Plugin disabled (default): ioam_plugin.so
load_one_plugin:117: Plugin disabled (default): ixge_plugin.so
load_one_plugin:117: Plugin disabled (default): l2e_plugin.so
load_one_plugin:117: Plugin disabled (default): lacp_plugin.so
load_one_plugin:117: Plugin disabled (default): lb_plugin.so
load_one_plugin:117: Plugin disabled (default): mactime_plugin.so
load_one_plugin:117: Plugin disabled (default): map_plugin.so
load_one_plugin:117: Plugin disabled (default): memif_plugin.so
load_one_plugin:117: Plugin disabled (default): nat_plugin.so
load_one_plugin:117: Plugin disabled (default): nsh_plugin.so
load_one_plugin:117: Plugin disabled (default): nsim_plugin.so
load_one_plugin:117: Plugin disabled (default): perfmon_plugin.so
load_one_plugin:117: Plugin disabled (default): pppoe_plugin.so
load_one_plugin:117: Plugin disabled (default): srv6ad_plugin.so
load_one_plugin:117: Plugin disabled (default): srv6am_plugin.so
load_one_plugin:117: Plugin disabled (default): srv6as_plugin.so
load_one_plugin:117: Plugin disabled (default): stn_plugin.so
load_one_plugin:117: Plugin disabled (default): svs_plugin.so
load_one_plugin:117: Plugin disabled (default): tlsmbedtls_plugin.so
load_one_plugin:117: Plugin disabled (default): tlsopenssl_plugin.so
load_one_plugin:117: Plugin disabled (default): unittest_plugin.so
load_one_plugin:117: Plugin disabled (default): vmxnet3_plugin.so
clib_elf_parse_file: open `linux-vdso.so.1': No such file or directory
load_one_vat_plugin:67: Loaded 

Re: [vpp-dev] running VPP non-root broken

2018-10-24 Thread Damjan Marion via Lists.Fd.Io

We merged patch which should fix things with 1G hugepages but I was not able to 
test it on arm, so please try...

-- 
Damjan

> On 24 Oct 2018, at 05:28, Sirshak Das  wrote:
> 
> 2M works but 1G still fails.
>  
> I toned down the dpdk resource allocation to default:
> dpdk
> {
>   dev 0004:01:00.1
>   dev 0004:01:00.2
>   no-multi-seg
>   log-level debug
>   dev default
>   {
> num-rx-queues 1
> # num-tx-queues 4
> num-rx-desc 2048
> num-tx-desc 2048
>   }
>   # num-mbufs 128000
>   # socket-mem 2048,2048
>   no-tx-checksum-offload
>  
> But here is the problem (for 16G of Hugepage memory):
> With:
> 2MB (nr_hugepages: 8192)
> GRUB_CMDLINE_LINUX="default_hugepagesz=2M hugepagesz=1G hugepages=16 
> hugepagesz=2M hugepages=8192 iommu.passthrough=1 isolcpus=16-45 
> nohz_full=16-45 rcu_nocbs=16-45"
> vs 1GB (nr_hugepages: 16)
> GRUB_CMDLINE_LINUX="default_hugepagesz=1G hugepagesz=1G hugepages=16 
> hugepagesz=2M hugepages=8192 iommu.passthrough=1 isolcpus=16-45 
> nohz_full=16-45 rcu_nocbs=16-45"
>  
> I am getting a performance improvement of 49% when I use 1G hugepages 
> compared to 2MB.
> I am not an expert on hugepages to pinpoint the exact reason but it will 
> surely help if you can fix the 1G hugepage issue.
>  
> Thank you
> Sirshak Das 
> From: Damjan Marion  
> Sent: Tuesday, October 23, 2018 3:43 PM
> To: Sirshak Das 
> Cc: vpp-dev ; Honnappa Nagarahalli 
> ; Lijian Zhang (Arm Technology China) 
> ; khemendra kumar ; Juraj 
> Linkeš 
> Subject: Re: [vpp-dev] running VPP non-root broken
>  
>  
> OMG, you are good in wasting memory. 1G pages, 2G per socket given to dpdk to 
> hang empty :)
> 128K buffers
>  
> For a start can you switch default page size to 2M. newer x86 kernels ignore 
> it but maybe it behaves
> differently on aarch64...
>  
> In the meantime I will fix few coverity issues...
>  
> -- 
> Damjan
> 
> 
> On 23 Oct 2018, at 20:45, Sirshak Das  > wrote:
>  
> Hi Damjan,
>  
> I am getting the following error as well I don’t know if its related to this 
> issue:
> vlib_plugin_early_init:361: plugin path 
> /home/sirdas/code/commita/vpp/build-root/install-vpp-native/vpp/lib/vpp_plugins
> load_one_plugin:117: Plugin disabled (default): abf_plugin.so
> load_one_plugin:117: Plugin disabled (default): acl_plugin.so
> load_one_plugin:117: Plugin disabled (default): avf_plugin.so
> load_one_plugin:117: Plugin disabled (default): cdp_plugin.so
> load_one_plugin:189: Loaded plugin: dpdk_plugin.so (Data Plane Development 
> Kit (DPDK))
> load_one_plugin:117: Plugin disabled (default): flowprobe_plugin.so
> load_one_plugin:117: Plugin disabled (default): gbp_plugin.so
> load_one_plugin:117: Plugin disabled (default): gtpu_plugin.so
> load_one_plugin:117: Plugin disabled (default): igmp_plugin.so
> load_one_plugin:117: Plugin disabled (default): ila_plugin.so
> load_one_plugin:117: Plugin disabled (default): ioam_plugin.so
> load_one_plugin:117: Plugin disabled (default): ixge_plugin.so
> load_one_plugin:117: Plugin disabled (default): l2e_plugin.so
> load_one_plugin:117: Plugin disabled (default): lacp_plugin.so
> load_one_plugin:117: Plugin disabled (default): lb_plugin.so
> load_one_plugin:117: Plugin disabled (default): mactime_plugin.so
> load_one_plugin:117: Plugin disabled (default): map_plugin.so
> load_one_plugin:117: Plugin disabled (default): memif_plugin.so
> load_one_plugin:117: Plugin disabled (default): nat_plugin.so
> load_one_plugin:117: Plugin disabled (default): nsh_plugin.so
> load_one_plugin:117: Plugin disabled (default): nsim_plugin.so
> load_one_plugin:117: Plugin disabled (default): perfmon_plugin.so
> load_one_plugin:117: Plugin disabled (default): pppoe_plugin.so
> load_one_plugin:117: Plugin disabled (default): srv6ad_plugin.so
> load_one_plugin:117: Plugin disabled (default): srv6am_plugin.so
> load_one_plugin:117: Plugin disabled (default): srv6as_plugin.so
> load_one_plugin:117: Plugin disabled (default): stn_plugin.so
> load_one_plugin:117: Plugin disabled (default): svs_plugin.so
> load_one_plugin:117: Plugin disabled (default): tlsmbedtls_plugin.so
> load_one_plugin:117: Plugin disabled (default): tlsopenssl_plugin.so
> load_one_plugin:117: Plugin disabled (default): unittest_plugin.so
> load_one_plugin:117: Plugin disabled (default): vmxnet3_plugin.so
> clib_elf_parse_file: open `linux-vdso.so.1': No such file or directory
> load_one_vat_plugin:67: Loaded plugin: lb_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: gtpu_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: memif_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: nsh_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: nsim_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: avf_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: vmxnet3_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: pppoe_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: mactime_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: 

Re: [vpp-dev] [tsc] [csit-dev] VPP 18.10 is out!!!

2018-10-24 Thread Jan Gelety via Lists.Fd.Io
Hello Damjan,

Thanks for the info.

In the past there was used igb_uio driver for CSIT tests and former 
vpp-dpdk-dkms deb package, replaced by vpp-ext-deps package now, was used as 
source of this driver for tests on ubuntu.

But CSIT tests were modified to use vfio-pci driver so we were able to remove 
CSIT dependency on vpp-ext-deps package in master [0] as well as rls1810 [1] 
branches.

Thus we don’t need it anymore.

Thanks,
Jan

[0] https://gerrit.fd.io/r/#/c/15505/
[1] https://gerrit.fd.io/r/#/c/15512/

From: Damjan Marion (damarion)
Sent: Wednesday, October 24, 2018 7:00 PM
To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) 
Cc: Marco Varlese ; vpp-dev@lists.fd.io; 
csit-...@lists.fd.io; t...@lists.fd.io
Subject: Re: [tsc] [csit-dev] VPP 18.10 is out!!!


Jan,

vpp-ext-deps is not official vpp package, it is just helper package for 
developers.
It is not needed or intended to be used by end users

Why do you need it?

--
Damjan


On 24 Oct 2018, at 10:59, via Lists.Fd.Io 
mailto:jgelety=cisco@lists.fd.io>> wrote:

Hello Macro,

Great and thanks for the info!

Unfortunately, vpp-ext-deps packages are missing there [0] - is it possible to 
fix it, please?

Thanks,
Jan

[0] https://packagecloud.io/app/fdio/release/search?q=vpp-ext-deps

-Original Message-
From: csit-...@lists.fd.io 
mailto:csit-...@lists.fd.io>> On Behalf Of Marco Varlese
Sent: Wednesday, October 24, 2018 9:47 AM
To: vpp-dev@lists.fd.io; 
csit-...@lists.fd.io
Cc: t...@lists.fd.io
Subject: [csit-dev] VPP 18.10 is out!!!

Dear all,

I am very happy to announce that release 18.10 is available.

Release artificats can be found on both Nexus and Packagecloud.

Thanks to all contributors for yet another great release!


Cheers,
--
Marco V

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 
(AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#863): https://lists.fd.io/g/tsc/message/863
Mute This Topic: https://lists.fd.io/mt/27619232/675241
Group Owner: tsc+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/tsc/unsub  
[damar...@cisco.com]
-=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10965): https://lists.fd.io/g/vpp-dev/message/10965
Mute This Topic: https://lists.fd.io/mt/27619893/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] running VPP non-root broken

2018-10-24 Thread Stephen Hemminger
On Wed, 24 Oct 2018 11:31:38 -0700
"Stephen Hemminger"  wrote:

> On Wed, 24 Oct 2018 16:27:24 +
> "Sirshak Das"  wrote:
> 
> > FYI just to be on same page things are not broken in 1810 so I don’t think 
> > its needed. Its only broken in current master.
> > 
> > From: Marco Varlese 
> > Sent: Wednesday, October 24, 2018 9:18 AM
> > To: dmar...@me.com; Sirshak Das 
> > Cc: vpp-dev@lists.fd.io
> > Subject: Re: [vpp-dev] running VPP non-root broken
> > 
> > Hi Damjan,
> > 
> > On Wed, 2018-10-24 at 16:14 +0200, Damjan Marion via Lists.Fd.Io wrote:
> > 
> > We merged patch which should fix things with 1G hugepages but I was not 
> > able to test it on arm, so please try...
> > 
> > Is this something which should go also on stable/1810 for a potential 
> > future dot release?
> > If so could you please cherry pick it to that branch?
> > 
> > 
> > 
> > --
> > Damjan
> > 
> > Cheers,
> > Marco
> > 
> > 
> > 
> > On 24 Oct 2018, at 05:28, Sirshak Das 
> > mailto:sirshak@arm.com>> wrote:
> > 2M works but 1G still fails.
> > 
> > I toned down the dpdk resource allocation to default:
> > dpdk
> > {
> >   dev 0004:01:00.1
> >   dev 0004:01:00.2
> >   no-multi-seg
> >   log-level debug
> >   dev default
> >   {
> > num-rx-queues 1
> > # num-tx-queues 4
> > num-rx-desc 2048
> > num-tx-desc 2048
> >   }
> >   # num-mbufs 128000
> >   # socket-mem 2048,2048
> >   no-tx-checksum-offload
> > 
> > But here is the problem (for 16G of Hugepage memory):
> > With:
> > 2MB (nr_hugepages: 8192)
> > GRUB_CMDLINE_LINUX="default_hugepagesz=2M hugepagesz=1G hugepages=16 
> > hugepagesz=2M hugepages=8192 iommu.passthrough=1 isolcpus=16-45 
> > nohz_full=16-45 rcu_nocbs=16-45"
> > vs 1GB (nr_hugepages: 16)
> > GRUB_CMDLINE_LINUX="default_hugepagesz=1G hugepagesz=1G hugepages=16 
> > hugepagesz=2M hugepages=8192 iommu.passthrough=1 isolcpus=16-45 
> > nohz_full=16-45 rcu_nocbs=16-45"
> > 
> > I am getting a performance improvement of 49% when I use 1G hugepages 
> > compared to 2MB.
> > I am not an expert on hugepages to pinpoint the exact reason but it will 
> > surely help if you can fix the 1G hugepage issue.
> > 
> > Thank you
> > Sirshak Das
> > From: Damjan Marion mailto:dmar...@me.com>>
> > Sent: Tuesday, October 23, 2018 3:43 PM
> > To: Sirshak Das mailto:sirshak@arm.com>>
> > Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>; Honnappa 
> > Nagarahalli 
> > mailto:honnappa.nagaraha...@arm.com>>; Lijian 
> > Zhang (Arm Technology China) 
> > mailto:lijian.zh...@arm.com>>; khemendra kumar 
> > mailto:khemendra.kuma...@gmail.com>>; Juraj 
> > Linkeš mailto:juraj.lin...@pantheon.tech>>
> > Subject: Re: [vpp-dev] running VPP non-root broken
> > 
> > 
> > OMG, you are good in wasting memory. 1G pages, 2G per socket given to dpdk 
> > to hang empty :)
> > 128K buffers
> > 
> > For a start can you switch default page size to 2M. newer x86 kernels 
> > ignore it but maybe it behaves
> > differently on aarch64...
> > 
> > In the meantime I will fix few coverity issues...
> > 
> > --
> > Damjan
> > 
> > 
> > 
> > On 23 Oct 2018, at 20:45, Sirshak Das 
> > mailto:sirshak@arm.com>> wrote:
> > 
> > Hi Damjan,
> > 
> > I am getting the following error as well I don’t know if its related to 
> > this issue:
> > vlib_plugin_early_init:361: plugin path 
> > /home/sirdas/code/commita/vpp/build-root/install-vpp-native/vpp/lib/vpp_plugins
> > load_one_plugin:117: Plugin disabled (default): abf_plugin.so
> > load_one_plugin:117: Plugin disabled (default): acl_plugin.so
> > load_one_plugin:117: Plugin disabled (default): avf_plugin.so
> > load_one_plugin:117: Plugin disabled (default): cdp_plugin.so
> > load_one_plugin:189: Loaded plugin: dpdk_plugin.so (Data Plane Development 
> > Kit (DPDK))
> > load_one_plugin:117: Plugin disabled (default): flowprobe_plugin.so
> > load_one_plugin:117: Plugin disabled (default): gbp_plugin.so
> > load_one_plugin:117: Plugin disabled (default): gtpu_plugin.so
> > load_one_plugin:117: Plugin disabled (default): igmp_plugin.so
> > load_one_plugin:117: Plugin disabled (default): ila_plugin.so
> > load_one_plugin:117: Plugin disabled (default): ioam_plugin.so
> > load_one_plugin:117: Plugin disabled (default): ixge_plugin.so
> > load_one_plugin:117: Plugin disabled (default): l2e_plugin.so
> > load_one_plugin:117: Plugin disabled (default): lacp_plugin.so
> > load_one_plugin:117: Plugin disabled (default): lb_plugin.so
> > load_one_plugin:117: Plugin disabled (default): mactime_plugin.so
> > load_one_plugin:117: Plugin disabled (default): map_plugin.so
> > load_one_plugin:117: Plugin disabled (default): memif_plugin.so
> > load_one_plugin:117: Plugin disabled (default): nat_plugin.so
> > load_one_plugin:117: Plugin disabled (default): nsh_plugin.so
> > load_one_plugin:117: Plugin disabled (default): nsim_plugin.so
> > load_one_plugin:117: Plugin disabled (default): perfmon_plugin.so
> > load_one_plugin:117: Plugin disabled (default): pppoe_plugin.so
> > load_one_plugin:117: Plugin disabled 

Re: [vpp-dev] clearing stats

2018-10-24 Thread David Cornejo
Ole,

thanks!

on a related note: do you intend that people will add to the
stat_directory_type_t with more complex specific types or keep it to
more primitive generic types?
On Mon, Oct 22, 2018 at 10:20 AM Ole Troan  wrote:
>
> David,
>
> > in the new stats api, is there a way to clear counters or would that
> > be done using the existing messages? for example, clearing interface
> > stats with VL_API_SW_INTERFACE_CLEAR_STATS.
>
> There is nothing that clears all stats.
> The SW_INTERFACE_CLEAR_STATS will clear the interface stats.
>
> Guess we should at least add a clear for the node performance counters.
>
> Cheers,
> Ole



-- 
Kailua, Hawaiʻi
US +1 (808) 728-3050
UK +44 (020) 3286 2808
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10966): https://lists.fd.io/g/vpp-dev/message/10966
Mute This Topic: https://lists.fd.io/mt/27525199/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] running VPP non-root broken

2018-10-24 Thread Stephen Hemminger
On Wed, 24 Oct 2018 16:27:24 +
"Sirshak Das"  wrote:

> FYI just to be on same page things are not broken in 1810 so I don’t think 
> its needed. Its only broken in current master.
> 
> From: Marco Varlese 
> Sent: Wednesday, October 24, 2018 9:18 AM
> To: dmar...@me.com; Sirshak Das 
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] running VPP non-root broken
> 
> Hi Damjan,
> 
> On Wed, 2018-10-24 at 16:14 +0200, Damjan Marion via Lists.Fd.Io wrote:
> 
> We merged patch which should fix things with 1G hugepages but I was not able 
> to test it on arm, so please try...
> 
> Is this something which should go also on stable/1810 for a potential future 
> dot release?
> If so could you please cherry pick it to that branch?
> 
> 
> 
> --
> Damjan
> 
> Cheers,
> Marco
> 
> 
> 
> On 24 Oct 2018, at 05:28, Sirshak Das 
> mailto:sirshak@arm.com>> wrote:
> 2M works but 1G still fails.
> 
> I toned down the dpdk resource allocation to default:
> dpdk
> {
>   dev 0004:01:00.1
>   dev 0004:01:00.2
>   no-multi-seg
>   log-level debug
>   dev default
>   {
> num-rx-queues 1
> # num-tx-queues 4
> num-rx-desc 2048
> num-tx-desc 2048
>   }
>   # num-mbufs 128000
>   # socket-mem 2048,2048
>   no-tx-checksum-offload
> 
> But here is the problem (for 16G of Hugepage memory):
> With:
> 2MB (nr_hugepages: 8192)
> GRUB_CMDLINE_LINUX="default_hugepagesz=2M hugepagesz=1G hugepages=16 
> hugepagesz=2M hugepages=8192 iommu.passthrough=1 isolcpus=16-45 
> nohz_full=16-45 rcu_nocbs=16-45"
> vs 1GB (nr_hugepages: 16)
> GRUB_CMDLINE_LINUX="default_hugepagesz=1G hugepagesz=1G hugepages=16 
> hugepagesz=2M hugepages=8192 iommu.passthrough=1 isolcpus=16-45 
> nohz_full=16-45 rcu_nocbs=16-45"
> 
> I am getting a performance improvement of 49% when I use 1G hugepages 
> compared to 2MB.
> I am not an expert on hugepages to pinpoint the exact reason but it will 
> surely help if you can fix the 1G hugepage issue.
> 
> Thank you
> Sirshak Das
> From: Damjan Marion mailto:dmar...@me.com>>
> Sent: Tuesday, October 23, 2018 3:43 PM
> To: Sirshak Das mailto:sirshak@arm.com>>
> Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>; Honnappa 
> Nagarahalli 
> mailto:honnappa.nagaraha...@arm.com>>; Lijian 
> Zhang (Arm Technology China) 
> mailto:lijian.zh...@arm.com>>; khemendra kumar 
> mailto:khemendra.kuma...@gmail.com>>; Juraj 
> Linkeš mailto:juraj.lin...@pantheon.tech>>
> Subject: Re: [vpp-dev] running VPP non-root broken
> 
> 
> OMG, you are good in wasting memory. 1G pages, 2G per socket given to dpdk to 
> hang empty :)
> 128K buffers
> 
> For a start can you switch default page size to 2M. newer x86 kernels ignore 
> it but maybe it behaves
> differently on aarch64...
> 
> In the meantime I will fix few coverity issues...
> 
> --
> Damjan
> 
> 
> 
> On 23 Oct 2018, at 20:45, Sirshak Das 
> mailto:sirshak@arm.com>> wrote:
> 
> Hi Damjan,
> 
> I am getting the following error as well I don’t know if its related to this 
> issue:
> vlib_plugin_early_init:361: plugin path 
> /home/sirdas/code/commita/vpp/build-root/install-vpp-native/vpp/lib/vpp_plugins
> load_one_plugin:117: Plugin disabled (default): abf_plugin.so
> load_one_plugin:117: Plugin disabled (default): acl_plugin.so
> load_one_plugin:117: Plugin disabled (default): avf_plugin.so
> load_one_plugin:117: Plugin disabled (default): cdp_plugin.so
> load_one_plugin:189: Loaded plugin: dpdk_plugin.so (Data Plane Development 
> Kit (DPDK))
> load_one_plugin:117: Plugin disabled (default): flowprobe_plugin.so
> load_one_plugin:117: Plugin disabled (default): gbp_plugin.so
> load_one_plugin:117: Plugin disabled (default): gtpu_plugin.so
> load_one_plugin:117: Plugin disabled (default): igmp_plugin.so
> load_one_plugin:117: Plugin disabled (default): ila_plugin.so
> load_one_plugin:117: Plugin disabled (default): ioam_plugin.so
> load_one_plugin:117: Plugin disabled (default): ixge_plugin.so
> load_one_plugin:117: Plugin disabled (default): l2e_plugin.so
> load_one_plugin:117: Plugin disabled (default): lacp_plugin.so
> load_one_plugin:117: Plugin disabled (default): lb_plugin.so
> load_one_plugin:117: Plugin disabled (default): mactime_plugin.so
> load_one_plugin:117: Plugin disabled (default): map_plugin.so
> load_one_plugin:117: Plugin disabled (default): memif_plugin.so
> load_one_plugin:117: Plugin disabled (default): nat_plugin.so
> load_one_plugin:117: Plugin disabled (default): nsh_plugin.so
> load_one_plugin:117: Plugin disabled (default): nsim_plugin.so
> load_one_plugin:117: Plugin disabled (default): perfmon_plugin.so
> load_one_plugin:117: Plugin disabled (default): pppoe_plugin.so
> load_one_plugin:117: Plugin disabled (default): srv6ad_plugin.so
> load_one_plugin:117: Plugin disabled (default): srv6am_plugin.so
> load_one_plugin:117: Plugin disabled (default): srv6as_plugin.so
> load_one_plugin:117: Plugin disabled (default): stn_plugin.so
> load_one_plugin:117: Plugin disabled (default): svs_plugin.so
> load_one_plugin:117: Plugin disabled 

Re: [vpp-dev] running VPP non-root broken

2018-10-24 Thread Damjan Marion via Lists.Fd.Io


> On 24 Oct 2018, at 20:41, Stephen Hemminger  
> wrote:
> 
> On Wed, 24 Oct 2018 11:31:38 -0700
> "Stephen Hemminger"  > wrote:

[snip]

> 
> The problem is that the setup code decides to make 1 huge page. And since 
> huge page size
> on this system is 256M, DPDK can't even get stared.

Already fixed in master... (hopefully works on Aarch64)

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10969): https://lists.fd.io/g/vpp-dev/message/10969
Mute This Topic: https://lists.fd.io/mt/27570325/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] Problem switching a bonded interface from L2 to L3 mode

2018-10-24 Thread steven luong via Lists.Fd.Io
Are you using VPP native bonding driver or DPDK bonding driver? How do you 
configure the bonding interface? Please include the configuration and process 
to recreate the problem.

Steven

From:  on behalf of "saint_sun 孙 via Lists.Fd.Io" 

Reply-To: "saint_...@aliyun.com" 
Date: Wednesday, October 24, 2018 at 8:07 PM
To: "John Lo (loj)" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] Problem switching a bonded interface from L2 to L3 mode

Ok, I forgot to click the reply-all. who is familiar with the problem I 
mentioned below please tell me,thanks!





2018年10月25日 星期四 +0800 10:32 发件人 John Lo (loj) :

Please include vpp-dev alias on any questions about VPP, instead of unicast an 
individual only. Then whoever is familiar with the area you are asking about 
may respond.  Does anyone know about the potential problem of switching between 
L2 and L3 modes on a bonded interface described in this email (I did change the 
email subject accordingly)?   -John



From: saint_sun 孙 mailto:saint_...@aliyun.com>>
Sent: Wednesday, October 24, 2018 8:52 PM
To: John Lo (loj) mailto:l...@cisco.com>>
Subject: Re: RE: RE: [vpp-dev]vlan interface support?



I am very grateful for your help.

And when I test the VLAN, maybe I find a bug that if I switch the mode of the 
Bonding interface to L2 and then switch back to L3,the bonding interface can 
not work as before.

I have found the error code that is in the mode switch function of bonding 
device: when set the mode of bonding interface to l2, all the members of the 
bonding interface will be set to l2, but when set the bonding interface back, 
all the members do not recover to l3.



At last I have another doubt that when I configure an IP address for an 
interface, then I ping the address from VPP, it’s failed, why?should I do other 
more settings?




2018年10月15日 星期一 +0800 22:20 发件人 John Lo (loj) 
mailto:l...@cisco.com>>:

If there is a BVI in a BD with sub-interfaces in the same BD which get packets 
with VLAN tags, it is best to configure a tag-rewrite operation on the 
sub-interfaces to pop their VLAN tags.  Then all packets are forwarded in BD 
without VLAN tags.  The CLI is “set interface l2 tag-rewrite  
pop 1” if the sub-interface has one VLAN tag.–John



From: saint_sun 孙 mailto:saint_...@aliyun.com>>
Sent: Monday, October 15, 2018 2:42 AM
To: John Lo (loj) mailto:l...@cisco.com>>
Cc: vpp-dev@lists.fd.io
Subject: Re: RE: [vpp-dev]vlan interface support?



I am very grateful to you for your advice!

I have tested it,But there is something wrong. when I receive an arp or ICMP 
packet from a l2 subif  that joins to bd 200 and encapsulates vlan 200,the 
reply packet that send from the subif does not have the vlan tag 200. Any more 
other configurations should I set?




可用于iOS的myMail发送


2018年10月14日 星期日 +0800 04:58 发件人 l...@cisco.com 
mailto:l...@cisco.com>>:

The equivalent of VLAN on a switch in VPP is a bridge domain or BD for short.  
One can put interfaces or VLAN sub-interfaces in a BD to form a L2 network 
among all interfaces in it.  One can also create a loopback interface, put it 
in a BD as its BVI (Bridge Virtual Interface) and assign IP addresses to it.  
Then packet can be IP forwarded into a BD through its BVI.



Following is the VPP CLI sequence to create a loopback (resulting in interface 
name loop0), put it in BD 13 as a BVI, and put an IP address on it:



loopback create mac 1a:2b:3c:4d:5e:6f

set interface l2 bridge loop0 13 bvi

set interface state loop0 up

set interface ip address loop0 6.0.0.250/16



Regards,

John



From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of saint_sun ? via 
Lists.Fd.Io
Sent: Friday, October 12, 2018 3:52 AM
To: vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev]vlan interface support?



I have a question:

Does vpp has the function like the configuration example:

interface f0/1

switchport access vlan 10



Interface vlan 10

ip address 10.0.0.1 255.255.255.0



If vpp has the function, where can I find the command and the source code?



Another question, does vpp support superVLAN?



anyone who knows please tell me, appreciate for your reply very much!


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10977): https://lists.fd.io/g/vpp-dev/message/10977
Mute This Topic: https://lists.fd.io/mt/27628831/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] running VPP non-root broken

2018-10-24 Thread Stephen Hemminger
On Wed, 24 Oct 2018 23:09:15 +0200
Damjan Marion  wrote:

> — 
> Damjan
> 
> > On 24 Oct 2018, at 23:04, Stephen Hemminger  
> > wrote:
> > 
> > On Wed, 24 Oct 2018 21:07:15 +0200
> > Damjan Marion  wrote:
> >   
> >>> On 24 Oct 2018, at 20:41, Stephen Hemminger  
> >>> wrote:
> >>> 
> >>> On Wed, 24 Oct 2018 11:31:38 -0700
> >>> "Stephen Hemminger"  >>> > wrote:
> >> 
> >> [snip]
> >>   
> >>> 
> >>> The problem is that the setup code decides to make 1 huge page. And since 
> >>> huge page size
> >>> on this system is 256M, DPDK can't even get stared.
> >> 
> >> Already fixed in master... (hopefully works on Aarch64)
> >>   
> > 
> > Still broken, added some instrumentation to clib_sysfs_prealloc_hugepages
> > and got.
> > 
> > clib_sysfs_prealloc_hugepages:261: found log2=21 page_size=2048 n=0
> > clib_sysfs_prealloc_hugepages:264: pre-allocating 1 additional 2048K 
> > hugepages on numa node 0
> > clib_sysfs_set_nr_hugepages:158: set 
> > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages to 1
> > 
> > DPDK won't start with on 2M of memory.  
> 
> Yeah, i already fixed that but it is not merged yet. This is just prealloc 
> issue, if pages are preallocated everything should work ok.

Got it, fixed for me.
Wonder why CI never caught this??
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10973): https://lists.fd.io/g/vpp-dev/message/10973
Mute This Topic: https://lists.fd.io/mt/27570325/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[vpp-dev] Problem switching a bonded interface from L2 to L3 mode

2018-10-24 Thread John Lo (loj) via Lists.Fd.Io
Please include vpp-dev alias on any questions about VPP, instead of unicast an 
individual only. Then whoever is familiar with the area you are asking about 
may respond.  Does anyone know about the potential problem of switching between 
L2 and L3 modes on a bonded interface described in this email (I did change the 
email subject accordingly)?   -John

From: saint_sun 孙 
Sent: Wednesday, October 24, 2018 8:52 PM
To: John Lo (loj) 
Subject: Re: RE: RE: [vpp-dev]vlan interface support?

I am very grateful for your help.
And when I test the VLAN, maybe I find a bug that if I switch the mode of the 
Bonding interface to L2 and then switch back to L3,the bonding interface can 
not work as before.
I have found the error code that is in the mode switch function of bonding 
device: when set the mode of bonding interface to l2, all the members of the 
bonding interface will be set to l2, but when set the bonding interface back, 
all the members do not recover to l3.

At last I have another doubt that when I configure an IP address for an 
interface, then I ping the address from VPP, it’s failed, why?should I do other 
more settings?



2018年10月15日 星期一 +0800 22:20 发件人 John Lo (loj) 
mailto:l...@cisco.com>>:

If there is a BVI in a BD with sub-interfaces in the same BD which get packets 
with VLAN tags, it is best to configure a tag-rewrite operation on the 
sub-interfaces to pop their VLAN tags.  Then all packets are forwarded in BD 
without VLAN tags.  The CLI is “set interface l2 tag-rewrite  
pop 1” if the sub-interface has one VLAN tag.–John



From: saint_sun 孙 mailto:saint_...@aliyun.com>>
Sent: Monday, October 15, 2018 2:42 AM
To: John Lo (loj) mailto:l...@cisco.com>>
Cc: vpp-dev@lists.fd.io
Subject: Re: RE: [vpp-dev]vlan interface support?



I am very grateful to you for your advice!

I have tested it,But there is something wrong. when I receive an arp or ICMP 
packet from a l2 subif  that joins to bd 200 and encapsulates vlan 200,the 
reply packet that send from the subif does not have the vlan tag 200. Any more 
other configurations should I set?




可用于iOS的myMail发送


2018年10月14日 星期日 +0800 04:58 发件人 l...@cisco.com 
mailto:l...@cisco.com>>:

The equivalent of VLAN on a switch in VPP is a bridge domain or BD for short.  
One can put interfaces or VLAN sub-interfaces in a BD to form a L2 network 
among all interfaces in it.  One can also create a loopback interface, put it 
in a BD as its BVI (Bridge Virtual Interface) and assign IP addresses to it.  
Then packet can be IP forwarded into a BD through its BVI.



Following is the VPP CLI sequence to create a loopback (resulting in interface 
name loop0), put it in BD 13 as a BVI, and put an IP address on it:



loopback create mac 1a:2b:3c:4d:5e:6f

set interface l2 bridge loop0 13 bvi

set interface state loop0 up

set interface ip address loop0 6.0.0.250/16



Regards,

John



From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of saint_sun ? via 
Lists.Fd.Io
Sent: Friday, October 12, 2018 3:52 AM
To: vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev]vlan interface support?



I have a question:

Does vpp has the function like the configuration example:

interface f0/1

switchport access vlan 10



Interface vlan 10

ip address 10.0.0.1 255.255.255.0



If vpp has the function, where can I find the command and the source code?



Another question, does vpp support superVLAN?



anyone who knows please tell me, appreciate for your reply very much!


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10975): https://lists.fd.io/g/vpp-dev/message/10975
Mute This Topic: https://lists.fd.io/mt/27628831/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] [tsc] Project Proposal for Sweetcomb

2018-10-24 Thread Ni, Hongjun
Hi all,

Some guys are asking for the original code in private.
Here is our answer:


We are working on reworking the original code, and doing internal legal review.

When it is done,  we will submit the code to FD.io community for IPR review in 
one or two weeks.

Thanks a lot,
Hongjun

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Edward 
Warnicke
Sent: Tuesday, October 23, 2018 9:47 PM
To: Ni, Hongjun 
Cc: t...@lists.fd.io; vpp-dev@lists.fd.io; Wang, Drenfong 
; ??? ; 
chen...@huachentel.com; lizhuo...@cmhi.chinamobile.com; ??? 
; zhijl@chinatelecom.cn; changlin...@nxp.com; Wang 
Tianyi ; davidfgao(?? ; 
lixin...@huachentel.com; jingqing@alibaba-inc.com
Subject: Re: [vpp-dev] [tsc] Project Proposal for Sweetcomb

I look forward to it :)

Ed

On Tue, Oct 23, 2018 at 8:42 AM Ni, Hongjun 
mailto:hongjun...@intel.com>> wrote:
Hi Ed,

OK. I or some project proposer will join the Nov 8 8am PT TSC meeting and 
present the proposal.

Thanks a lot,
Hongjun

From: t...@lists.fd.io 
[mailto:t...@lists.fd.io] On Behalf Of Edward Warnicke
Sent: Tuesday, October 23, 2018 9:15 PM
To: Ni, Hongjun mailto:hongjun...@intel.com>>
Cc: t...@lists.fd.io; 
vpp-dev@lists.fd.io; Wang, Drenfong 
mailto:drenfong.w...@intel.com>>; ??? 
mailto:wangchuan...@huachentel.com>>; 
chen...@huachentel.com; 
lizhuo...@cmhi.chinamobile.com; ??? 
mailto:lihf...@chinaunicom.cn>>; 
zhijl@chinatelecom.cn; 
changlin...@nxp.com; Wang Tianyi 
mailto:tianyi.w...@tieto.com>>; davidfgao(?? 
mailto:davidf...@tencent.com>>; 
lixin...@huachentel.com; 
jingqing@alibaba-inc.com
Subject: Re: [tsc] Project Proposal for Sweetcomb

Hongjun,

Thank you for the proposal :)  Per the FD.io technical charter, all proposals 
must be out for public review for two weeks prior to approval by the TSC.  I 
believe this makes Nov 8 the earliest TSC meeting where we could approve at the 
TSC.  Would you like to schedule the project creation review for the Nov 8 8am 
PT TSC meeting?  Will you (or other proposers of the project) be able to make 
that time to present the proposal?

Ed

On Tue, Oct 23, 2018 at 7:01 AM Ni, Hongjun 
mailto:hongjun...@intel.com>> wrote:
Hello FD.io TSCs

Please accept this project proposal for Sweetcomb for consideration.
https://wiki.fd.io/view/Project_Proposals/Sweetcomb

This project has nine founding companies:
Intel, HuachenTel, China Mobile, China Unicom, China Telecom, NXP, Tieto, 
Tencent, Alibaba.

If possible, I would like to present this on TSC meeting.

Thanks,
Hongjun

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#856): https://lists.fd.io/g/tsc/message/856
Mute This Topic: https://lists.fd.io/mt/27567539/464962
Group Owner: tsc+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/tsc/unsub  
[hagb...@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10974): https://lists.fd.io/g/vpp-dev/message/10974
Mute This Topic: https://lists.fd.io/mt/27568384/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] Problem switching a bonded interface from L2 to L3 mode

2018-10-24 Thread saint_sun 孙 via Lists . Fd . Io

Ok, I forgot to click the reply-all. who is familiar with the problem I 
mentioned below please tell me,thanks!






2018年10月25日 星期四 +0800 10:32 发件人 John Lo (loj)  :
>Please include vpp-dev alias on any questions about VPP, instead of unicast an 
>individual only. Then whoever is familiar with the area
> you are asking about may respond.  Does anyone know about the potential 
> problem of switching between L2 and L3 modes on a bonded interface described 
> in this email (I did change the email subject accordingly)?   -John
> 
>From: saint_sun 孙 < saint_...@aliyun.com >
>Sent: Wednesday, October 24, 2018 8:52 PM
>To: John Lo (loj) < l...@cisco.com >
>Subject: Re: RE: RE: [vpp-dev]vlan interface support?
> 
>I am very grateful for your help. 
>And when I test the VLAN, maybe I find a bug that if I switch the mode of the 
>Bonding interface to L2 and then switch back to L3 , the bonding interface can 
>not work as before. 
>I have found the error code that is in the mode switch function of bonding 
>device: when set the mode of bonding interface to l2, all the members of the 
>bonding interface will be set to l2, but when set the bonding interface back, 
>all the
> members do not recover to l3.
> 
>At last I have another doubt that when I configure an IP address for an 
>interface, then I ping the address from VPP, it’s failed, why?should I do 
>other more settings?
> 
>
>
>2018 年 10 月 15 日 星期一 +0800 22:20  发件人 John Lo (loj) < l...@cisco.com >:
>>If there is a BVI in a BD with sub-interfaces in the same BD which get 
>>packets with VLAN tags, it is best
>> to configure a tag-rewrite operation on the sub-interfaces to pop their VLAN 
>> tags.  Then all packets are forwarded in BD without VLAN tags.  The CLI is 
>> “set interface l2 tag-rewrite  pop 1” if the sub-interface 
>> has one VLAN tag.    –John
>> 
>>From: saint_sun 孙 < saint_...@aliyun.com >
>>Sent: Monday, October 15, 2018 2:42 AM
>>To: John Lo (loj) < l...@cisco.com >
>>Cc: vpp-dev@lists.fd.io
>>Subject: Re: RE: [vpp-dev]vlan interface support?
>> 
>>I am very grateful to you for your advice !
>>I have tested it , But there is something wrong. when I receive an arp or 
>>ICMP packet from a l2 subif  that joins to bd 200 and encapsulates vlan 200 , 
>>the
>> reply packet that send from the subif does not have the vlan tag 200. Any 
>> more other configurations should I set ?
>> 
>>
>>
>>可用于 iOS 的 myMail 发送
>>
>>
>>2018 年 10 月 14 日 星期日 +0800 04:58  发件人 l...@cisco.com < l...@cisco.com >:
>>>The equivalent of VLAN on a switch in VPP is a bridge domain or BD for 
>>>short.  One
>>> can put interfaces or VLAN sub-interfaces in a BD to form a L2 network 
>>> among all interfaces in it.  One can also create a loopback interface, put 
>>> it in a BD as its BVI (Bridge Virtual Interface) and assign IP addresses to 
>>> it.  Then packet can be IP forwarded
>>> into a BD through its BVI.
>>> 
>>>Following is the VPP CLI sequence to create a loopback (resulting in 
>>>interface name
>>> loop0), put it in BD 13 as a BVI, and put an IP address on it:
>>> 
>>>loopback create mac 1a:2b:3c:4d:5e:6f
>>>set interface l2 bridge loop0 13 bvi
>>>set interface state loop0 up
>>>set interface ip address loop0 6.0.0.250/16
>>> 
>>>Regards,
>>>John
>>> 
>>>From: vpp-dev@lists.fd.io < vpp-dev@lists.fd.io > On Behalf Of  saint_sun ? 
>>>via Lists.Fd.Io
>>>Sent: Friday, October 12, 2018 3:52 AM
>>>To: vpp-dev@lists.fd.io
>>>Cc: vpp-dev@lists.fd.io
>>>Subject: [vpp-dev]vlan interface support?
>>> 
>>>I have a question:
>>>Does vpp has the function like the configuration example:
>>>interface f0/1
>>>switchport access vlan 10
>>> 
>>>Interface vlan 10
>>>ip address 10.0.0.1 255.255.255.0
>>> 
>>>If vpp has the function, where can I find the command and the source code?
>>> 
>>>Another question, does vpp support superVLAN?
>>> 
>>>anyone who knows please tell me, appreciate for your reply very much!
>>> -=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10976): https://lists.fd.io/g/vpp-dev/message/10976
Mute This Topic: https://lists.fd.io/mt/27628831/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] running VPP non-root broken

2018-10-24 Thread Stephen Hemminger
On Wed, 24 Oct 2018 21:07:15 +0200
Damjan Marion  wrote:

> > On 24 Oct 2018, at 20:41, Stephen Hemminger  
> > wrote:
> > 
> > On Wed, 24 Oct 2018 11:31:38 -0700
> > "Stephen Hemminger"  > > wrote:  
> 
> [snip]
> 
> > 
> > The problem is that the setup code decides to make 1 huge page. And since 
> > huge page size
> > on this system is 256M, DPDK can't even get stared.  
> 
> Already fixed in master... (hopefully works on Aarch64)
> 

Still broken, added some instrumentation to clib_sysfs_prealloc_hugepages
and got.

clib_sysfs_prealloc_hugepages:261: found log2=21 page_size=2048 n=0
clib_sysfs_prealloc_hugepages:264: pre-allocating 1 additional 2048K hugepages 
on numa node 0
clib_sysfs_set_nr_hugepages:158: set 
/sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages to 1

DPDK won't start with on 2M of memory.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10970): https://lists.fd.io/g/vpp-dev/message/10970
Mute This Topic: https://lists.fd.io/mt/27570325/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] running VPP non-root broken

2018-10-24 Thread Damjan Marion via Lists.Fd.Io


— 
Damjan

> On 24 Oct 2018, at 23:04, Stephen Hemminger  
> wrote:
> 
> On Wed, 24 Oct 2018 21:07:15 +0200
> Damjan Marion  wrote:
> 
>>> On 24 Oct 2018, at 20:41, Stephen Hemminger  
>>> wrote:
>>> 
>>> On Wed, 24 Oct 2018 11:31:38 -0700
>>> "Stephen Hemminger" >> > wrote:  
>> 
>> [snip]
>> 
>>> 
>>> The problem is that the setup code decides to make 1 huge page. And since 
>>> huge page size
>>> on this system is 256M, DPDK can't even get stared.  
>> 
>> Already fixed in master... (hopefully works on Aarch64)
>> 
> 
> Still broken, added some instrumentation to clib_sysfs_prealloc_hugepages
> and got.
> 
> clib_sysfs_prealloc_hugepages:261: found log2=21 page_size=2048 n=0
> clib_sysfs_prealloc_hugepages:264: pre-allocating 1 additional 2048K 
> hugepages on numa node 0
> clib_sysfs_set_nr_hugepages:158: set 
> /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages to 1
> 
> DPDK won't start with on 2M of memory.

Yeah, i already fixed that but it is not merged yet. This is just prealloc 
issue, if pages are preallocated everything should work ok.-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10971): https://lists.fd.io/g/vpp-dev/message/10971
Mute This Topic: https://lists.fd.io/mt/27570325/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] running VPP non-root broken

2018-10-24 Thread Sirshak Das
Yes this works on AArch64

From: Damjan Marion 
Sent: Wednesday, October 24, 2018 2:07 PM
To: Stephen Hemminger 
Cc: Sirshak Das ; Marco Varlese ; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] running VPP non-root broken




On 24 Oct 2018, at 20:41, Stephen Hemminger 
mailto:step...@networkplumber.org>> wrote:

On Wed, 24 Oct 2018 11:31:38 -0700
"Stephen Hemminger" 
mailto:step...@networkplumber.org>> wrote:

[snip]



The problem is that the setup code decides to make 1 huge page. And since huge 
page size
on this system is 256M, DPDK can't even get stared.

Already fixed in master... (hopefully works on Aarch64)

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.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10972): https://lists.fd.io/g/vpp-dev/message/10972
Mute This Topic: https://lists.fd.io/mt/27570325/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] #vpp

2018-10-24 Thread Yao, Chengqiang
Hi Macro,

Is there any sample code to show how to use SCTP (such as association, packet 
transmission/reception, etc.)? And is there any performance report for SCTP?



Best Regards,
Chengqiang Yao



From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Marco 
Varlese
Sent: Wednesday, October 10, 2018 5:47 PM
To: srivastava.rac...@gmail.com; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] #vpp

Hi Srivastava,

On Wed, 2018-10-10 at 01:23 -0700, 
srivastava.rac...@gmail.com wrote:
Hi

Does the VPP support SCTP. If yes what is the configuration for SCTP. Does it 
support the same features as the linux kernel SCTP ?
VPP has an implementation for SCTP. You can look into /src/vnet/sctp folder to 
see what we currently support in terms of RFC.
Any feedback (and contribution) is very much welcome!


Thanks
Rachit Srivastava
Thanks,
Marco


-=-=-=-=-=-=-=-=-=-=-=-

Links: You receive all messages sent to this group.



View/Reply Online (#10787): https://lists.fd.io/g/vpp-dev/message/10787

Mute This Topic: https://lists.fd.io/mt/27155313/675056

Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480704

Group Owner: vpp-dev+ow...@lists.fd.io

Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[mvarl...@suse.de]

-=-=-=-=-=-=-=-=-=-=-=-


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10978): https://lists.fd.io/g/vpp-dev/message/10978
Mute This Topic: https://lists.fd.io/mt/27155313/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[vpp-dev] Memory Performance issue #vpp

2018-10-24 Thread david . leitch . vpp
Hi,
 
I tested VPP performance for CGNAT in Deterministic mode; While VPP is working 
and has sessions, "show memory" command causes huge drop rates or when I want 
to add another deterministic mapping it takes long delay (for memory 
allocation) and again huge drop rate occurs that relate to memory allocation.
 
First, I thought drop rate was for main heap memory locking, so I changed 
source code and comment mheap_maybe_lock and mheap_maybe_unlock on mheap_usage 
command, but when the main heap is busy I have drop rate for incoming traffic. 
:(
 
Is it normal behavior Or it is performance problem for memory?
 
Thanks!
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10941): https://lists.fd.io/g/vpp-dev/message/10941
Mute This Topic: https://lists.fd.io/mt/27615950/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] PPPoE plugin documentation/support

2018-10-24 Thread Ni, Hongjun
Hi Alp Arslan,

Please see below slides for more details. There is some packet trace for your 
reference.

https://schd.ws/hosted_files/onsna18/cf/Accelerated%20Open%20Source%20vBRAS%20Solution%20Based%20on%20OpenBRAS%20and%20VPP%26DPDK.PPTX

Thanks,
Hongjun

-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of 
alp.ars...@xflowresearch.com
Sent: Wednesday, October 24, 2018 2:49 PM
To: Ni, Hongjun ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] PPPoE plugin documentation/support

Dell - Internal Use - Confidential  

Dear Hongjun, 

I was able to correctly set up the cp interface, my mistake as I was giving the 
wrong interface index. 
Now the PADI packets are passed to cp interface. 

I started a pppoe-server on the Linux side (tap0) interface, but VPP is 
dropping the PADO packets. 
Adding a trace on the virtio-input shows this: 

00:04:07:498195: virtio-input
  virtio: hw_if_index 2 next-index 4 vring 0 len 71
hdr: flags 0x00 gso_type 0x00 hdr_len 0 gso_size 0 csum_start 0 csum_offset 
0 num_buffers 1
00:04:07:498204: ethernet-input
  PPPOE_DISCOVERY: f6:a0:85:84:98:e6 -> 3c:fd:fe:25:e6:20
00:04:07:498209: error-drop
  ethernet-input: l3 mac mismatch

The destination MAC address belongs to the pppoe-client, that's connected to 
the 10G interface. However, VPP doesn't seem to know where to forward the PADO 
replies. 
Also there are no entries in the pppoe fib for this client. Can you please help 
me with this one? Please let me know if you need any more information. 

Regards,
Alp Arslan


-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Ni, Hongjun
Sent: Tuesday, October 23, 2018 1:07 PM
To: alp.ars...@xflowresearch.com; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] PPPoE plugin documentation/support

Hi Alp Arslan,

To make tap_cli work, you need to revert the code as per this patch:
https://gerrit.fd.io/r/#/c/9467/ 

Thanks,
Hongjun

-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of 
alp.ars...@xflowresearch.com
Sent: Tuesday, October 23, 2018 4:01 PM
To: Ni, Hongjun ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] PPPoE plugin documentation/support

Dell - Internal Use - Confidential  

Dear Hongjun, 

Thanks for the reply. 

I am using the VPP version 18.07. If the tap_cli is still present, can you 
please point me towards what could be the problem with the existing plugin. 
I would like to see this one working a little bit, before starting to look into 
tapv2.

Regards,
Alp Arslan

-Original Message-
From: Ni, Hongjun [mailto:hongjun...@intel.com]
Sent: Tuesday, October 23, 2018 12:51 PM
To: alp.ars...@xflowresearch.com; vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] PPPoE plugin documentation/support

Hi Alp Arslan,

Since tap_cli code is going to be deprecated in favour of tapv2.
I suggest you leverage tapv2, and also need some rework for PPPoE plugin.

Thanks,
Hongjun

-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of 
alp.ars...@xflowresearch.com
Sent: Tuesday, October 23, 2018 3:08 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] PPPoE plugin documentation/support

Dear All, 

I am trying to evaluate the support of pppoe in vpp. However, I am facing some 
issues, here is my startup conf file. 

unix {
  nodaemon
  log /var/log/vpp/vpp.log
  full-coredump
  cli-listen /run/vpp/cli.sock
  gid vpp
}
api-trace {
  on
}
api-segment {
  gid vpp
}
socksvr {
  default
}
cpu {
main-core 1
corelist-workers 2,4,3,5
}
dpdk {
dev :05:00.1
uio-driver vfio-pci
socket-mem 2048,2048
}
plugins {
plugin default { enable}
}
tuntap {
  enable
  ethernet
  name newtap
}

After that I run the following commands: 

vpp# set interface state TenGigabitEthernet5/0/1 up vpp# set interface state
local0 up

Now at this point if I try to connect from the pppoe client, I can see three 
PADI request reaching VPP, and VPP trying to forward them at local0 interface. 
To forward this traffic to the tap port instead, I use this command. 

vpp# create pppoe cp cp-if-index 2

The help and the documentation for this command show this "create pppoe cp 
if-name  [del]", which doesn't work.
Now at this moment, I was expecting the VPP to forward the PADI request to
tuntap-0 interface, but I don't see anything in the VPP counters, nor by using 
tcpdump on interface "newtap" which is the kernel facing side of "tuntap-0" 
interface. 

My question is, Is my approach correct? Are the PADI requests forwarded to the 
tuntap-0 interface? If not where do they go? I cannot find any good 
documentation on this anywhere. 
Any help regarding this would be highly appreciated. 

Regards,
Alp Arslan





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10942): https://lists.fd.io/g/vpp-dev/message/10942
Mute This Topic: https://lists.fd.io/mt/27566265/21656
Group Owner: 

Re: [vpp-dev] VPP cores out of vlib_worker_thread_barrier_sync_int()

2018-10-24 Thread siddarth rai
Hi All,

I found out that one of the worker threads is stuck at a place, thus
causing this issue:

*#0  0x2b95c2bcda2d in accept () from /lib64/libpthread.so.0*
*#1  0x2b9703e026c8 in vfio_mp_sync_thread (arg=)*
*#2  0x2b95c2bc6dd5 in start_thread () from /lib64/libpthread.so.0*
*#3  0x2b95c30ddb3d in clone () from /lib64/libc.so.6*

I see on my setup that these two drivers are loaded : vfio and
vfio_iommu_type1

Can anyone tell if this could be causing some issue? Would the issue go
away if I remove these?

Regards,
Siddarth

On Tue, Oct 23, 2018 at 4:22 PM siddarth rai  wrote:

> Hi all,
> I am facing occasional VPP crash from
> vlib_worker_thread_barrier_sync_int(). There was hardly any load on VPP
> when this happened
> I am using VPP version v18.01.1-100~g3a6948c.  Upgrading to a newer
> version is not an option for me currently.
>
> Here is the backtrace:
>
> *#0  0x2b95c3015207 in raise () from /lib64/libc.so.6*
> *#1  0x2b95c30168f8 in abort () from /lib64/libc.so.6*
> *#2  0x00405ef3 in os_panic ()*
> *at
> /bfs-build/build-area.47/builds/LinuxNBngp_mainline_RH7/2018-10-15-1924/third-party/vpp/vpp_1801/build-data/../src/vpp/vnet/main.c:268*
> *#3  0x2b95c111560a in vlib_worker_thread_barrier_sync_int
> (vm=0x2b95c1345260 )*
> *at
> /bfs-build/build-area.47/builds/LinuxNBngp_mainline_RH7/2018-10-15-1924/third-party/vpp/vpp_1801/build-data/../src/vlib/threads.c:1480*
> *#4  0x2b95c0e90d3a in vl_msg_api_handler_with_vm_node
> (am=0x2b95c10c14a0 , the_msg=0x3026f5ac, vm=0x2b95c1345260
> ,*
> *node=)*
> *at
> /bfs-build/build-area.47/builds/LinuxNBngp_mainline_RH7/2018-10-15-1924/third-party/vpp/vpp_1801/build-data/../src/vlibapi/api_shared.c:506*
> *#5  0x2b95c0ea02ec in memclnt_process (vm=0x2b95c1345260
> , node=0x2b95c607, f=)*
> *at
> /bfs-build/build-area.47/builds/LinuxNBngp_mainline_RH7/2018-10-15-1924/third-party/vpp/vpp_1801/build-data/../src/vlibmemory/memory_vlib.c:983*
> *#6  0x2b95c10f1656 in vlib_process_bootstrap (_a=)*
> *at
> /bfs-build/build-area.47/builds/LinuxNBngp_mainline_RH7/2018-10-15-1924/third-party/vpp/vpp_1801/build-data/../src/vlib/main.c:1231*
> *#7  0x2b95c245c838 in clib_calljmp ()*
> *at
> /bfs-build/build-area.47/builds/LinuxNBngp_mainline_RH7/2018-10-15-1924/third-party/vpp/vpp_1801/build-data/../src/vppinfra/longjmp.S:110*
> *#8  0x2b95c5edfe30 in ?? ()*
> *#9  0x2b95c10f2999 in vlib_process_startup (f=0x0, p=0x2b95c607,
> vm=0x2b95c1345260 )*
> *at
> /bfs-build/build-area.47/builds/LinuxNBngp_mainline_RH7/2018-10-15-1924/third-party/vpp/vpp_1801/build-data/../src/vlib/main.c:1253*
> *#10 dispatch_process (vm=0x2b95c1345260 ,
> p=0x2b95c607, last_time_stamp=39202939357732, f=0x0)*
> *at
> /bfs-build/build-area.47/builds/LinuxNBngp_mainline_RH7/2018-10-15-1924/third-party/vpp/vpp_1801/build-data/../src/vlib/main.c:1296*
> *#11 0x000c in ?? ()*
> *#12 0x0005000c in ?? ()*
> *#13 0x in ?? ()*
>
> Any help will be greatly appreciated.
>
> Regards,
> Siddarth
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10943): https://lists.fd.io/g/vpp-dev/message/10943
Mute This Topic: https://lists.fd.io/mt/27567149/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] Memory Performance issue #vpp

2018-10-24 Thread Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES@Cisco) via Lists.Fd.Io
Hi,

Deterministic NAT preallocate vector with 1000 session slots for each host from 
inside network range, so it will take some time  
https://wiki.fd.io/view/VPP/NAT#Memory_requirements

Matus


From: vpp-dev@lists.fd.io  On Behalf Of 
david.leitch@gmail.com
Sent: Wednesday, October 24, 2018 10:25 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Memory Performance issue #vpp

Hi,

I tested VPP performance for CGNAT in Deterministic mode; While VPP is working 
and has sessions, "show memory" command causes huge drop rates or when I want 
to add another deterministic mapping it takes long delay (for memory 
allocation) and again huge drop rate occurs that relate to memory allocation.

First, I thought drop rate was for main heap memory locking, so I changed 
source code and comment mheap_maybe_lock and mheap_maybe_unlock on mheap_usage 
command, but when the main heap is busy I have drop rate for incoming traffic. 
:(

Is it normal behavior Or it is performance problem for memory?

Thanks!
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10944): https://lists.fd.io/g/vpp-dev/message/10944
Mute This Topic: https://lists.fd.io/mt/27615950/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] Memory Performance issue #vpp

2018-10-24 Thread david . leitch . vpp
hi Matus

I know it will take some time when add new deterministic mapping.
But why "show memory" command has drop rate 
Or why adding new deterministic mapping cause drop rate

Thanks !
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10945): https://lists.fd.io/g/vpp-dev/message/10945
Mute This Topic: https://lists.fd.io/mt/27615950/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] [csit-dev] VPP 18.10 is out!!!

2018-10-24 Thread Jan Gelety via Lists.Fd.Io
Hello Macro,

Great and thanks for the info!

Unfortunately, vpp-ext-deps packages are missing there [0] - is it possible to 
fix it, please?

Thanks,
Jan

[0] https://packagecloud.io/app/fdio/release/search?q=vpp-ext-deps

-Original Message-
From: csit-...@lists.fd.io  On Behalf Of Marco Varlese
Sent: Wednesday, October 24, 2018 9:47 AM
To: vpp-dev@lists.fd.io; csit-...@lists.fd.io
Cc: t...@lists.fd.io
Subject: [csit-dev] VPP 18.10 is out!!!

Dear all,

I am very happy to announce that release 18.10 is available.

Release artificats can be found on both Nexus and Packagecloud.

Thanks to all contributors for yet another great release!


Cheers,
--
Marco V

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 
(AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10946): https://lists.fd.io/g/vpp-dev/message/10946
Mute This Topic: https://lists.fd.io/mt/27616092/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] [csit-dev] VPP 18.10 is out!!!

2018-10-24 Thread Marco Varlese
Hi Jan,

Yes, I already told Vanessa... I don't know why that RPM/DEB was not included in
the first place!


Cheers,
Marco

On Wed, 2018-10-24 at 08:59 +, Jan Gelety via Lists.Fd.Io wrote:
> Hello Macro,
> 
> Great and thanks for the info!
> 
> Unfortunately, vpp-ext-deps packages are missing there [0] - is it possible to
> fix it, please?
> 
> Thanks,
> Jan
> 
> [0] https://packagecloud.io/app/fdio/release/search?q=vpp-ext-deps
> 
> -Original Message-
> From: csit-...@lists.fd.io  On Behalf Of Marco Varlese
> Sent: Wednesday, October 24, 2018 9:47 AM
> To: vpp-dev@lists.fd.io; csit-...@lists.fd.io
> Cc: t...@lists.fd.io
> Subject: [csit-dev] VPP 18.10 is out!!!
> 
> Dear all,
> 
> I am very happy to announce that release 18.10 is available.
> 
> Release artificats can be found on both Nexus and Packagecloud.
> 
> Thanks to all contributors for yet another great release!
> 
> 
> Cheers,
> --
> Marco V
> 
> SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB
> 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#3141): https://lists.fd.io/g/csit-dev/message/3141
> Mute This Topic: https://lists.fd.io/mt/27615759/675056
> Group Owner: csit-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/csit-dev/unsubb  [mvarl...@suse.de]
> -=-=-=-=-=-=-=-=-=-=-=-
-- 
Marco V

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10947): https://lists.fd.io/g/vpp-dev/message/10947
Mute This Topic: https://lists.fd.io/mt/27616092/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] [csit-dev] VPP 18.10 is out!!!

2018-10-24 Thread Damjan Marion via Lists.Fd.Io

Why do you need that package, it is not end user package, it is just helper 
package for developers compiling vpp...

— 
Damjan

> On 24 Oct 2018, at 10:59, Jan Gelety via Lists.Fd.Io 
>  wrote:
> 
> Hello Macro,
> 
> Great and thanks for the info!
> 
> Unfortunately, vpp-ext-deps packages are missing there [0] - is it possible 
> to fix it, please?
> 
> Thanks,
> Jan
> 
> [0] https://packagecloud.io/app/fdio/release/search?q=vpp-ext-deps
> 
> -Original Message-
> From: csit-...@lists.fd.io  On Behalf Of Marco Varlese
> Sent: Wednesday, October 24, 2018 9:47 AM
> To: vpp-dev@lists.fd.io; csit-...@lists.fd.io
> Cc: t...@lists.fd.io
> Subject: [csit-dev] VPP 18.10 is out!!!
> 
> Dear all,
> 
> I am very happy to announce that release 18.10 is available.
> 
> Release artificats can be found on both Nexus and Packagecloud.
> 
> Thanks to all contributors for yet another great release!
> 
> 
> Cheers,
> --
> Marco V
> 
> SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 
> 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#3141): https://lists.fd.io/g/csit-dev/message/3141
> Mute This Topic: https://lists.fd.io/mt/27615759/675642
> Group Owner: csit-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/csit-dev/unsub  [dmar...@me.com]
> -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10948): https://lists.fd.io/g/vpp-dev/message/10948
Mute This Topic: https://lists.fd.io/mt/27616092/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] PPPoE plugin documentation/support

2018-10-24 Thread alp . arslan
Dell - Internal Use - Confidential  

Dear Hongjun, 

I was able to correctly set up the cp interface, my mistake as I was giving
the wrong interface index. 
Now the PADI packets are passed to cp interface. 

I started a pppoe-server on the Linux side (tap0) interface, but VPP is
dropping the PADO packets. 
Adding a trace on the virtio-input shows this: 

00:04:07:498195: virtio-input
  virtio: hw_if_index 2 next-index 4 vring 0 len 71
hdr: flags 0x00 gso_type 0x00 hdr_len 0 gso_size 0 csum_start 0
csum_offset 0 num_buffers 1
00:04:07:498204: ethernet-input
  PPPOE_DISCOVERY: f6:a0:85:84:98:e6 -> 3c:fd:fe:25:e6:20
00:04:07:498209: error-drop
  ethernet-input: l3 mac mismatch

The destination MAC address belongs to the pppoe-client, that's connected to
the 10G interface. However, VPP doesn't seem to know where to forward the
PADO replies. 
Also there are no entries in the pppoe fib for this client. Can you please
help me with this one? Please let me know if you need any more information. 

Regards, 
Alp Arslan


-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Ni,
Hongjun
Sent: Tuesday, October 23, 2018 1:07 PM
To: alp.ars...@xflowresearch.com; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] PPPoE plugin documentation/support

Hi Alp Arslan,

To make tap_cli work, you need to revert the code as per this patch:
https://gerrit.fd.io/r/#/c/9467/ 

Thanks,
Hongjun

-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of
alp.ars...@xflowresearch.com
Sent: Tuesday, October 23, 2018 4:01 PM
To: Ni, Hongjun ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] PPPoE plugin documentation/support

Dell - Internal Use - Confidential  

Dear Hongjun, 

Thanks for the reply. 

I am using the VPP version 18.07. If the tap_cli is still present, can you
please point me towards what could be the problem with the existing plugin. 
I would like to see this one working a little bit, before starting to look
into tapv2.

Regards,
Alp Arslan

-Original Message-
From: Ni, Hongjun [mailto:hongjun...@intel.com]
Sent: Tuesday, October 23, 2018 12:51 PM
To: alp.ars...@xflowresearch.com; vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] PPPoE plugin documentation/support

Hi Alp Arslan,

Since tap_cli code is going to be deprecated in favour of tapv2.
I suggest you leverage tapv2, and also need some rework for PPPoE plugin.

Thanks,
Hongjun

-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of
alp.ars...@xflowresearch.com
Sent: Tuesday, October 23, 2018 3:08 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] PPPoE plugin documentation/support

Dear All, 

I am trying to evaluate the support of pppoe in vpp. However, I am facing
some issues, here is my startup conf file. 

unix {
  nodaemon
  log /var/log/vpp/vpp.log
  full-coredump
  cli-listen /run/vpp/cli.sock
  gid vpp
}
api-trace {
  on
}
api-segment {
  gid vpp
}
socksvr {
  default
}
cpu {
main-core 1
corelist-workers 2,4,3,5
}
dpdk {
dev :05:00.1
uio-driver vfio-pci
socket-mem 2048,2048
}
plugins {
plugin default { enable}
}
tuntap {
  enable
  ethernet
  name newtap
}

After that I run the following commands: 

vpp# set interface state TenGigabitEthernet5/0/1 up vpp# set interface state
local0 up

Now at this point if I try to connect from the pppoe client, I can see three
PADI request reaching VPP, and VPP trying to forward them at local0
interface. 
To forward this traffic to the tap port instead, I use this command. 

vpp# create pppoe cp cp-if-index 2

The help and the documentation for this command show this "create pppoe cp
if-name  [del]", which doesn't work.
Now at this moment, I was expecting the VPP to forward the PADI request to
tuntap-0 interface, but I don't see anything in the VPP counters, nor by
using tcpdump on interface "newtap" which is the kernel facing side of
"tuntap-0" interface. 

My question is, Is my approach correct? Are the PADI requests forwarded to
the tuntap-0 interface? If not where do they go? I cannot find any good
documentation on this anywhere. 
Any help regarding this would be highly appreciated. 

Regards,
Alp Arslan





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10936): https://lists.fd.io/g/vpp-dev/message/10936
Mute This Topic: https://lists.fd.io/mt/27566265/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[vpp-dev] VPP 18.10 is out!!!

2018-10-24 Thread Marco Varlese
Dear all,

I am very happy to announce that release 18.10 is available.

Release artificats can be found on both Nexus and Packagecloud.

Thanks to all contributors for yet another great release!


Cheers,
-- 
Marco V

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10938): https://lists.fd.io/g/vpp-dev/message/10938
Mute This Topic: https://lists.fd.io/mt/27615761/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] running VPP non-root broken

2018-10-24 Thread Damjan Marion via Lists.Fd.Io

Can you share your startup config in both cases (if different)?

-- 
Damjan

> On 24 Oct 2018, at 06:12, Lee Roberts  wrote:
> 
> Damjan,
>  
> In my case, we have a four-socket Skylake server filled with 2x25GbE NICs and
> encryption accelerators---trying to see how much IPsec throughput we can 
> manage.
>  
> Recently saw a ~50% performance increase by changing from 2MB hugepages (8192 
> pages)
> to 1GB hugepages (16 pages) with VPP 18.04 on Ubuntu 16.04 (4.4.0 kernel).
>  
> -Lee
>  
>  
> From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Damjan 
> Marion via Lists.Fd.Io
> Sent: Tuesday, October 23, 2018 4:05 PM
> To: Roberts, Lee A. 
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] running VPP non-root broken
>  
>  
> I submitted patch
>  
> Just for my curiosity what is the use case for allocating >=2 GB of wired 
> memory?
> I thought nobody wants to do that so i did not pay attention.
> 
> — 
> Damjan
> 
> On 23 Oct 2018, at 21:00, Lee Roberts  > wrote:
> 
> In the following code, take a close look at line #61:
>  
> 
>  
>  
> Back in VPP 18.01.1, we had a similar problem---see VPP-1168 
> (https://jira.fd.io/browse/VPP-1168 ).
> One needs to be sure the left shift doesn’t lose high-order bits.  You may 
> need to explicitly
> cast “i” to be unsigned-64 before left-shifting it:
>  
>   uword pa = clib_pmalloc_get_pa (pm, (u8 *) va + ((u64)i << 
> a->log2_page_sz));
>  
>  
> -Lee Roberts
>  
>  
>  
> From: vpp-dev@lists.fd.io  
> [mailto:vpp-dev@lists.fd.io ] On Behalf Of 
> Sirshak Das
> Sent: Tuesday, October 23, 2018 12:45 PM
> To: dmar...@me.com ; vpp-dev  >
> Cc: Honnappa Nagarahalli  >; Lijian Zhang (Arm Technology China) 
> mailto:lijian.zh...@arm.com>>; khemendra kumar 
> mailto:khemendra.kuma...@gmail.com>>; Juraj 
> Linkeš mailto:juraj.lin...@pantheon.tech>>
> Subject: Re: [vpp-dev] running VPP non-root broken
>  
> Hi Damjan,
>  
> I am getting the following error as well I don’t know if its related to this 
> issue:
> vlib_plugin_early_init:361: plugin path 
> /home/sirdas/code/commita/vpp/build-root/install-vpp-native/vpp/lib/vpp_plugins
> load_one_plugin:117: Plugin disabled (default): abf_plugin.so
> load_one_plugin:117: Plugin disabled (default): acl_plugin.so
> load_one_plugin:117: Plugin disabled (default): avf_plugin.so
> load_one_plugin:117: Plugin disabled (default): cdp_plugin.so
> load_one_plugin:189: Loaded plugin: dpdk_plugin.so (Data Plane Development 
> Kit (DPDK))
> load_one_plugin:117: Plugin disabled (default): flowprobe_plugin.so
> load_one_plugin:117: Plugin disabled (default): gbp_plugin.so
> load_one_plugin:117: Plugin disabled (default): gtpu_plugin.so
> load_one_plugin:117: Plugin disabled (default): igmp_plugin.so
> load_one_plugin:117: Plugin disabled (default): ila_plugin.so
> load_one_plugin:117: Plugin disabled (default): ioam_plugin.so
> load_one_plugin:117: Plugin disabled (default): ixge_plugin.so
> load_one_plugin:117: Plugin disabled (default): l2e_plugin.so
> load_one_plugin:117: Plugin disabled (default): lacp_plugin.so
> load_one_plugin:117: Plugin disabled (default): lb_plugin.so
> load_one_plugin:117: Plugin disabled (default): mactime_plugin.so
> load_one_plugin:117: Plugin disabled (default): map_plugin.so
> load_one_plugin:117: Plugin disabled (default): memif_plugin.so
> load_one_plugin:117: Plugin disabled (default): nat_plugin.so
> load_one_plugin:117: Plugin disabled (default): nsh_plugin.so
> load_one_plugin:117: Plugin disabled (default): nsim_plugin.so
> load_one_plugin:117: Plugin disabled (default): perfmon_plugin.so
> load_one_plugin:117: Plugin disabled (default): pppoe_plugin.so
> load_one_plugin:117: Plugin disabled (default): srv6ad_plugin.so
> load_one_plugin:117: Plugin disabled (default): srv6am_plugin.so
> load_one_plugin:117: Plugin disabled (default): srv6as_plugin.so
> load_one_plugin:117: Plugin disabled (default): stn_plugin.so
> load_one_plugin:117: Plugin disabled (default): svs_plugin.so
> load_one_plugin:117: Plugin disabled (default): tlsmbedtls_plugin.so
> load_one_plugin:117: Plugin disabled (default): tlsopenssl_plugin.so
> load_one_plugin:117: Plugin disabled (default): unittest_plugin.so
> load_one_plugin:117: Plugin disabled (default): vmxnet3_plugin.so
> clib_elf_parse_file: open `linux-vdso.so.1': No such file or directory
> load_one_vat_plugin:67: Loaded plugin: lb_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: gtpu_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: memif_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: nsh_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: nsim_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: avf_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: vmxnet3_test_plugin.so
>