Re: [EXTERNAL] [vpp-dev] Coverity errors nag-o-gram

[Chris Luke via lists.fd.io]

And in case it’s not obvious, the scanning tool had a holiday hiatus, but I got 
it back on its feet a week or so ago.

Chris.

From: vpp-dev@lists.fd.io  on behalf of Ole Troan 

Date: Tuesday, January 18, 2022 at 06:16
To: Neale Ranns , Pablo Camarillo (pcamaril) 
, Radu Nicolau , Steven Luong 
(sluong) , tetsuya@gmail.com , 
hongjun...@intel.com , Andrew Yourtchenko 
, Mohsin Kazmi (sykazmi) , Damjan Marion 
, moham...@hawari.fr , 
satoru.matsush...@gmail.com , j...@netgate.com 
, Roy Fan Zhang 
Cc: vpp-dev 
Subject: [EXTERNAL] [vpp-dev] Coverity errors nag-o-gram
Guys, can we do a little effort here. Those of you in the To: field, you know 
what to do.

https://urldefense.com/v3/__https://github.com/vpp-dev/vpp-coverity-report__;!!CQl3mcHX2A!VD9Z5KHMIzmZ9lHiLYQBKY73N56grRVrtJzl_cwu0oTktr9tgfeQgqWav_mi4bjFwQ$

Best regards,
Ole

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20745): https://lists.fd.io/g/vpp-dev/message/20745
Mute This Topic: https://lists.fd.io/mt/88508258/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [EXTERNAL] Re: [vpp-dev] Multi-threading locks and synchronization

[Chris Luke via lists.fd.io]

Really depends on what you need it to do, which I may have missed. Why do you 
need any synchronization at all?

Chris


From: vpp-dev@lists.fd.io  on behalf of satish amara 

Date: Monday, July 12, 2021 at 23:59
To: vpp-dev@lists.fd.io 
Subject: Re: [EXTERNAL] Re: [vpp-dev] Multi-threading locks and synchronization
Thank you for your explanation.  What is recommended way if a custom plugin is 
working on multiple threads. Direct the packet in the same flow to the same 
thread or use spinlocks for synchronization. It looks like for IPSEC VPP code 
is trying the process the packets on the same flow on the same thread.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19754): https://lists.fd.io/g/vpp-dev/message/19754
Mute This Topic: https://lists.fd.io/mt/84165477/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [EXTERNAL] Re: [vpp-dev] Multi-threading locks and synchronization

[Chris Luke via lists.fd.io]

Grossly simplified explanation: Because of how VPP works, all packets are 
processed to completion on every vector (there may be exceptions, but it’s not 
typical, VPP really does not want to hang on to packets across cycles). Once a 
vector has been completed, there’s a barrier lock to allow main thread 
operations on worker thread data structures (such as collecting counters), and 
once those are complete the barrier is lifted and the next vector ingested. Not 
all main thread operations happen on every barrier, and naturally given the 
time sensitive nature all that code is carefully vetted. It may seem like an 
inefficient way, but it avoids a lot of locking – and especially checking for 
locks.

Thus “flushed” is the wrong perspective; there is no flushing when everything 
is processed to completion anyway.

Chris.

From: vpp-dev@lists.fd.io  on behalf of satish amara 

Date: Monday, July 12, 2021 at 16:48
To: Damjan Marion , vpp-dev@lists.fd.io 
Subject: [EXTERNAL] Re: [vpp-dev] Multi-threading locks and synchronization
"Interfaces are created/deleted under the barrier so there is not packets in 
flight."
Can you please add more details?  I just gave a scenario. In general, this is 
applicable to all meta fields  /Opaque fields. How are handling the outdated 
meta fields in packets due to config changes?  Does this mean all the packets 
need to be flushed out or processed before the new config is applied?

On Mon, Jul 12, 2021 at 11:04 AM Damjan Marion 
mailto:dmar...@me.com>> wrote:

On 11.07.2021., at 17:10, satish amara 
mailto:satishkam...@gmail.com>> wrote:


[Edited Message Follows]
Hi,
   I have a few questions about how synchronization is being done when there 
are multiple workers/threads accessing the same data structure.
For example, IPsec headers have a seq number that gets incremented.
If we have IPsec flow and encrypting packets on VPP do we assume that packets 
in the same flow go to the same core for encryption?

Yes, we handoff all packets to the owning thread. For fat flows we have crypto 
scheduler which offloads crypto operations to the multiple cores
but order is still maintained by the owning thread.


In IP lookup will find the adjacency and store it in the Opaque field.. Send to 
another node to rewrite. Before the packet gets processed in the next node if 
the interface is removed from the forwarding table. What will happen?   Lots of 
info being stored in Opaque fields for a couple of features. How the code is 
making sure changes in the config data are taken care of when the packets are 
still being processed by intermediate nodes in the graph.

Interfaces are created/deleted under the barrier so there is not packets in 
flight.

—
Damjan


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19749): https://lists.fd.io/g/vpp-dev/message/19749
Mute This Topic: https://lists.fd.io/mt/84165477/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [EXTERNAL] Re: [vpp-dev] VPP Emacs Lisp evolution to P4

[Chris Luke via lists.fd.io]

Hi Hemant,

Do you plan to open source and maintain this code generator?

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of hemant via 
lists.fd.io
Sent: Wednesday, May 5, 2021 12:09
To: hem...@mnkcg.com; vpp-dev@lists.fd.io
Subject: [EXTERNAL] Re: [vpp-dev] VPP Emacs Lisp evolution to P4


I don't know why the email I sent earlier did not show up as text. Resending.



[If you didn’t read this recent short blog I wrote, 
https://mnkcg.com/need-for-a-p4tovpp-compiler/, this is what the first 
paragraph of the blog says.



“VPP has stellar data plane code open-sourced by Cisco as a FD.io Linux 
project.  Now VPP runs crypto on latest Intel server hardware at 1 Tbps.  Most 
VPP new features are implemented as a plugin.  VPP provides a script using 
Emacs Lisp to generate a plugin’s stub code.  The generated code includes API 
and CLI to enable-disable plugin.  MNK Labs & Consulting saw a need to generate 
a complete VPP plugin – this would cause less bugs with new plugin and also 
accelerate VPP plugin development. Emacs Lisp is not the right tool to generate 
a full VPP plugin including data plane code.  MNK saw P4 as a good fit to 
describe any data plane and used P4 to generate a VPP plugin.”



I have proved my point by generating a 5G UPF plugin using the compiler. ]



Hemant



-Original Message-
From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of hemant via 
lists.fd.io
Sent: Wednesday, May 05, 2021 10:47 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP Emacs Lisp evolution to P4









-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19349): https://lists.fd.io/g/vpp-dev/message/19349
Mute This Topic: https://lists.fd.io/mt/82610223/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [EXTERNAL] Re: [vpp-dev] vpp hang on

[Chris Luke via lists.fd.io]

As Andrew says, vppctl is not ideal for this purpose.

Your GDB trace looks like it was vppctl itself, and it's stuck waiting on 
connect() - which means the far end, VPP, did not accept() the connection. My 
immediate reaction would be to check netstat to see if there's lots of old unix 
sockets still connected to the CLI endpoint.

But digging deeper, we should note that ping is in some regards special in the 
way it handles the CLI session compared to other CLI comments, because it wants 
to solicit input to interrupt a long-running ping. All of the CLI interaction - 
input and output - is in the main thread and each ping runs synchronously in 
that thread, if I remember correctly. Did I read that you run pings to 50 
different destinations every 5 seconds? Are those 50 dispatched in parallel? I 
think you'll be hitting contention for the main thread if so; while it's 
pinging it's not accepting connections. If several of your destinations are not 
reachable then you'll be waiting on several ping timeouts before any accept() 
happens.

Chris.


-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Andrew Yourtchenko
Sent: Thursday, April 8, 2021 11:18
To: yichanglui 
Cc: vpp-dev@lists.fd.io
Subject: [EXTERNAL] Re: [vpp-dev] vpp hang on

Hi,

first, a general comment: the vpp ping was aimed only for quick 
connectivity/diagnostic checks, not for continuous monitoring; and probably 
especially not using vppctl - since that involves a lot of overhead.

There are a few options:

1) Before the commit 34716fae918750e4fc7a7da4b06e0dfbdef2d1c5, there was code 
that performed the monitoring of targets on an ongoing basis.
You could probably take a look at that code and build something that is a bit 
more scalable and is more lightweight - and then upstream it as a separate 
plugin, provided you are happy to become a maintainer.

2) worst case, have a daemon that connects to VPP over the API and issues the 
commands using the cli_inband; maybe even adding an API call to ping plugin, 
such that you did not have the parse the commands.

That said, we should narrow down the issue that you are observing with the CLI, 
since regardless of how many times you do vppctl there should be no problem. 
Even if your version 19.08 is no longer receiving fixes, it's worth 
understanding what the problem is.

Were you able to reproduce the issue in your lab environment ?

--a


On 4/8/21, yichanglui  wrote:
> hi
>
> We are going to use "vppctl ping " to detect whether the device is
> reacehable, but we have some problem below :
>
>
>
>
> we have above 50 service to do "vppctl ping 100.100.0.x repeat 1
> table-id x " detect different devices,  each service exec this command
> per 5 second, after 3~4 days,  all vppctl ping service hang on,  we
> use gdb to debug , vppctl are hang on below point at
> src\vppinfra\socket.c: clib_socket_init
>
>
>
>
> ==
>
>
>
>
> 416  if (addr.sa.sa_family == PF_INET)
> (gdb)
> 419  if (s->flags & CLIB_SOCKET_F_IS_SERVER)
> (gdb)
> 497  if ((s->flags & CLIB_SOCKET_F_NON_BLOCKING_CONNECT)
> (gdb)
> 505  if (connect (s->fd, , addr_len) < 0
>
>
> ==
>
> it may cause some error on vpp socket  , when vppctl connect to vpp
> many times.
>
>
>
>
> our vpp version is below,
>
> =
>
> Version:  v19.08.1-229~g1517d5e72-dirty
> Compiled by:  root
> Compile host: i-qvoo7mp3
> Compile date: Fri Nov  1 20:53:55 CST 2019
> Compile location: /root/ws/vpp
> Compiler: GCC 7.5.0
> Current PID:  4652
>
> =
>
>
> Linux version is below:
>
>
> Linux version 4.15.0-112-generic (buildd@lcy01-amd64-027) (gcc version
> 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #113-Ubuntu SMP Thu Jul 9
> 23:41:39 UTC 2020
>
>
>
>
> On the other hander,  Is any other better method to do network health
> detection , like one-arm-echo bfd? because we may detect the device
> that not support bfd.
>
>
>
>
>
>
>
>
>
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19159): https://lists.fd.io/g/vpp-dev/message/19159
Mute This Topic: https://lists.fd.io/mt/81946650/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [EXTERNAL] [vpp-dev] New Committer Proposal

[Chris Luke via lists.fd.io]

+1

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
lists.fd.io
Sent: Wednesday, March 31, 2021 13:58
To: vpp-dev 
Cc: Zhang, Roy Fan 
Subject: [EXTERNAL] [vpp-dev] New Committer Proposal


Dear VPP Committers,

I would like to propose Roy Fan Zhang from Intel as a new VPP committer.
Fan made significant contributions to the VPP including the async crypto 
infrastructure and crypto scheduler.
Beside that I found that Fan is active in the community, and willing to help.

Please let me know if you agree/neutral/disagree with +1/0/-1 (committers only 
please).

My +1 is here.

Thanks,

Damjan


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19075): https://lists.fd.io/g/vpp-dev/message/19075
Mute This Topic: https://lists.fd.io/mt/81758204/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [EXTERNAL] Re: [vpp-dev] Issue with cloning repo on VM

[Chris Luke via lists.fd.io]

Rajesh,

It looks like a local system issue, nothing to do with git or gerrit per se.

Your system is tell you it’s not letting you create that file. You should 
investigate that. I believe it’s out of scope for this list I’m afraid.

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of Rajesh Dawadi via 
lists.fd.io
Sent: Sunday, February 21, 2021 09:19
To: vpp-dev@lists.fd.io; vpp-dev-inter...@cisco.com
Subject: [EXTERNAL] Re: [vpp-dev] Issue with cloning repo on VM

Hi, Has anyone faced similar issues when trying to clone on an Ubuntu VM? All 
the options suggested on google search didnt work, both https and ssh clone 
didnt work even after adding a new ssh public key.
Thanks,
Rajesh

On Sunday, February 14, 2021, 2:54:15 p.m. EST, Rajesh Dawadi 
mailto:dwdraj...@yahoo.com>> wrote:


Hi,
I am trying to setup the VPP repo on a Ubuntu VM running on MAC host and was 
trying to follow the steps mentioned here for "Pulling code via authenticated 
https": 
https://wiki.fd.io/view/VPP/Pulling,_Building,_Running,_Hacking_and_Pushing_VPP_Code

 However, I face 2 issues with both authenticated and the anonymous cloning 
with git.
1. git clone fails with error " git clone 
https://gerrit.fd.io/r/vpp
Cloning into 'vpp'...
remote: Counting objects: 93, done
fatal: Unable to create temporary file 
'/home/rajesh/vpp_ubuntu/repo/vpp/.git/objects/pack/tmp_pack_XX': Operation 
not permitted
fatal: index-pack failed" .
I tried to add chmod on the .git directory but it didn't help.

2. With authenticated https, it fails at the authentication step itself, even 
though the same username/password credential works for the Linux Foundation 
account at:
git clone 
https://dwdraj...@gerrit.fd.io/r/a/vpp
Cloning into 'vpp'...
Password for 'https://dwdraj...@gerrit.fd.io': 

remote: Unauthorized
fatal: Authentication failed for 
'https://gerrit.fd.io/r/a/vpp/'"

Any one faced similar issue with Ubuntu VM on MAC ?
Thanks a lot ,
Rajesh
"

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18777): https://lists.fd.io/g/vpp-dev/message/18777
Mute This Topic: https://lists.fd.io/mt/80803544/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [EXTERNAL] [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

[Chris Luke via lists.fd.io]

+1

I used to do this manually, in effect, though I’ve been less active the past 
while which probably accounts for the growth!

FWIW, I usually performed it on an approximate 60 day nudge and 90 day abandon, 
about once a month, schedule. I did similar with JIRA but less frequently. I 
felt the warning of impending abandonment important enough to make the effort 
to do it, though my recollection suggests that in one case did it actually 
result in a proposal being revived.

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of Dave Wallace
Sent: Wednesday, January 27, 2021 16:50
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP 
master

Folks,

There are currently 636 open Gerrit Reviews on VPP master [0], the oldest being 
submitted on Jun 13, 2016 [1]!

I would like to propose that the Gerrit Review Auto-Abandon job [2] to reduce 
the size of the queue to a more reasonable length. Benefits include (from [3]):

- %< -
Abandoning old inactive changes has the following advantages:

it signals change authors that changes are considered outdated

it keeps dashboards clean

it reduces the load on the server (for open changes the mergeability flag 
is recomputed whenever a change is merged)

If a change is still wanted it can be restored by clicking on the Restore 
button.
- %< -

I would like to propose the following configuration [2] for auto-abandon:

changeCleanup.abandonAfter: 30d
changeCleanup.abandonIfMergeable:   default (true)
changeCleanup.cleanupAccountPatchReview:default (false)
changeCleanup.abandonMessage:   default
changeCleanup.startTime:Sat 00:00
changeCleanup.interval: 1 day

If you are opposed to the use of Auto-abandon, please propose an alternative 
method to clean up the backlog of reviews on VPP master and maintain a 
reasonably sized queue.
If you approve of the concept, please respond with a +1.
If you approve of the concept but don't like the configuration, please respond 
with your preferred configuration.

Lack of response will be interpreted as approval of the use of auto-abandon 
with the proposed configuration ;)

Thanks,
-daw-

[0] dwallacelf@daw-server-2:~$ ssh -p 29418 gerrit.fd.io gerrit query 
status:open project:vpp branch:master --format=JSON --no-limit | tail -1
{"type":"stats","rowCount":636,"runTimeMilliseconds":1467,"moreChanges":false}
[1] 
https://gerrit.fd.io/r/c/vpp/+/1529
[2] 
https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#changeCleanup
[3] 
https://gerrit-review.googlesource.com/Documentation/user-change-cleanup.html#auto-abandon

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18611): https://lists.fd.io/g/vpp-dev/message/18611
Mute This Topic: https://lists.fd.io/mt/80171630/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [EXTERNAL] [vpp-dev] Check running status of vpp

[Chris Luke via lists.fd.io]

It is odd that the filesystem entry for the CLI socket would exist but it says 
“connection refused”. Any log messages from VPP complaining about not being 
able to create the socket? I wonder if the filesystem entry is a remnant from a 
previous session that was not cleaned up.

Chris.


From: vpp-dev@lists.fd.io  On Behalf Of 
ashish.sax...@hsc.com
Sent: Tuesday, December 15, 2020 23:29
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] [vpp-dev] Check running status of vpp

Hi All,

I am using VPP version 20.05.1 on my setup and my application is running vppctl 
commands after checking that VPP process is created , but sometimes it happens 
that though vpp process is created and vpp is running, still vpp doesn't accept 
any vppctl commands and is giving this error:
connect (fd 3, '/run/vpp/cli.sock'): Connection refused

Is there any way we can check from the application code that vpp is up and 
running and ready to accept vppctl commands?
Thanks and Regards,
Ashish

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18359): https://lists.fd.io/g/vpp-dev/message/18359
Mute This Topic: https://lists.fd.io/mt/79001336/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [EXTERNAL] Re: [vpp-dev] vppctl fails from within the application (system cmd returns 256)

[Chris Luke via lists.fd.io]

On this line in the trace:

[pid 2536742] socket(AF_UNIX, SOCK_STREAM, 0) = 0

It says it’s returning file descriptor 0 for the socket. Similarly other file 
opens and subsequent closes are using descriptor 0. 0 is normally stdin. Are 
stdin & out closed? That could cause all kinds of strange issues, especially 
when it tries to print the results to a closed stdout descriptor.

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of Aniket Pugaonkar
Sent: Tuesday, November 17, 2020 17:04
To: Benoit Ganne (bganne) 
Cc: vpp-dev@lists.fd.io
Subject: [EXTERNAL] Re: [vpp-dev] vppctl fails from within the application 
(system cmd returns 256)

sorry, forgot to reply-all

Hi Ben,

When i use the same command in sample test application (just int main()..) they 
work fine. but when I add them in my multithreaded application, it does not 
work.  Please see below Strace output of the application.   even fully 
specifying path to vppctl and cli.sock is not working

since it is multithreaded, the main process creates the app (vppcom_app_create).
another thread configures the interfaces using the CLI (vppctl) - which is 
failing these commands
one thread is using VCL to receive, another thread is using VCL to transmit.
before VCL Rx and Tx threads are started, configuration thread tries to 
configure the VPP interface using the CLI.

We ran into issues while making this application (that uses VCL)  work with 
another application that used VAPI to configure VPP, and had to revert back the 
code to vpp cli for other application.

commands that fail from my multithreaded application:
 /usr/bin/vppctl -s /run/vpp/cli.sock  create sub-interfaces 
HundredGigabitEthernet12/0/0 701
 /usr/bin/vppctl -s /run/vpp/cli.sock set interface state 
HundredGigabitEthernet12/0/0 up
 /usr/bin/vppctl -s /run/vpp/cli.sock set interface state 
HundredGigabitEthernet12/0/0.701up
/usr/bin/vppctl -s /run/vpp/cli.sock  set interface ip address 
HundredGigabitEthernet12/0/0.701 fd0d:1:2:cc:a5a5:301f:fe3a:a5a5/64



[pid 2536742] rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, sa_mask=[], 
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fbced84f790}, 
{sa_handler=0x55ee9d32d180, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, 
sa_restorer=0x7fbced84f790}, 8) = 0
[pid 2536742] execve("/usr/bin/vppctl", ["/usr/bin/vppctl", "-s", 
"/run/vpp/cli.sock", "ip", "mroute", "add", "ff38:23:2001:5b0:2000::3002/128", 
"via", "tuntap-0", "Accept"], 0x55ee9ead72c0 /* 27 vars */) = 0
[pid 2536742] brk(NULL) = 0x55fce62d4000
[pid 2536742] arch_prctl(0x3001 /* ARCH_??? */, 0x7ffc94d85710) = -1 EINVAL 
(Invalid argument)
[pid 2536742] access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or 
directory)
[pid 2536742] openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 0
[pid 2536742] fstat(0, {st_mode=S_IFREG|0644, st_size=62967, ...}) = 0
[pid 2536742] mmap(NULL, 62967, PROT_READ, MAP_PRIVATE, 0, 0) = 0x7ffb8ce4f000
[pid 2536742] close(0)  = 0
[pid 2536742] openat(AT_FDCWD, "/lib64/libvppinfra.so.20.05.1", 
O_RDONLY|O_CLOEXEC) = 0
[pid 2536742] read(0, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\230\0\0\0\0\0\0"..., 832) = 832
[pid 2536742] fstat(0, {st_mode=S_IFREG|0755, st_size=509240, ...}) = 0
[pid 2536742] mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 
-1, 0) = 0x7ffb8ce4d000
[pid 2536742] mmap(NULL, 2603336, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0x7ffb8c9bb000
[pid 2536742] mprotect(0x7ffb8ca35000, 2093056, PROT_NONE) = 0
[pid 2536742] mmap(0x7ffb8cc34000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 0, 0x79000) = 0x7ffb8cc34000
[pid 2536742] mmap(0x7ffb8cc36000, 2376, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ffb8cc36000
[pid 2536742] close(0)  = 0
[pid 2536742] openat(AT_FDCWD, "/lib64/libm.so.6", O_RDONLY|O_CLOEXEC) = 0
[pid 2536742] read(0, 
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\305\0\0\0\0\0\0"..., 832) = 
832
[pid 2536742] fstat(0, {st_mode=S_IFREG|0755, st_size=2714928, ...}) = 0
[pid 2536742] mmap(NULL, 3674432, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0x7ffb8c639000
[pid 2536742] mprotect(0x7ffb8c7ba000, 2093056, PROT_NONE) = 0
[pid 2536742] mmap(0x7ffb8c9b9000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 0, 0x18) = 0x7ffb8c9b9000
[pid 2536742] close(0)  = 0
[pid 2536742] openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 0
[pid 2536742] read(0, 
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2607\2\0\0\0\0\0"..., 832) = 832
[pid 2536742] fstat(0, {st_mode=S_IFREG|0755, st_size=4176104, ...}) = 0
[pid 2536742] mmap(NULL, 3938144, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0x7ffb8c277000
[pid 2536742] mprotect(0x7ffb8c43, 2093056, PROT_NONE) = 0
[pid 2536742] mmap(0x7ffb8c62f000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 0, 0x1b8000) = 0x7ffb8c62f000
[pid 2536742] mmap(0x7ffb8c635000, 14176, 

Re: [EXTERNAL] [vpp-dev] vppctl fails from within the application (system cmd returns 256)

[Chris Luke via lists.fd.io]

Is vppctl in the system path? Otherwise fully specify the path to the vppctl 
binary in those system calls.

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of Aniket Pugaonkar
Sent: Monday, November 16, 2020 12:41
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] [vpp-dev] vppctl fails from within the application (system 
cmd returns 256)

Hi,

i am having a issue with VPP running on RH8.2 with version 20.05.1.

There are 4 commands that I am trying to run from my application (using 
vppcli), fairly straight forward.  the Trace.Writeline function is just a 
utility to print out the trace.

what I see is the ret val is 256 indicating system command did not get executed 
properly. however  the same command when i type it manually , works perfectly 
fine.. Not sure what is wrong. I am logged in as root and running the process 
using "./a.out"  (manually) as a root.

Could anyone suggest anything else to check apart from switching to VPP API to 
configure interfaces/add routes etc? we had few issues with vpp api/vcl 
libraries and have not decided to pursue vpp - api for now, so vppctl is the 
only option. Alternative is to write a ipaddr.txt file and put it in 
startup.conf  -> which will do the trick. However I want to do it from 
application.   is there special flag in vpp.log to enable that can give 
information. i could not find anything useful in vpp.log

string s1("vppctl create sub-interfaces HundredGigabitEthernet12/0/1 
501");
string s2("vppctl set interface state HundredGigabitEthernet12/0/1 up");
string s3("vppctl set interface state HundredGigabitEthernet12/0/1.501 
up");
string s4("vppctl set interface ip address 
HundredGigabitEthernet12/0/1.501 2001:5b0::501:b883:31f:19e:8879/64");

int ret;
ret = system(s1.c_str());
Trace.WriteLine(TraceConstants::Configuration, "Cmd: ", s1, ", ret = ", 
ret);
ret = system(s2.c_str());
Trace.WriteLine(TraceConstants::Configuration, "Cmd: ", s2, ", ret = ", 
ret);
ret = system(s3.c_str());
Trace.WriteLine(TraceConstants::Configuration, "Cmd: ", s3, ", ret = ", 
ret);
ret = system(s4.c_str());
Trace.WriteLine(TraceConstants::Configuration, "Cmd: ", s4, ", ret = ", 
ret);


my startup.conf file:

unix {
  nodaemon
  log /var/log/vpp/vpp.log
  full-coredump
  cli-listen /run/vpp/cli.sock
  gid vpp
}


[cid:image002.png@01D6BCD6.975B3AD0]




--

Thanks and regards,
Aniket Pugaonkar

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18063): https://lists.fd.io/g/vpp-dev/message/18063
Mute This Topic: https://lists.fd.io/mt/78320037/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] Can I submit commit to vpp GitHub repo instead of gerrit?

[Chris Luke]

Like Damjan said, we use Gerrit. Those GitHub PR’s won’t be reviewed. I thought 
it used to say it was only a mirror, but doesn’t now. GitHub I think now allows 
us remove the option to create PR’s, perhaps we should make that so.

If you want to submit patches for review, details at 
https://wiki.fd.io/view/VPP/Pulling,_Building,_Running,_Hacking_and_Pushing_VPP_Code
 – anyone can sign up for an account with Linux Foundation and login to fd.io’s 
gerrit.

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of Dimitrios Markou
Sent: Monday, September 28, 2020 12:07
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] [vpp-dev] Can I submit commit to vpp GitHub repo instead of 
gerrit?

Hello all,

I would like to ask if it is possible to create pull requests to the vpp github 
repo. I am not sure if I am allowed to do so or I must use only the gerrit 
path. I am asking because I am seeing couple pull requests in the github repo.

https://github.com/FDio/vpp/pulls

Regards,
Dimitris

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17560): https://lists.fd.io/g/vpp-dev/message/17560
Mute This Topic: https://lists.fd.io/mt/77178878/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-committers] [vpp-dev] VPP committers: VPP PTL vote

[Chris Luke]

Is it too late to change my vote? :)

(kidding)

Chris.

-Original Message-
From: vpp-committ...@lists.fd.io  On Behalf Of 
Damjan Marion via lists.fd.io
Sent: Monday, September 28, 2020 07:48
To: Benoit Ganne (bganne) 
Cc: Dave Barach (dbarach) ; vpp-committ...@lists.fd.io; 
vpp-dev@lists.fd.io
Subject: [EXTERNAL] Re: [vpp-committers] [vpp-dev] VPP committers: VPP PTL vote



Now when we have votes from all 12 committers (me excluded) I would like to 
thank you all for your +1s.
It is nice to be elected by unanimous decision :)

—
Damjan


> On 28.09.2020., at 09:44, Benoit Ganne (bganne) via lists.fd.io 
>  wrote:
>
> +1
>
> And I take this opportunity to say a big thank you Dave for your efforts to 
> build an healthy community, and all the best for Damjan in his (I hope) 
> future new role 
>
> Best
> ben
>
>> -Original Message-
>> From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach
>> via lists.fd.io
>> Sent: vendredi 25 septembre 2020 21:14
>> To: vpp-committ...@lists.fd.io
>> Cc: vpp-dev@lists.fd.io
>> Subject: [vpp-dev] VPP committers: VPP PTL vote
>>
>> Folks,
>>
>>
>>
>> The self-nomination period closed yesterday. We had one self-nomination,
>> from Damjan Marion. At this point, we can proceed with a vote.
>>
>>
>>
>> I’m sure that Damjan will do a great job, so let me start:
>>
>>
>>
>> Damjan Marion as VPP PTL: +1
>>
>>
>>
>> Please vote +1, 0, -1. For once, the “reply-all” button is everyone’s
>> friend.
>>
>>
>>
>> Thanks... Dave
>>
>>
>>
>> -Original Message-
>> From: d...@barachs.net 
>> Sent: Thursday, September 17, 2020 10:32 AM
>> To: 'vpp-dev@lists.fd.io' ; 't...@lists.fd.io'
>> 
>> Subject: Happy Trails to Me...
>>
>>
>>
>> Folks,
>>
>>
>>
>> I’m departing the employment rolls towards the end of next month. Although
>> I intend to remain active in the fd.io vpp community as a coder,
>> committer, and resident greybeard, it’s time for the community to pick a
>> new PTL.
>>
>>
>>
>> According to the project governance document,
>> https://urldefense.com/v3/__https://fd.io/docs/tsc/FD.IO-Technical-Community-Document-12-12-2017.pdf__;!!CQl3mcHX2A!WmRcJWF6bQqlI4cuG6JddoEFrsl7GtBe3_DDVexBF_xjXQiSCmxaICfJO6Qgzked0Q$
>> >  >
>> :
>>
>>
>>
>> 3.2.3.1 Project Technical Leader Candidates Candidates for the project’s
>> PTL will be derived from the Committers of the Project. Candidates must
>> self-nominate.
>>
>>
>>
>> I'd like to invite any interested vpp project committer to self-nominate
>> for the PTL role. Please email vpp-dev@lists.fd.io > d...@lists.fd.io> .
>>
>>
>>
>> Let's close the self-nomination period in one week: more specifically, by
>> 5pm EDT on Thursday, September 24, 2020; committer vote to follow
>> thereafter.
>>
>>
>>
>> I'll be glad to answer unicast questions about the PTL role from eligible
>> committers.
>>
>>
>>
>> Thanks... Dave
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17550): https://lists.fd.io/g/vpp-dev/message/17550
Mute This Topic: https://lists.fd.io/mt/77172336/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] [EXTERNAL] [vpp-committers] VPP committers: VPP PTL vote

[Chris Luke]

+1

From: vpp-committ...@lists.fd.io  On Behalf Of Dave 
Barach via lists.fd.io
Sent: Friday, September 25, 2020 15:14
To: vpp-committ...@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: [EXTERNAL] [vpp-committers] VPP committers: VPP PTL vote

Folks,

The self-nomination period closed yesterday. We had one self-nomination, from 
Damjan Marion. At this point, we can proceed with a vote.

I'm sure that Damjan will do a great job, so let me start:

Damjan Marion as VPP PTL: +1

Please vote +1, 0, -1. For once, the "reply-all" button is everyone's friend.

Thanks... Dave



-Original Message-
From: d...@barachs.net 
mailto:d...@barachs.net>>
Sent: Thursday, September 17, 2020 10:32 AM
To: 'vpp-dev@lists.fd.io' mailto:vpp-dev@lists.fd.io>>; 
't...@lists.fd.io' mailto:t...@lists.fd.io>>
Subject: Happy Trails to Me...



Folks,



I'm departing the employment rolls towards the end of next month. Although I 
intend to remain active in the fd.io vpp community as a coder, committer, and 
resident greybeard, it's time for the community to pick a new PTL.



According to the project governance document, 
https://fd.io/docs/tsc/FD.IO-Technical-Community-Document-12-12-2017.pdf:



3.2.3.1 Project Technical Leader Candidates Candidates for the project's PTL 
will be derived from the Committers of the Project. Candidates must 
self-nominate.



I'd like to invite any interested vpp project committer to self-nominate for 
the PTL role. Please email vpp-dev@lists.fd.io.



Let's close the self-nomination period in one week: more specifically, by 5pm 
EDT on Thursday, September 24, 2020; committer vote to follow thereafter.



I'll be glad to answer unicast questions about the PTL role from eligible 
committers.



Thanks... Dave












-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17523): https://lists.fd.io/g/vpp-dev/message/17523
Mute This Topic: https://lists.fd.io/mt/77123583/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [EXTERNAL] Re: [vpp-dev] Please look at coverity defects in preparation for VPP 20.09 before Monday

[Chris Luke]

I’m dusting off dim recollection.. and it’s further complicated by the scan 
service (which is the free Coverity for open source projects that we use) being 
slightly different from the commercial offering. At the time, I feel I 
concluded that Coverity models could override macro definitions but that this 
may be one of the features scan didn’t support, partly because the model file 
is maintained in the web service, and the data collection happens completely 
offline until the point of submission.


I don’t remember if I tried overriding these macros locally during collection, 
but that would be my next thought; it would require some hoop jumping (eg, 
including __coverity_tainted_data_sanitize__ as a weak function stub so the 
build succeeds but does not interfere with Coverity). I suspect I left it 
because of diminishing returns on the effort when we’d already managed the 
defect list to a reasonable size, and new issues were easily assessed and 
marked in the UI as they arose.

I also note the examples in Coverity’s documentation showing macros in the 
modelling file are no longer present – or perhaps I imagined them :)

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of Andrew Yourtchenko
Sent: Friday, September 11, 2020 11:41
To: Luke, Chris 
Cc: Nathan Skrzypczak ; vpp-dev 

Subject: Re: [EXTERNAL] Re: [vpp-dev] Please look at coverity defects in 
preparation for VPP 20.09 before Monday

Chris,

this is very interesting - i was under the impression that coverity operates 
post-macro expansion (and thus should see the check within 
VALIDATE_SW_IF_INDEX)... is it not the case, or am I missing something else ?

--a


On 11 Sep 2020, at 17:06, Luke, Chris 
mailto:chris_l...@comcast.com>> wrote:

Nathan,

Just a caveat; those Coverity comments do not always work – at least didn’t 
when we started using Coverity. They have plausibly improved things in the 
analyzer since but I have not seen that; I would be interested to see if it is 
effective once patches are merged and my twice daily submission runs, so let me 
know!


For example, I did setup a modeling 
file
 that has fake versions of key macros to mark certain data as safe (eg, if we 
inspect an interface index with VALIDATE_SW_IF_INDEX or variants of, we can 
assume the index is now safe) but I did not find that to be effective at the 
time, so did not make it any more complete. If that now works, this would be a 
better way to handle most tainted data errors – the validation macros/functions 
squelch the complaint.



Chris.

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Nathan Skrzypczak
Sent: Friday, September 11, 2020 04:45
To: Andrew Yourtchenko mailto:ayour...@gmail.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: [EXTERNAL] Re: [vpp-dev] Please look at coverity defects in 
preparation for VPP 20.09 before Monday

Hi Andrew, Hi all,

Thanks for the coverity reminder and good luck with release work Andrew !

Just sharing some info for fixing coverity warnings as it was surprisingly 
difficult to find.
The checker's reference can be found here [1]. False positive can *apparently* 
be
silenced with comments, e.g. :

/* coverity [COPY_PASTE_ERROR] */
u8 
ab->ba.ab.ba
 = 1;

/* coverity[ -tainted_data_argument : arg-0 ] */
recvmsg (...);

Hope this helps
Cheers

-Nathan
[1] 
https://scan9.coverity.com/doc/en/cov_checker_ref.html

Le jeu. 10 sept. 2020 à 17:10, Andrew Yourtchenko 
mailto:ayour...@gmail.com>> a écrit :
Dear developers,

In preparation for the 20.09 release - could you please take a look at
the Coverity report and address the outstanding issues in "your" areas
of the code.

To do so: go to 
https://scan.coverity.com/projects/fd-io-vpp,
 login,
then hit "view defects" button on the top right.

There are currently 18 defects as seen there.

Each Coverity issue corresponds to a defect.

We need to have this number to be 0 by RC2, so on Monday I will start
contacting the folks personally with either a "thank you" note if that
issue has already taken care of between now and then, or a request to
open a JIRA ticket so that it can be tracked and mentioned in the
release notes for 20.09 as a known issue. I'd obviously prefer the
former, it's less work for everyone and the users will be happier with
the result. :-)

So - thanks a lot in advance for spending some of your cycles 

Re: [EXTERNAL] Re: [vpp-dev] Please look at coverity defects in preparation for VPP 20.09 before Monday

[Chris Luke]

Nathan,

Just a caveat; those Coverity comments do not always work – at least didn’t 
when we started using Coverity. They have plausibly improved things in the 
analyzer since but I have not seen that; I would be interested to see if it is 
effective once patches are merged and my twice daily submission runs, so let me 
know!


For example, I did setup a modeling 
file that has fake 
versions of key macros to mark certain data as safe (eg, if we inspect an 
interface index with VALIDATE_SW_IF_INDEX or variants of, we can assume the 
index is now safe) but I did not find that to be effective at the time, so did 
not make it any more complete. If that now works, this would be a better way to 
handle most tainted data errors – the validation macros/functions squelch the 
complaint.



Chris.

From: vpp-dev@lists.fd.io  On Behalf Of Nathan Skrzypczak
Sent: Friday, September 11, 2020 04:45
To: Andrew Yourtchenko 
Cc: vpp-dev 
Subject: [EXTERNAL] Re: [vpp-dev] Please look at coverity defects in 
preparation for VPP 20.09 before Monday

Hi Andrew, Hi all,

Thanks for the coverity reminder and good luck with release work Andrew !

Just sharing some info for fixing coverity warnings as it was surprisingly 
difficult to find.
The checker's reference can be found here [1]. False positive can *apparently* 
be
silenced with comments, e.g. :

/* coverity [COPY_PASTE_ERROR] */
u8 
ab->ba.ab.ba
 = 1;

/* coverity[ -tainted_data_argument : arg-0 ] */
recvmsg (...);

Hope this helps
Cheers

-Nathan
[1] 
https://scan9.coverity.com/doc/en/cov_checker_ref.html

Le jeu. 10 sept. 2020 à 17:10, Andrew Yourtchenko 
mailto:ayour...@gmail.com>> a écrit :
Dear developers,

In preparation for the 20.09 release - could you please take a look at
the Coverity report and address the outstanding issues in "your" areas
of the code.

To do so: go to 
https://scan.coverity.com/projects/fd-io-vpp,
 login,
then hit "view defects" button on the top right.

There are currently 18 defects as seen there.

Each Coverity issue corresponds to a defect.

We need to have this number to be 0 by RC2, so on Monday I will start
contacting the folks personally with either a "thank you" note if that
issue has already taken care of between now and then, or a request to
open a JIRA ticket so that it can be tracked and mentioned in the
release notes for 20.09 as a known issue. I'd obviously prefer the
former, it's less work for everyone and the users will be happier with
the result. :-)

So - thanks a lot in advance for spending some of your cycles tomorrow
and squashing all of the outstanding defects !

--a /* your friendly 20.0Segmentation fault (core dumped)
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17375): https://lists.fd.io/g/vpp-dev/message/17375
Mute This Topic: https://lists.fd.io/mt/76781568/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] How to see coverity logs

[Chris Luke]

Oh, I think I worked out what you mean; you authorized Coverity to use GitHub 
as an authenticator, and in the process gave Coverity access to every Git 
repository you have access to? I refuse it that access every time it asks.

That should not have an impact on your access to the defects of VPP, but at a 
guess if the email address you used for signing up on Coverity does not match 
one in your github profile I could imagine it being confused. I would suggest 
not signing in with GitHub, personally.

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of Chris Luke
Sent: Wednesday, September 2, 2020 08:46
To: Nitin Saxena ; vpp-dev 
Subject: Re: [vpp-dev] How to see coverity logs

The correct URL is 
https://scan.coverity.com/projects/fd-io-vpp<https://urldefense.com/v3/__https:/scan.coverity.com/projects/fd-io-vpp__;!!CQl3mcHX2A!U7yKF4Y-O3KsSU4HOv5wWnndeddI20UGds-4hkl6PBa--dipNIDiF0z4hk0CKjaj4w$>
 (you missed a trailing p) but I am not sure how you would add it "to your 
github". It's just a web page.

I also note that you're listed as a contributor, so you should have access to 
see the defects.

Chris.

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Nitin Saxena
Sent: Wednesday, September 2, 2020 03:31
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: [EXTERNAL] [vpp-dev] How to see coverity logs

Hi Maintainers,

I would like to see coverity logs for latest VPP build. I tried adding 
https://scan.coverity.com/projects/fd-io-vp<https://urldefense.com/v3/__https:/scan.coverity.com/projects/fd-io-vp__;!!CQl3mcHX2A!S6R6FhXXP0uNdzFhnEBZpJGUw5NwEuTl7RYy8oRf6MsvPkQMif78_M3Q-pmURxS7Gw$>
 to my github but when I click on "View Defects" it says "Permission denied".
Is it possible to view coverity logs or I am missing anything?

Thanks,
Nitin


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

View/Reply Online (#17316): https://lists.fd.io/g/vpp-dev/message/17316
Mute This Topic: https://lists.fd.io/mt/76577815/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] How to see coverity logs

[Chris Luke]

The correct URL is https://scan.coverity.com/projects/fd-io-vpp (you missed a 
trailing p) but I am not sure how you would add it "to your github". It's just 
a web page.

I also note that you're listed as a contributor, so you should have access to 
see the defects.

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of Nitin Saxena
Sent: Wednesday, September 2, 2020 03:31
To: vpp-dev 
Subject: [EXTERNAL] [vpp-dev] How to see coverity logs

Hi Maintainers,

I would like to see coverity logs for latest VPP build. I tried adding 
https://scan.coverity.com/projects/fd-io-vp
 to my github but when I click on "View Defects" it says "Permission denied".
Is it possible to view coverity logs or I am missing anything?

Thanks,
Nitin


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

View/Reply Online (#17314): https://lists.fd.io/g/vpp-dev/message/17314
Mute This Topic: https://lists.fd.io/mt/76577815/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 20.05.1 tomorrow 15th July 2020

[Chris Luke]

To clarify, committers are the only ones who can approve and merge changes, to 
any of the maintained branches.

Any contributor can propose changes to any open branch, and a cherry-pick is 
just a proposed change that happens to be a (rebased) copy of another change.

Chris.

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Elias Rudberg
Sent: Wednesday, July 15, 2020 07:29
To: ayour...@gmail.com
Cc: vpp-dev@lists.fd.io; dwallac...@gmail.com
Subject: [EXTERNAL] Re: [vpp-dev] VPP 20.05.1 tomorrow 15th July 2020

Hi Andrew,

I don't know how to cherry-pick. I was under the impression that only the 
trusted commiters were allowed to do that, maybe I misunderstood that.

What I know so far about the gerrit system is what I read here:
https://urldefense.com/v3/__https://wiki.fd.io/view/VPP/Pulling,_Building,_Running,_Hacking_and_Pushing_VPP_Code*Pushing_Code_with_git_review__;Iw!!CQl3mcHX2A!SkOWdT8Z5B79TmRqn5_fL1LYof7mqilJRpdNLporTGsXh43TVyfj4Bbx1Qvmpnk8Ag$

Is there a guide somewhere describing how to do cherry-picking?
Alternatively, could you do it for me?

/ Elias


On Wed, 2020-07-15 at 12:27 +0200, Andrew  Yourtchenko wrote:
> Hi Elias, sure, feel free to cherry-pick to stable/2005 branch and add
> me as a reviewer, then I can merge when JJB gives thumbs up.
>
> --a
>
> > On 15 Jul 2020, at 07:25, Elias Rudberg 
> > wrote:
> >
> > Hello Andrew,
> >
> > The following two fixes have been merged to the master branch, it
> > would be good to have them in stable/2005 also:
> >
> > https://urldefense.com/v3/__https://gerrit.fd.io/r/c/vpp/*/27280__;K
> > w!!CQl3mcHX2A!SkOWdT8Z5B79TmRqn5_fL1LYof7mqilJRpdNLporTGsXh43TVyfj4B
> > bx1QuwGCsEhg$  (misc: ipfix-export unformat
> > u16
> > collector_port fix)
> >
> > https://urldefense.com/v3/__https://gerrit.fd.io/r/c/vpp/*/27281__;K
> > w!!CQl3mcHX2A!SkOWdT8Z5B79TmRqn5_fL1LYof7mqilJRpdNLporTGsXh43TVyfj4B
> > bx1QufJvaKPw$  (nat: fix regarding vm arg for vlib_time_now call)
> >
> > Best regards,
> > Elias
> >
> >
> > > On Tue, 2020-07-14 at 19:04 +0200, Andrew Yourtchenko wrote:
> > > Hi all,
> > >
> > > As agreed on the VPP community call today, we will declare the
> > > current stable/2005 branch as v20.05.1 tomorrow (15th July)
> > >
> > > If you have any fixes that are already in master but not yet in
> > > stable/2005, that you want to get in there - please let  me know
> > > before noon UTC.
> > >
> > > --a
> > > Your friendly release manager
> > > -=-=-=-=-=-=-=-=-=-=-=-
> > >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16972): https://lists.fd.io/g/vpp-dev/message/16972
Mute This Topic: https://lists.fd.io/mt/75503386/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] Replacing master/slave nomenclature

[Chris Luke]

It is subjective and contextualized. But in this case, if making the effort to 
correct a wrong, why stop half way?

Chris.

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Jerome Tollet via 
lists.fd.io
Sent: Tuesday, July 14, 2020 12:37
To: Steven Luong (sluong) ; Dave Barach (dbarach) 
; Kinsella, Ray ; Stephen Hemminger 
; vpp-dev@lists.fd.io; t...@lists.fd.io; Ed 
Warnicke (eaw) 
Subject: [EXTERNAL] Re: [vpp-dev] Replacing master/slave nomenclature

Hi Steven,
Please note that per this proposition,  
https://urldefense.com/v3/__https://lkml.org/lkml/2020/7/4/229__;!!CQl3mcHX2A!QdLdxm4rtZW-mFe5jt_qzEpx-_X2KWnqvjyEl-7Py41jsEV7FrnEw0lTNcF8LdfUzQ$
 , slave must be avoided but master can be kept.
Maybe master/member or master/secondary could be options too.
Jerome

Le 14/07/2020 18:32, « vpp-dev@lists.fd.io au nom de steven luong via 
lists.fd.io »  a 
écrit :

I am in the process of pushing a patch to replace master/slave with 
aggregator/member for the bonding.

Steven

On 7/13/20, 4:44 AM, "vpp-dev@lists.fd.io on behalf of Dave Barach via 
lists.fd.io"  
wrote:

+1, especially since our next release will be supported for a year, and 
API name changes are involved...

-Original Message-
From: Kinsella, Ray 
Sent: Monday, July 13, 2020 6:01 AM
To: Dave Barach (dbarach) ; Stephen Hemminger 
; vpp-dev@lists.fd.io; t...@lists.fd.io; Ed 
Warnicke (eaw) 
Subject: Re: [vpp-dev] Replacing master/slave nomenclature

Hi Stephen,

I agree, I don't think we should ignore this.
Ed - I suggest we table a discussion at the next FD.io TSC?

Ray K

On 09/07/2020 17:05, Dave Barach via lists.fd.io wrote:
> Looping in the technical steering committee...
>
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Stephen 
Hemminger
> Sent: Thursday, July 2, 2020 7:02 PM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Replacing master/slave nomenclature
>
> Is the VPP project addressing the use of master/slave nomenclature in 
the code base, documentation and CLI?  We are doing this for DPDK and it would 
be good if the replacement wording used in DPDK matched the wording used in 
FD.io projects.
>
> Particularly problematic is the use of master/slave in bonding.
> This seems to be a leftover from Linux, since none of the commercial 
products use that terminology and it is not present in 802.1AX standard.
>
> The IEEE and IETF are doing an across the board look at these terms 
in standards.
>
>
>
>


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

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

Re: [EXTERNAL] [vpp-dev] why define an unused var

[Chris Luke]

With strict static analysis it should complain when return values go ignored.

The canonical way to flag that this is intentional and avoid the warning is to 
cast the result to (void) however any optimizing compiler will correctly omit 
any storage of the result of an ((unused)) variable, so no big deal really if 
it’s done the way you show. It’s likely this came about incrementally in the 
code.

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of "??
Sent: Saturday, July 11, 2020 04:48
To: vpp-dev 
Subject: [EXTERNAL] [vpp-dev] why define an unused var

hi there,

i'm reading vpp code,  and confused with this code: int rv __attribute__ 
((unused)) = write (2, "Main heap allocation failure!\r\n", 31); why it define 
a var named rv, but never used, what dose this var mean to?

git:stable/1609
vpp/vnet/main.c:264
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [EXTERNAL] [vpp-dev] VPP release 20.05 is complete!

[Chris Luke]

Brilliant, good job!

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Andrew Yourtchenko
Sent: Wednesday, May 27, 2020 17:28
To: vpp-dev 
Subject: [EXTERNAL] [vpp-dev] VPP release 20.05 is complete!

Dear all,

I am happy to announce that the release 20.05 is available on packagecloud.io 
in fdio/release repository.

I have verified that it is installable on Ubuntu 18.04 and Centos 7 
distributions.

Special thanks to Vanessa Valderrama and Dave Wallace for the help during the 
release.

--a (your friendly 20.05 release manager)

P.s. Branch stable/2005 is now open.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution giving error

[Chris Luke]

That is quite odd indeed.  This is the sort of issue that could take some time 
to properly diagnose and I cannot dig in to it right away. For now, if you are 
not using the output, perhaps as a workaround simply redirect stdout to 
/dev/null?

That said, if this part of a larger application, I suspect SR provides API 
access and that will generally be much more performant than using vppctl.

Chris.

From: Chinmaya Aggarwal 
Sent: Wednesday, May 27, 2020 05:47
To: Luke, Chris ; vpp-dev@lists.fd.io
Subject: Re: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution 
giving error

Attached is the sample VPP commands script, having a delay of 50 ms. Below is 
the screenshot of he output we get on running the script : -
Request 88 :  time 14:05:01.906
Request 89 :  time 14:05:01.906
Request 90 :  time 14:05:02.043
_____   _  ___
 __/ __/ _ \  (_)__| | / / _ \/ _ \
 _/ _// // / / / _ \   | |/ / ___/ ___/
 /_/ /(_)_/\___/   |___/_/  /_/

vpp# Request 91 :  time 14:05:02.043
_____   _  ___
 __/ __/ _ \  (_)__| | / / _ \/ _ \
 _/ _// // / / / _ \   | |/ / ___/ ___/
 /_/ /(_)_/\___/   |___/_/  /_/

vpp# Request 92 :  time 14:05:02.213
Request 93 :  time 14:05:02.213
Request 94 :  time 14:05:02.358

The commands are executed sequentially at a gap of 50 ms. As seen from the 
execution time displayed by the script, we never see a situation where the gap 
is more than 1 sec.
Can you please guide us through this?

Thanks and Regards,
Chinmaya Agarwal.

From: Luke, Chris mailto:chris_l...@comcast.com>>
Sent: Tuesday, May 26, 2020 7:34 PM
To: Luke, Chris mailto:chris_l...@comcast.com>>; 
Chinmaya Aggarwal mailto:chinmaya.agar...@hsc.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>>
Subject: RE: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution 
giving error


CAUTION:This email originated from an external organization

Actually, I missed one detail, if you tell vppctl to run a command using its 
command line arguments, it will always assume non-interactive.



The only way you'll see the banner, then, is if the 1s session startup timer 
expires and it makes assumptions. In those cases that you see the output, does 
the script you run stall for a second?



Chris.



From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Chris Luke
Sent: Tuesday, May 26, 2020 09:40
To: Chinmaya Aggarwal 
mailto:chinmaya.agar...@hsc.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution 
giving error



You'll get the banner if it thinks it's an interactive session.



Roughly vppctl does this (I am paraphrasing):



is_interactive = isatty(STDIN);

...

if (is_interactive) TERM = "vppctl";

...

open telnet session to the CLI socket; pass the terminal information



Then in VPP:



is_interactive = (strcmp(TERM, "vppctl") != 0);

...

if (is_interactive) emit_banner();



The passing of the terminal options in the TELNET protocol is bounded by a 
timer (1 second); if for whatever reason that information arrives late, VPP 
will make assumptions; typically that the terminal is of the 'dumb' type rather 
than non-interactive.



Does this correlate to what you are observing? Does the output you see make use 
of ANSI color? That would be another clue, the 'dumb' terminal doesn't use 
color.



Chris.





From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Chinmaya Aggarwal
Sent: Tuesday, May 26, 2020 08:19
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution 
giving error



Further adding to observations regarding above issue, we have created a script 
that has only vpp commands running sequentially having a constant delay between 
the execution of each commands. On running the script, we again see VPP shell 
output as shown below :-

_____   _  ___

 __/ __/ _ \  (_)__| | / / _ \/ _ \

 _/ _// // / / / _ \   | |/ / ___/ ___/

 /_/ /(_)_/\___/   |___/_/  /_/

We executed the script with delay of 10ms, 50ms and 100ms. In most of the 
cases, we get no output from vppctl command but in some random times, we get 
the vpp shell as output of the command.



Please suggest, in what scenarios does the vpp return this kind of output?
DISCLAIMER: This electronic message and all of its contents, contains 
information which is privileged, confidential or otherwise protected from 
disclosure. The information contained in this electronic mail transmission is 
intended for use only by the individual or entity to which it is addressed. If 
you are not the intended recipient or may have received this electronic mail 
transmission in error, p

Re: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution giving error

[Chris Luke]

Actually, I missed one detail, if you tell vppctl to run a command using its 
command line arguments, it will always assume non-interactive.

The only way you’ll see the banner, then, is if the 1s session startup timer 
expires and it makes assumptions. In those cases that you see the output, does 
the script you run stall for a second?

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of Chris Luke
Sent: Tuesday, May 26, 2020 09:40
To: Chinmaya Aggarwal ; vpp-dev@lists.fd.io
Subject: Re: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution 
giving error

You’ll get the banner if it thinks it’s an interactive session.

Roughly vppctl does this (I am paraphrasing):

is_interactive = isatty(STDIN);
…
if (is_interactive) TERM = “vppctl”;
…
open telnet session to the CLI socket; pass the terminal information

Then in VPP:

is_interactive = (strcmp(TERM, “vppctl”) != 0);
…
if (is_interactive) emit_banner();

The passing of the terminal options in the TELNET protocol is bounded by a 
timer (1 second); if for whatever reason that information arrives late, VPP 
will make assumptions; typically that the terminal is of the ‘dumb’ type rather 
than non-interactive.

Does this correlate to what you are observing? Does the output you see make use 
of ANSI color? That would be another clue, the ‘dumb’ terminal doesn’t use 
color.

Chris.


From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Chinmaya Aggarwal
Sent: Tuesday, May 26, 2020 08:19
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution 
giving error

Further adding to observations regarding above issue, we have created a script 
that has only vpp commands running sequentially having a constant delay between 
the execution of each commands. On running the script, we again see VPP shell 
output as shown below :-
_____   _  ___
 __/ __/ _ \  (_)__| | / / _ \/ _ \
 _/ _// // / / / _ \   | |/ / ___/ ___/
 /_/ /(_)_/\___/   |___/_/  /_/
We executed the script with delay of 10ms, 50ms and 100ms. In most of the 
cases, we get no output from vppctl command but in some random times, we get 
the vpp shell as output of the command.

Please suggest, in what scenarios does the vpp return this kind of output?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution giving error

[Chris Luke]

You’ll get the banner if it thinks it’s an interactive session.

Roughly vppctl does this (I am paraphrasing):

is_interactive = isatty(STDIN);
…
if (is_interactive) TERM = “vppctl”;
…
open telnet session to the CLI socket; pass the terminal information

Then in VPP:

is_interactive = (strcmp(TERM, “vppctl”) != 0);
…
if (is_interactive) emit_banner();

The passing of the terminal options in the TELNET protocol is bounded by a 
timer (1 second); if for whatever reason that information arrives late, VPP 
will make assumptions; typically that the terminal is of the ‘dumb’ type rather 
than non-interactive.

Does this correlate to what you are observing? Does the output you see make use 
of ANSI color? That would be another clue, the ‘dumb’ terminal doesn’t use 
color.

Chris.


From: vpp-dev@lists.fd.io  On Behalf Of Chinmaya Aggarwal
Sent: Tuesday, May 26, 2020 08:19
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution 
giving error

Further adding to observations regarding above issue, we have created a script 
that has only vpp commands running sequentially having a constant delay between 
the execution of each commands. On running the script, we again see VPP shell 
output as shown below :-
_____   _  ___
 __/ __/ _ \  (_)__| | / / _ \/ _ \
 _/ _// // / / / _ \   | |/ / ___/ ___/
 /_/ /(_)_/\___/   |___/_/  /_/
We executed the script with delay of 10ms, 50ms and 100ms. In most of the 
cases, we get no output from vppctl command but in some random times, we get 
the vpp shell as output of the command.

Please suggest, in what scenarios does the vpp return this kind of output?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16494): https://lists.fd.io/g/vpp-dev/message/16494
Mute This Topic: https://lists.fd.io/mt/74477335/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] Help with creating patch

[Chris Luke]

Govind,

Did you create a branch locally before making a commit? It looks like you tried 
to push to master which won't work. A typical workflow involves creating a 
local branch, making some changes and commits and then pushing to Gerrit.

Also, I changed the email subject; you should really have started a new thread 
instead of replying to an existing thread with something unrelated.

Chris.

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Govindarajan 
Mohandoss
Sent: Wednesday, May 13, 2020 19:24
To: ayour...@gmail.com; vpp-dev 
Cc: nd 
Subject: [EXTERNAL] Re: [vpp-dev] VPP 20.05 RC1 milestone is complete! RC2 - on 
Wednesday 20th May

Hello Maintainers,
 I am doing the patch submission for the first time.
 I am following the page 
https://urldefense.com/v3/__https://wiki.fd.io/view/VPP/Pulling,_Building,_Running,_Hacking_and_Pushing_VPP_Code*Pulling__;Iw!!CQl3mcHX2A!X_YlDf6H02w8Ew6AQDrBpiMP7UZ5XJeDWGNgAaY0wqMSqos0VyWPgbGH8cP27Pol6w$
  and getting the error below. Can you please help to fix this ?

#:~/vpp_external/vpp$ git review
remote: error: branch refs/publish/master:
remote: You need 'Create' rights to create new references.
remote: User: mgovind
remote: Contact an administrator to fix the permissions
remote:
remote: Processing changes: refs: 1
remote: Processing changes: refs: 1, done To ssh://gerrit.fd.io:29418/vpp
 ! [remote rejected] HEAD -> refs/publish/master (prohibited by Gerrit: not 
permitted: create)
error: failed to push some refs to 'ssh://mgov...@gerrit.fd.io:29418/vpp'

Thanks
Govind

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Andrew
> Yourtchenko via lists.fd.io
> Sent: Wednesday, May 13, 2020 6:05 PM
> To: vpp-dev 
> Subject: [vpp-dev] VPP 20.05 RC1 milestone is complete! RC2 - on
> Wednesday 20th May
>
> Hi all,
>
> This is to announce that the VPP 20.05 RC1 milestone is complete!
>
> The newly created stable/2005 branch is ready for your fixes in
> preparation for the RC2 milestone.
>
> They need to have a Jira ticket for the issue, and to avoid forgetting
> adding them to master, where practical, *should* be first merged there
> and then cherry-picked into the stable/2005 branch - but as soon as
> the Jira ticket is mentioned in the commit message and the fix ends up
> in both master and
> stable/2005 (and if it is important/urgent - maybe earlier branches),
> then either order is fine.
>
> The installation packages for the RC1 for Ubuntu 18.04 and Centos 7
> from the new branch are available on
> https://urldefense.com/v3/__https://packagecloud.io/fdio/2005/__;!!CQl
> 3mcHX2A!X_YlDf6H02w8Ew6AQDrBpiMP7UZ5XJeDWGNgAaY0wqMSqos0VyWPgbGH8cM1me
> QxkA$
>
> The master branch is open for all commits.
>
> Our next milestone for VPP 20.05 is RC2, happening next Wednesday 20th
> May.
>
> Thanks a lot to Vanessa Valderrama, Dave Wallace and Ed Warnicke for
> the help!
>
> --a
> /* Your friendly 2005 release manager */
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16371): https://lists.fd.io/g/vpp-dev/message/16371
Mute This Topic: https://lists.fd.io/mt/74197290/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 project committer nomination: Benoit Ganne

[Chris Luke]

+1

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
lists.fd.io
Sent: Tuesday, April 21, 2020 07:40
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] [vpp-dev] vpp project committer nomination: Benoit Ganne

Vpp project committers: please vote +1, 0, -1 on the mailto:vpp-dev@lists.fd.io 
mailer as to whether we should add Benoit Ganne as a vpp project committer.

Ben has about 150 merged patches, see 
https://urldefense.com/v3/__https://gerrit.fd.io/r/q/status:merged*owner:bganne*2540cisco.com__;KyU!!CQl3mcHX2A!TTZFsLO2V2WrKhWwVpqgPGCd7VUib3ra9qSJpToKLL9OrT4JX5e2R8huvX5FYP30Sw$
 . He has expressed interest in the role, and I believe that he will make a 
fine committer.

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

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

Re: [EXTERNAL] Re: [vpp-dev] APPROVED: add Matt Smith as a vpp committer, subject to TSC approval this Thursday

[Chris Luke]

Congratulations, and welcome!

Chris


From: vpp-dev@lists.fd.io  On Behalf Of Matthew Smith via 
Lists.Fd.Io
Sent: Monday, March 2, 2020 4:11 PM
To: Dave Barach (dbarach) 
Cc: vpp-dev@lists.fd.io
Subject: [EXTERNAL] Re: [vpp-dev] APPROVED: add Matt Smith as a vpp committer, 
subject to TSC approval this Thursday


Thanks Dave (et al)!!

-Matt


On Mon, Mar 2, 2020 at 2:52 PM Dave Barach via 
Lists.Fd.Io
 mailto:cisco@lists.fd.io>> wrote:
With 100% of the votes counted: 11 votes +1, no other votes.

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

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

Re: [EXTERNAL] [vpp-dev] vpp project committers: formal vote to add Matt Smith as a vpp committer

[Chris Luke]

+1

From: vpp-dev@lists.fd.io  On Behalf Of d...@barachs.net
Sent: Monday, March 2, 2020 9:16 AM
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] [vpp-dev] vpp project committers: formal vote to add Matt 
Smith as a vpp committer

VPP committers, please vote +1, 0, -1 on adding Matt Smith 
(mgsm...@netgate.com) as a vpp project committer.
Matt has contributed O(100) merged patches, and he recently contributed the 
entire vrrp plugin. See 
https://gerrit.fd.io/r/q/owner:mgsmith%2540netgate.com
Please vote (on vpp-dev@lists.fd.io) by the end of 
this Wednesday, 2/4/2020, so we can put the results in front of the TSC this 
Thursday.
Thanks... Dave

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

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

Re: [EXTERNAL] Re: [vpp-dev] Wanted to use socket transport as VAT API ( not svm i.e shared memory default)

[Chris Luke]

Vppctl uses a unix socket, yes, but it’s exactly the same as the TCP socket 
version of the CLI – it runs the TELNET protocol and does terminal-like IO with 
unstructured intended-for-humans content. There’s nothing special about it.

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of 
sastry.si...@gmail.com
Sent: Friday, January 31, 2020 08:46
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] Re: [vpp-dev] Wanted to use socket transport as VAT API ( 
not svm i.e shared memory default)

Hi Ole,
  So VAT APIs has only shared memory has transport?

Socket fd APIs like producer_event_fd etc are there but, I am not sure if they 
are any use.

Please confirm if there is any other way to use VAT API?

ALso vppctl commands between vpp_main and vppctl is using Unix socket?

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

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

Re: [EXTERNAL] Re: [vpp-dev] Need info on memory-tracer

[Chris Luke]

Satish,

Tangential to the thread, but I maintain the CLI infrastructure. You had a 
crash disabling the CLI history? First command after starting VPP? Did you keep 
the backtrace from it? Any startup commands configured? It does not do that for 
me, so I am curious what corner case you have managed to tickle.

Thanks,
Chris.

From: vpp-dev@lists.fd.io  On Behalf Of 
satish.gu...@gmail.com
Sent: Wednesday, January 29, 2020 12:58 AM
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] Re: [vpp-dev] Need info on memory-tracer

Thank you Dave. I tried disabling history ( which caused a crash ). So, I used 
to gdb to avoid the problematic code for the time being.
With this, now, I am not seeing periodic increments in the traced allocations 
due to CLI history.

However, I am still not getting how to make good use of the "show memory 
verbose" o/p to find a leak.
The o/p is not removing the entries that were freed, which is bit confusing.

For ex:

1) With clean slate
traced object are 1.
Thread 0 vpp_main
  virtual memory start 0x7fffb4c86000, size 1048640k, 262160 pages, page size 4k
numa 0: 15708 pages, 62832k
not mapped: 0 pages, 0k
unknown: 246452 pages, 985808k
  total: 1.00G, used: 62.03M, free: 962.03M, trimmable: 958.59M
free chunks 79 free fastbin blks 0
max total allocated 1.00G

1 total traced objects
2) Now, I have added one ip table
traced objects became 26
Thread 0 vpp_main
  virtual memory start 0x7fffb4c86000, size 1048640k, 262160 pages, page size 4k
numa 0: 15708 pages, 62832k
not mapped: 0 pages, 0k
unknown: 246452 pages, 985808k
  total: 1.00G, used: 62.04M, free: 962.02M, trimmable: 958.59M
free chunks 78 free fastbin blks 0
max total allocated 1.00G

  BytesCount Sample   Traceback
 19201 0x7fffb8645eb0 clib_mem_alloc_aligned_at_offset + 0x86
  vec_resize_allocate_memory + 0x199
  _vec_resize_inline + 0x136
  mfib_entry_alloc + 0x1c4
  mfib_entry_create + 0x3d
  mfib_table_entry_update + 0x7f
  ip4_create_mfib_with_table_id + 0x3de
  ip4_mfib_table_find_or_create_and_lock + 0x3f
  mfib_table_find_or_create_and_lock_i + 0x44
  mfib_table_find_or_create_and_lock_w_name + 
0x3b
  ip_table_create + 0xb6
  vnet_ip_table_cmd + 0x1ff

26 total traced objects

3) Now , I deleted the same ip table
traced objects became 37. This really confused me. After deletion, the traced 
object should come down way below than 26 objects , right ?
How come it increased from 26 to 27. I could see the deallocation stack traces 
also in the output. But, how can we map each allocation to a deallocation and 
detect it as a leak ? Do we need to manually go through each stack trace and do 
this ?
Thread 0 vpp_main
  virtual memory start 0x7fffb4c86000, size 1048640k, 262160 pages, page size 4k
numa 0: 15708 pages, 62832k
not mapped: 0 pages, 0k
unknown: 246452 pages, 985808k
  total: 1.00G, used: 62.05M, free: 962.02M, trimmable: 958.59M
free chunks 66 free fastbin blks 0
max total allocated 1.00G


  BytesCount Sample   Traceback
 19201 0x7fffb8645eb0 clib_mem_alloc_aligned_at_offset + 0x86
  vec_resize_allocate_memory + 0x199
  _vec_resize_inline + 0x136
  mfib_entry_alloc + 0x1c4
  mfib_entry_create + 0x3d
  mfib_table_entry_update + 0x7f
  ip4_create_mfib_with_table_id + 0x3de
  ip4_mfib_table_find_or_create_and_lock + 0x3f
  mfib_table_find_or_create_and_lock_i + 0x44
  mfib_table_find_or_create_and_lock_w_name + 
0x3b
  ip_table_create + 0xb6
  vnet_ip_table_cmd + 0x1ff

I see some deallocation stack traces.

37 total traced objects


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

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

Re: [EXTERNAL] [vpp-dev] Change to Gerrit

[Chris Luke]

+1

From: vpp-dev@lists.fd.io  On Behalf Of Paul Vinciguerra
Sent: Wednesday, November 20, 2019 1:33 PM
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] [vpp-dev] Change to Gerrit

How would the group feel about implementing something like [0], so that changes 
to the commit message don't trigger rebuilds?

To enforce the commit message structure, we could skip the jobs and set verify 
label after the codestyle checks if no files were changed.
Maybe others don't care, but I don't like wasting cpu cycles/developer's time, 
and I weigh that before clarifying a commit message.

[0] 
https://gerrit-review.googlesource.com/Documentation/config-labels.html#label_copyAllScoresIfNoCodeChange
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [EXTERNAL] [vpp-dev] Coverity run FAILED as of 2019-11-11 14:01:19 UTC

[Chris Luke]

Looks like we were overdue for Coverity stalling, which it did a week or so 
ago. I've prodded it, but it may be a Coverity issue.

Chris.

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Noreply Jenkins
Sent: Monday, November 11, 2019 9:01 AM
To: vpp-dev@lists.fd.io; e...@cisco.com
Subject: [EXTERNAL] [vpp-dev] Coverity run FAILED as of 2019-11-11 14:01:19 UTC

Coverity run failed today.

[Error replacing 'FILE' - Workspace is not accessible]
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14560): https://lists.fd.io/g/vpp-dev/message/14560
Mute This Topic: https://lists.fd.io/mt/52907390/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] Coverity run FAILED as of 2019-10-22 14:00:19 UTC

[Chris Luke]

You'll be glad to hear that it did, indeed, clear Coverity up. :)

Chris

-Original Message-
From: Benoit Ganne (bganne) 
Sent: Tuesday, October 22, 2019 12:32
To: Luke, Chris ; Damjan Marion 
Cc: vpp-dev@lists.fd.io
Subject: [EXTERNAL] RE: [vpp-dev] Coverity run FAILED as of 2019-10-22 14:00:19 
UTC

> Redefine the macro for the Coverity case, so Coverity doesn't
> complain. It just needs to be representative of the execution you expect to 
> happen.

Ha yes good point, I was focusing on the ASSERT()...
Just did that: 
https://protect2.fireeye.com/url?k=52707044-0e947e8f-527057f0-000babff3540-a375f8b76a951681=https://gerrit.fd.io/r/c/vpp/+/22936
Hopefully, Coverity should remove the false positives with that.

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

View/Reply Online (#14281): https://lists.fd.io/g/vpp-dev/message/14281
Mute This Topic: https://lists.fd.io/mt/36443369/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] Coverity run FAILED as of 2019-10-22 14:00:19 UTC

[Chris Luke]

Redefine the macro for the Coverity case, so Coverity doesn't complain. It just 
needs to be representative of the execution you expect to happen.


-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Benoit Ganne 
(bganne) via Lists.Fd.Io
Sent: Tuesday, October 22, 2019 11:46 AM
To: Damjan Marion 
Cc: vpp-dev@lists.fd.io
Subject: [EXTERNAL] Re: [vpp-dev] Coverity run FAILED as of 2019-10-22 14:00:19 
UTC

> you can try to wrap that assert with #ifndef __COVERITY__ ...

It is in a macro... I was thinking to do something like ASSERT(0 == (l) || (l) 
<= vec_max_len(v)) (with special care for not double-evaluating (l) ).
But then, will the warning will disappear from Coverity? Or should we mark them 
anyway?

ben

> > On 22 Oct 2019, at 16:22, Benoit Ganne (bganne) via Lists.Fd.Io
>  wrote:
> >
> > Hmm. Almost if not all of those are due to the newly introduced (by
> me...) vec_set_len() macro https://gerrit.fd.io/r/c/vpp/+/21935
> > vec_reset_len() now use it, and setting len to 0 is always fine
> > whatever
> the vector length, so the ASSERT((l) <= vec_max_len(v)) in
> vec_set_len() confuses Coverity.
> > I am not familiar with the Coverity UI, but if we change the
> > ASSERT() to
> ignore the 0 case, will that silence Coverity? Or do we have to mark
> every single report as a false positive?
> >
> > Ben
> >
> >> -Original Message-
> >> From: vpp-dev@lists.fd.io  On Behalf Of
> >> Noreply Jenkins
> >> Sent: mardi 22 octobre 2019 16:04
> >> To: vpp-dev@lists.fd.io; Ed Kern (ejk) 
> >> Subject: [vpp-dev] Coverity run FAILED as of 2019-10-22 14:00:19
> >> UTC
> >>
> >> Coverity run failed today.
> >>
> >> Current number of outstanding issues are 194 Newly detected: 193
> >> Eliminated: 0
> >> More details can be found at
> >> https://scan.coverity.com/projects/fd-io-
> >> vpp/view_defects
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> >
> > View/Reply Online (#14264):
> > https://lists.fd.io/g/vpp-dev/message/14264
> > Mute This Topic: https://lists.fd.io/mt/36443369/675642
> > Group Owner: vpp-dev+ow...@lists.fd.io
> > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [dmar...@me.com]
> > -=-=-=-=-=-=-=-=-=-=-=-

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

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

Re: [EXTERNAL] [vpp-dev] [review-request] vlib: cli support ctrl-w to erase left word #vpp

[Chris Luke]

Hi Hiroki,

Review comments posted.

Thanks for this. I’m shocked that I managed to miss adding ^W when I added 
command line editing!

Chris.

From:  on behalf of Hiroki Shirokura 
Date: Sunday, August 25, 2019 at 2:42 AM
To: "vpp-dev@lists.fd.io" 
Subject: [EXTERNAL] [vpp-dev] [review-request] vlib: cli support ctrl-w to 
erase left word #vpp

Hi, all
I'm hiroki. thank you for great dataplane project.
I wrote a patch to support Ctrl-W action erasing left word at vpp-CLI. Someone 
can review them please? or If I have some mistake, please tell about one.

https://gerrit.fd.io/r/c/vpp/+/21357

regards, hiroki

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

View/Reply Online (#13838): https://lists.fd.io/g/vpp-dev/message/13838
Mute This Topic: https://lists.fd.io/mt/33022484/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: [EXTERNAL] Re: [vpp-dev] vppctl makes VPP hang-up occasionally

[Chris Luke]

His output is from the stdio console; it's the vppctl session that causes a 
trigger to be loaded.

Chris.

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Ray Kinsella
Sent: Thursday, July 11, 2019 06:42
To: dbar...@cisco.com; Yusuke Tatsumi ; 
vpp-dev@lists.fd.io
Subject: [EXTERNAL] Re: [vpp-dev] vppctl makes VPP hang-up occasionally

Good work

Bit confused - if we are waiting for a timer to trigger here to display a 
welcome and show a prompt.

How does Tatsumi have a prompt in the first place, to type the initial command?

My understanding is the initial memory allocation is happening in response to 
Tatsumi (or anyone) typing in a command.

Ray K

On 09/07/2019 13:05, Dave Barach via Lists.Fd.Io wrote:
> The root cause is obvious from the backtrace in VPP-1711: memory 
> allocator takes a spin-lock, timer interrupt fires, back into the 
> memory allocator, deadlock.
> 
>  
> 
> The [sic] timer interrupt function in .../src/vppinfra/timers.c is a 
> mistake. You managed to find the only place in all of vpp which uses it.
> 
>  
> 
> As a quick 1-line workaround, comment out the “timer_call” shown 
> below, around line 2837 in .../src/vlib/unix/cli.c, e.g. by adding an 
> “if(0)”...
> 
>  
> 
>  /* In case the client doesn't negotiate terminal type, use
> 
>   * a timer to kick off the initial prompt. */
> 
>   if (0)
> 
>   timer_call (unix_cli_file_welcome_timer, cf_index, 1);
> 
>  
> 
> HTH... Dave
> 
>  
> 
> *From:*vpp-dev@lists.fd.io  *On Behalf Of *Yusuke 
> Tatsumi
> *Sent:* Tuesday, July 9, 2019 1:11 AM
> *To:* vpp-dev@lists.fd.io
> *Subject:* [vpp-dev] vppctl makes VPP hang-up occasionally
> 
>  
> 
> Hi all,
> 
>  
> 
> We found that VPP itself freeze once a day under using "vppctl" 
> command repeatedly.
> 
> I think this is a kind of spin-lock problem but I can't understand the 
> root cause.
> 
> See here for details.
> 
> https://jira.fd.io/browse/VPP-1711
> 
>  
> 
> If this goes on, It's hard to operate VPP as production service. So I 
> need help to fix this issue.
> 
> Could anyone help/suggest to this issue?
> 
>  
> 
> Thanks,
> 
> Tatsumi.
> 
>  
> 
> —
> 
> 立見祐介
> 
> ヤフー株式会社
> 
> テクノロジーグループ システム統括本部クラウドプラットフォーム本部技術1
> 部 コンピュート
> 
> TEL: 03-6898-3081
> 
> mail: ytats...@yahoo-corp.jp 
> 
>  
> 
> —
> 
> Yusuke Tatsumi
> 
> Compute team,
> 
> Cloud Platform Division,
> 
> System Management Group
> 
> Yahoo Japan Corporation
> 
> Direct: +81 (3) 6898 3081
> 
> mail: ytats...@yahoo-corp.jp 
> 
>  
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13463): 
> https://lists.fd.io/g/vpp-dev/message/13463
> Mute This Topic: 
> https://protect2.fireeye.com/url?k=d480be3758b37aec.d4809983-2f088dfce
> 1d69bd3=https://lists.fd.io/mt/32402610/675355
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [m...@ashroe.eu]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

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

View/Reply Online (#13487): https://lists.fd.io/g/vpp-dev/message/13487
Mute This Topic: https://lists.fd.io/mt/32428896/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] vppctl makes VPP hang-up occasionally

[Chris Luke]

Sure, and in 99.99% of cases nobody would ever notice, too. For the curious, 
the most straightforward way to tickle this particular feature is something 
like “socat /run/vpp/cli.sock stdio” to get a CLI connection without any TELNET 
negotiation; there’s a ~1s pause while VPP waits for the negotiation to 
complete before it gives up and starts the session regardless.

Chris.

From: Dave Barach (dbarach) 
Sent: Wednesday, July 10, 2019 17:04
To: Luke, Chris ; Yusuke Tatsumi 
; vpp-dev@lists.fd.io
Subject: [EXTERNAL] RE: vppctl makes VPP hang-up occasionally

+1, commenting out the timer_call(...) was a quick hack to make the pain go 
away...

From: Luke, Chris mailto:chris_l...@comcast.com>>
Sent: Wednesday, July 10, 2019 4:55 PM
To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>; Yusuke 
Tatsumi mailto:ytats...@yahoo-corp.jp>>; 
vpp-dev@lists.fd.io
Subject: RE: vppctl makes VPP hang-up occasionally

For the archives, https://gerrit.fd.io/r/#/c/20573/ was merged earlier to 
resolve this issue. We are hoping Tatsumi is able to confirm this, but since it 
is a better approach regardless.

Chris.

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Tuesday, July 9, 2019 08:06
To: Yusuke Tatsumi mailto:ytats...@yahoo-corp.jp>>; 
vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: [EXTERNAL] Re: [vpp-dev] vppctl makes VPP hang-up occasionally

The root cause is obvious from the backtrace in VPP-1711: memory allocator 
takes a spin-lock, timer interrupt fires, back into the memory allocator, 
deadlock.

The [sic] timer interrupt function in .../src/vppinfra/timers.c is a mistake. 
You managed to find the only place in all of vpp which uses it.

As a quick 1-line workaround, comment out the “timer_call” shown below, around 
line 2837 in .../src/vlib/unix/cli.c, e.g. by adding an “if(0)”...

 /* In case the client doesn't negotiate terminal type, use
  * a timer to kick off the initial prompt. */
  if (0)
  timer_call (unix_cli_file_welcome_timer, cf_index, 1);

HTH... Dave

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Yusuke Tatsumi
Sent: Tuesday, July 9, 2019 1:11 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vppctl makes VPP hang-up occasionally

Hi all,

We found that VPP itself freeze once a day under using "vppctl" command 
repeatedly.
I think this is a kind of spin-lock problem but I can't understand the root 
cause.
See here for details.
https://jira.fd.io/browse/VPP-1711

If this goes on, It's hard to operate VPP as production service. So I need help 
to fix this issue.
Could anyone help/suggest to this issue?

Thanks,
Tatsumi.

-
立見 祐介
ヤフー株式会社
テクノロジーグループ システム統括本部 クラウドプラットフォーム本部 技術1部 コンピュート
TEL: 03-6898-3081
mail: ytats...@yahoo-corp.jp

-
Yusuke Tatsumi
Compute team,
Cloud Platform Division,
System Management Group
Yahoo Japan Corporation
Direct: +81 (3) 6898 3081
mail: ytats...@yahoo-corp.jp

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

View/Reply Online (#13485): https://lists.fd.io/g/vpp-dev/message/13485
Mute This Topic: https://lists.fd.io/mt/32402610/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] vppctl makes VPP hang-up occasionally

[Chris Luke]

For the archives, https://gerrit.fd.io/r/#/c/20573/ was merged earlier to 
resolve this issue. We are hoping Tatsumi is able to confirm this, but since it 
is a better approach regardless.

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Tuesday, July 9, 2019 08:06
To: Yusuke Tatsumi ; vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: [EXTERNAL] Re: [vpp-dev] vppctl makes VPP hang-up occasionally

The root cause is obvious from the backtrace in VPP-1711: memory allocator 
takes a spin-lock, timer interrupt fires, back into the memory allocator, 
deadlock.

The [sic] timer interrupt function in .../src/vppinfra/timers.c is a mistake. 
You managed to find the only place in all of vpp which uses it.

As a quick 1-line workaround, comment out the “timer_call” shown below, around 
line 2837 in .../src/vlib/unix/cli.c, e.g. by adding an “if(0)”...

 /* In case the client doesn't negotiate terminal type, use
  * a timer to kick off the initial prompt. */
  if (0)
  timer_call (unix_cli_file_welcome_timer, cf_index, 1);

HTH... Dave

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Yusuke Tatsumi
Sent: Tuesday, July 9, 2019 1:11 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vppctl makes VPP hang-up occasionally

Hi all,

We found that VPP itself freeze once a day under using "vppctl" command 
repeatedly.
I think this is a kind of spin-lock problem but I can't understand the root 
cause.
See here for details.
https://jira.fd.io/browse/VPP-1711

If this goes on, It's hard to operate VPP as production service. So I need help 
to fix this issue.
Could anyone help/suggest to this issue?

Thanks,
Tatsumi.

-
立見 祐介
ヤフー株式会社
テクノロジーグループ システム統括本部 クラウドプラットフォーム本部 技術1部 コンピュート
TEL: 03-6898-3081
mail: ytats...@yahoo-corp.jp

-
Yusuke Tatsumi
Compute team,
Cloud Platform Division,
System Management Group
Yahoo Japan Corporation
Direct: +81 (3) 6898 3081
mail: ytats...@yahoo-corp.jp

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

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

Re: [EXTERNAL] Re: [vpp-dev] VPP Router Plugin or alternatives

[Chris Luke]

TCP-MD5 may technically be obsolete, but it’s used widely for protecting BGP 
sessions in the real world. Noting the comments in 
https://tools.ietf.org/html/rfc5925#page-35 that any AO implementation SHOULD 
support MD5, I would suggest starting with an RFC 2385 TCP-MD5 implementation. 
It may be legacy, but you need it anyway and it gets you significant real world 
coverage immediately.

Chris.


From: vpp-dev@lists.fd.io  On Behalf Of Burt Silverman
Sent: Friday, July 5, 2019 09:09
To: Jim Thompson 
Cc: Steuer Heribert ; vpp-dev 
Subject: [EXTERNAL] Re: [vpp-dev] VPP Router Plugin or alternatives

>TCP-MD5 needs to be implemented in the host stack before a standards-compliant 
>BGP could be accomplished.

Or TCP-AO, RFC 5925, instead, as it has obsoleted RFC 2385?

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

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

Re: [EXTERNAL] [vpp-dev] VPP OOM crash in CLI

[Chris Luke]

Hi Andreas,

On deeper analysis of the stack trace I found no regression in the pager code. 
The symptoms appear to be from the final overflow output buffer. 
unix_cli_add_pending_output is designed to write to the output descriptor 
unless it's using a buffer. The buffer only ever gets used if writing to the 
descriptor fails; typically this would happen only if there was a signal 
(EAGAIN) or it wasn't able to deliver the whole request, e.g. because the 
socket send buffer is full or the tty can't keep up; these are rare. When this 
happens the undelivered bytes are copied to a buffer and an event system 
triggered to poll the descriptor for when it is able to deliver data again; 
until the buffer is emptied, it will continue to accumulate bytes.

Your stack trace suggests this is what is happening. 
unix_cli_add_pending_output would only try to resize a memory block if it was 
executing the line that appends to the buffer. It's asking for ~40MB 
(presumably the size of the accumulation so far), and that resize request 
bombs, apparently ungracefully. This is where it becomes interesting; this 
happens during the memcpy operation that copies the data to its new resized 
location. This implies VPP allocated the memory from the heap successfully and 
that ultimately the process ended by external action. VPP's memory manager did 
not complain.

You don't include the details of the signal that ended the process, only a 
stipulation that it was an OOM error.

Was it Linux that reported the OOM? In which case my inclination would be to 
look at the balance of memory usage across the whole system, not just VPP. 
VPP's default heap is 1GB, and add any hugepages allocated for packet buffers.

That said, it is a reasonable suggestion to cap how large this overflow buffer 
can grow to avoid unchecked memory bloat when large amounts of terminal output 
cannot be delivered, if only to protect VPP. However in this specific case I 
believe this would only stay the inevitable OOM for a short period of time.

Chris.

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Chris Luke
> Sent: Thursday, May 16, 2019 6:42
> To: Andreas Schultz 
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [EXTERNAL] [vpp-dev] VPP OOM crash in CLI
> 
> > -Original Message-
> > From: Andreas Schultz  Am Mi., 15. Mai
> > 2019 um 19:31 Uhr schrieb Luke, Chris
> > :
> > >
> > > The pager in the CLI retains output up to a certain amount but then
> > > gives
> > up and switches to pass-through after a certain number of lines
> > (default is 10). If the output doesn't have newlines, or that
> > default has been altered, then it will try to use more memory.
> > >
> > > In this case it appears to die while trying to increase the buffer
> > > to ~40MB in
> > size, which is quite a lot; are these long lines that it is trying to 
> > display?
> >
> > That was the default FIB table output ('show ip fib' if I remember 
> > correctly).
> > Just with about 30 entries. Same thing would probably happen on a
> > `show interfaces` command.
> 
> Okay, when I get a chance I'll look at the buffer size limit check in case of 
> a
> regression since it was written. The intended behavior is that it buffers
> output in memory so that you can page through it, but once it hits that limit 
> it
> gives up and dumps both the current contents of the buffer, and any future
> content, directly to the output. At the time I chose to not redirect it to a 
> file,
> or similar, to avoid introducing more syscalls than necessary at runtime.
> 
> Chris.
> 
> >
> > Andreas
> >
> > >
> > > Chris.
> > >
> > > -Original Message-
> > > From: vpp-dev@lists.fd.io  On Behalf Of Andreas
> > > Schultz
> > > Sent: Wednesday, May 15, 2019 12:39 PM
> > > To: vpp-dev@lists.fd.io
> > > Subject: [EXTERNAL] [vpp-dev] VPP OOM crash in CLI
> > >
> > > Hi,
> > >
> > > It seems VPPs CLI is not very good at dealing with large FIBs or
> > > lots of
> > interfaces. I know the CLI is a debug tool only, but IMHO it should
> > not crash VPP that easily.
> > > On a fib with 300k entries, the pager does not work and I get a OOM
> crash:
> > >
> > > (gdb) bt
> > > #0  clib_mov16 (src=, dst=) at
> > > /usr/src/vpp/src/vppinfra/memcpy_sse3.h:60
> > > #1  clib_mov32 (src=, dst=) at
> > > /usr/src/vpp/src/vppinfra/memcpy_sse3.h:67
> > > #2  clib_mov64 (src=, dst=) at
> > > /usr/src/vpp/src/vppinfra/memcpy_sse3.h:73
> > > #3  clib_mov128 (src=, dst=) at
> > > /usr/src/vpp/src/vppinfra/memcpy_sse3.h:81
> > > #4  cli

Re: [EXTERNAL] [vpp-dev] VPP OOM crash in CLI

[Chris Luke]

> -Original Message-
> From: Andreas Schultz 
> Am Mi., 15. Mai 2019 um 19:31 Uhr schrieb Luke, Chris
> :
> >
> > The pager in the CLI retains output up to a certain amount but then gives
> up and switches to pass-through after a certain number of lines (default is
> 10). If the output doesn't have newlines, or that default has been
> altered, then it will try to use more memory.
> >
> > In this case it appears to die while trying to increase the buffer to ~40MB 
> > in
> size, which is quite a lot; are these long lines that it is trying to display?
> 
> That was the default FIB table output ('show ip fib' if I remember correctly).
> Just with about 30 entries. Same thing would probably happen on a
> `show interfaces` command.

Okay, when I get a chance I'll look at the buffer size limit check in case of a 
regression since it was written. The intended behavior is that it buffers 
output in memory so that you can page through it, but once it hits that limit 
it gives up and dumps both the current contents of the buffer, and any future 
content, directly to the output. At the time I chose to not redirect it to a 
file, or similar, to avoid introducing more syscalls than necessary at runtime.

Chris.

> 
> Andreas
> 
> >
> > Chris.
> >
> > -Original Message-
> > From: vpp-dev@lists.fd.io  On Behalf Of Andreas
> > Schultz
> > Sent: Wednesday, May 15, 2019 12:39 PM
> > To: vpp-dev@lists.fd.io
> > Subject: [EXTERNAL] [vpp-dev] VPP OOM crash in CLI
> >
> > Hi,
> >
> > It seems VPPs CLI is not very good at dealing with large FIBs or lots of
> interfaces. I know the CLI is a debug tool only, but IMHO it should not crash
> VPP that easily.
> > On a fib with 300k entries, the pager does not work and I get a OOM crash:
> >
> > (gdb) bt
> > #0  clib_mov16 (src=, dst=) at
> > /usr/src/vpp/src/vppinfra/memcpy_sse3.h:60
> > #1  clib_mov32 (src=, dst=) at
> > /usr/src/vpp/src/vppinfra/memcpy_sse3.h:67
> > #2  clib_mov64 (src=, dst=) at
> > /usr/src/vpp/src/vppinfra/memcpy_sse3.h:73
> > #3  clib_mov128 (src=, dst=) at
> > /usr/src/vpp/src/vppinfra/memcpy_sse3.h:81
> > #4  clib_mov256 (src=0x7febd6d2ff30 "on184760 (p2p)\n[@0]: ipv4 via
> > 0.0.0.0 upf_session184760: mtu:9000\npath:[184809] pl-index:184809 ip4
> > weight=1 pref=0 attached-nexthop:  oper-flags:resolved, cfg-
> flags:attached,\n  10.43.104.28 upf_sessi"...,
> > dst=0x7febd97aff30 "on184760 (p2p)\n[@0]: ipv4 via 0.0.0.0
> > upf_session184760: mtu:9000\npath:[184809] pl-index:184809 ip4
> > weight=1 pref=0 attached-nexthop:  oper-flags:resolved, cfg-
> flags:attached,\n  10.43.104.28 upf_sessi"...)
> > at /usr/src/vpp/src/vppinfra/memcpy_sse3.h:88
> > #5  clib_memcpy_fast (n=40232024, src=0x7febd6d2ff30,
> > dst=0x7febd97aff30) at /usr/src/vpp/src/vppinfra/memcpy_sse3.h:325
> > #6  vec_resize_allocate_memory (v=v@entry=0x7febd4b9c01c,
> > length_increment=length_increment@entry=201, data_bytes=40232076,
> > header_bytes=, header_bytes@entry=0,
> > data_align=data_align@entry=8) at /usr/src/vpp/src/vppinfra/vec.c:95
> > #7  0x76ae4233 in _vec_resize_inline (data_align= > out>, header_bytes=, data_bytes=,
> > length_increment=, v=) at
> > /usr/src/vpp/src/vppinfra/vec.h:147
> > #8  unix_cli_add_pending_output (uf=0x7ff2704bfe2c,
> > buffer=0x7fffbabeb96c "path:[209906] pl-index:209906 ip4 weight=1
> > pref=0 attached-nexthop:  oper-flags:resolved, cfg-flags:attached,\n
> > 10.12.107.171 upf_session209858 (p2p)\n[@0]: ipv4 via 0.0.0.0
> > upf_session209858: mtu:9000"..., buffer_bytes=201, cf=)
> > at /usr/src/vpp/src/vlib/unix/cli.c:544
> > #9  0x76ae5cb7 in unix_vlib_cli_output_raw
> > (cf=cf@entry=0x7fffb93dc69c, uf=uf@entry=0x7ff2704bfe2c,
> > buffer=, buffer_bytes=) at
> > /usr/src/vpp/src/vlib/unix/cli.c:654
> > #10 0x76ae6475 in unix_vlib_cli_output_raw
> > (buffer_bytes=, buffer=,
> > uf=0x7ff2704bfe2c, cf=0x7fffb93dc69c) at
> > /usr/src/vpp/src/vlib/unix/cli.c:620
> > #11 unix_vlib_cli_output_cooked (cf=0x7fffb93dc69c, uf=0x7ff2704bfe2c,
> > buffer=0x7fffbabeb96c "path:[209906] pl-index:209906 ip4 weight=1
> > pref=0 attached-nexthop:  oper-flags:resolved, cfg-flags:attached,\n
> > 10.12.107.171 upf_session209858 (p2p)\n[@0]: ipv4 via 0.0.0.0
> > upf_session209858: mtu:9000"..., buffer_bytes=201)
> > at /usr/src/vpp/src/vlib/unix/cli.c:687
> > #12 0x76a8c79b in vlib_cli_output (vm=vm@entry=0x76d06700
> > , fmt=fmt@entry=0x77889987 "%U") at
> > /usr/src/vpp/src/vlib/cli.c:742
> > #13 0x777ffe23 in show_fib_path_command (vm=0x76d06700
> > , input=, cmd=) at
> > /usr/src/vpp/src/vnet/fib/fib_path.c:2737
> > #14 0x76a8caa6 in vlib_cli_dispatch_sub_commands
> > (vm=vm@entry=0x76d06700 ,
> > cm=cm@entry=0x76d06900 ,
> > input=input@entry=0x7fffbac5bf60, parent_command_index= > out>) at /usr/src/vpp/src/vlib/cli.c:607
> > #15 0x76a8d0e7 in vlib_cli_dispatch_sub_commands
> > (vm=vm@entry=0x76d06700 ,
> > cm=cm@entry=0x76d06900 ,
> > 

Re: [EXTERNAL] [vpp-dev] VPP OOM crash in CLI

[Chris Luke]

The pager in the CLI retains output up to a certain amount but then gives up 
and switches to pass-through after a certain number of lines (default is 
10). If the output doesn't have newlines, or that default has been altered, 
then it will try to use more memory.

In this case it appears to die while trying to increase the buffer to ~40MB in 
size, which is quite a lot; are these long lines that it is trying to display?

Chris.

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Andreas Schultz
Sent: Wednesday, May 15, 2019 12:39 PM
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] [vpp-dev] VPP OOM crash in CLI

Hi,

It seems VPPs CLI is not very good at dealing with large FIBs or lots of 
interfaces. I know the CLI is a debug tool only, but IMHO it should not crash 
VPP that easily.
On a fib with 300k entries, the pager does not work and I get a OOM crash:

(gdb) bt
#0  clib_mov16 (src=, dst=) at
/usr/src/vpp/src/vppinfra/memcpy_sse3.h:60
#1  clib_mov32 (src=, dst=) at
/usr/src/vpp/src/vppinfra/memcpy_sse3.h:67
#2  clib_mov64 (src=, dst=) at
/usr/src/vpp/src/vppinfra/memcpy_sse3.h:73
#3  clib_mov128 (src=, dst=) at
/usr/src/vpp/src/vppinfra/memcpy_sse3.h:81
#4  clib_mov256 (src=0x7febd6d2ff30 "on184760 (p2p)\n[@0]: ipv4 via
0.0.0.0 upf_session184760: mtu:9000\npath:[184809] pl-index:184809 ip4
weight=1 pref=0 attached-nexthop:  oper-flags:resolved, cfg-flags:attached,\n  
10.43.104.28 upf_sessi"...,
dst=0x7febd97aff30 "on184760 (p2p)\n[@0]: ipv4 via 0.0.0.0
upf_session184760: mtu:9000\npath:[184809] pl-index:184809 ip4
weight=1 pref=0 attached-nexthop:  oper-flags:resolved, cfg-flags:attached,\n  
10.43.104.28 upf_sessi"...)
at /usr/src/vpp/src/vppinfra/memcpy_sse3.h:88
#5  clib_memcpy_fast (n=40232024, src=0x7febd6d2ff30,
dst=0x7febd97aff30) at /usr/src/vpp/src/vppinfra/memcpy_sse3.h:325
#6  vec_resize_allocate_memory (v=v@entry=0x7febd4b9c01c, 
length_increment=length_increment@entry=201, data_bytes=40232076, 
header_bytes=, header_bytes@entry=0,
data_align=data_align@entry=8) at /usr/src/vpp/src/vppinfra/vec.c:95
#7  0x76ae4233 in _vec_resize_inline (data_align=, header_bytes=, data_bytes=,
length_increment=, v=) at
/usr/src/vpp/src/vppinfra/vec.h:147
#8  unix_cli_add_pending_output (uf=0x7ff2704bfe2c,
buffer=0x7fffbabeb96c "path:[209906] pl-index:209906 ip4 weight=1
pref=0 attached-nexthop:  oper-flags:resolved, cfg-flags:attached,\n
10.12.107.171 upf_session209858 (p2p)\n[@0]: ipv4 via 0.0.0.0
upf_session209858: mtu:9000"..., buffer_bytes=201, cf=)
at /usr/src/vpp/src/vlib/unix/cli.c:544
#9  0x76ae5cb7 in unix_vlib_cli_output_raw (cf=cf@entry=0x7fffb93dc69c, 
uf=uf@entry=0x7ff2704bfe2c, buffer=, buffer_bytes=) at
/usr/src/vpp/src/vlib/unix/cli.c:654
#10 0x76ae6475 in unix_vlib_cli_output_raw (buffer_bytes=, buffer=, uf=0x7ff2704bfe2c, cf=0x7fffb93dc69c) at
/usr/src/vpp/src/vlib/unix/cli.c:620
#11 unix_vlib_cli_output_cooked (cf=0x7fffb93dc69c, uf=0x7ff2704bfe2c,
buffer=0x7fffbabeb96c "path:[209906] pl-index:209906 ip4 weight=1
pref=0 attached-nexthop:  oper-flags:resolved, cfg-flags:attached,\n
10.12.107.171 upf_session209858 (p2p)\n[@0]: ipv4 via 0.0.0.0
upf_session209858: mtu:9000"..., buffer_bytes=201)
at /usr/src/vpp/src/vlib/unix/cli.c:687
#12 0x76a8c79b in vlib_cli_output (vm=vm@entry=0x76d06700 
, fmt=fmt@entry=0x77889987 "%U") at
/usr/src/vpp/src/vlib/cli.c:742
#13 0x777ffe23 in show_fib_path_command (vm=0x76d06700 
, input=, cmd=) at
/usr/src/vpp/src/vnet/fib/fib_path.c:2737
#14 0x76a8caa6 in vlib_cli_dispatch_sub_commands
(vm=vm@entry=0x76d06700 ,
cm=cm@entry=0x76d06900 , 
input=input@entry=0x7fffbac5bf60, parent_command_index=) at /usr/src/vpp/src/vlib/cli.c:607
#15 0x76a8d0e7 in vlib_cli_dispatch_sub_commands
(vm=vm@entry=0x76d06700 ,
cm=cm@entry=0x76d06900 , 
input=input@entry=0x7fffbac5bf60, parent_command_index=) at /usr/src/vpp/src/vlib/cli.c:568
#16 0x76a8d0e7 in vlib_cli_dispatch_sub_commands
(vm=vm@entry=0x76d06700 ,
cm=cm@entry=0x76d06900 , 
input=input@entry=0x7fffbac5bf60,
parent_command_index=parent_command_index@entry=0) at
/usr/src/vpp/src/vlib/cli.c:568
#17 0x76a8d3b4 in vlib_cli_input (vm=0x76d06700 , 
input=input@entry=0x7fffbac5bf60,
function=function@entry=0x76ae6900 ,
function_arg=function_arg@entry=0) at /usr/src/vpp/src/vlib/cli.c:707
#18 0x76ae84c6 in unix_cli_process_input (cm=0x76d07040 
, cli_file_index=0) at
/usr/src/vpp/src/vlib/unix/cli.c:2420
#19 unix_cli_process (vm=0x76d06700 , rt=0x7fffbac4b000, 
f=) at
/usr/src/vpp/src/vlib/unix/cli.c:2536
#20 0x76aa4e06 in vlib_process_bootstrap (_a=) at 
/usr/src/vpp/src/vlib/main.c:1469
#21 0x765a5864 in clib_calljmp () from
/usr/src/vpp/build-root/install-vpp-native/vpp/lib/libvppinfra.so.19.08
#22 0x7fffb95ffb00 in ?? ()
#23 0x76aaa971 in vlib_process_startup (f=0x0, p=0x7fffbac4b000, 
vm=0x76d06700 ) at

Re: [EXTERNAL] [vpp-dev] Pager Buffer limit

[Chris Luke]

I should add that after the pager limit is exceeded, it simply disables the 
pager (if that does not work and it eats the output, please let me know!)

This is to limit memory consumption more than anything since it has to keep all 
the CLI output in memory to be able to paginate it. 100K lines was thought a 
reasonable default limit for this – at 80 characters per line this would be 
about 8MB+overhead and thus doesn’t put too much pressure on the heap. I would 
recommend you use vppctl and send the output to a file, or pipe to less, if you 
really do generate that much output.

Chris.

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Chris Luke
Sent: Thursday, September 06, 2018 9:18 AM
To: siddarth rai ; vpp-dev@lists.fd.io
Subject: Re: [EXTERNAL] [vpp-dev] Pager Buffer limit

Siddarth,

A quick Google reveals these resources in the first three responses that may 
answer your question:


· 
https://docs.fd.io/vpp/16.12/clicmd_vlib_vlib_unix_cli_c.html#clicmd_set_terminal_pager

· 
https://wiki.fd.io/view/VPP/Command-line_Arguments#.22unix.22_parameters

· https://docs.fd.io/vpp/16.12/syscfg_vlib_vlib_unix.html

Chris.

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
[mailto:vpp-dev@lists.fd.io] On Behalf Of siddarth rai
Sent: Thursday, September 06, 2018 7:07 AM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [EXTERNAL] [vpp-dev] Pager Buffer limit

Hi,

I am working on creating a VPP cli which dumps a lot of info.

Is there any limitation to the number of lines we can print in a paged format 
using vlib_cli_output ? I am not able to print more than 100K lines.

Beyond that i get the error "-- pager buffer overflowed --" .
Also, how do I modify this limit ?

Thanks & Regards,
Siddarth
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [EXTERNAL] [vpp-dev] Pager Buffer limit

[Chris Luke]

Siddarth,

A quick Google reveals these resources in the first three responses that may 
answer your question:


· 
https://docs.fd.io/vpp/16.12/clicmd_vlib_vlib_unix_cli_c.html#clicmd_set_terminal_pager

· 
https://wiki.fd.io/view/VPP/Command-line_Arguments#.22unix.22_parameters

· https://docs.fd.io/vpp/16.12/syscfg_vlib_vlib_unix.html

Chris.

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of siddarth rai
Sent: Thursday, September 06, 2018 7:07 AM
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] [vpp-dev] Pager Buffer limit

Hi,

I am working on creating a VPP cli which dumps a lot of info.

Is there any limitation to the number of lines we can print in a paged format 
using vlib_cli_output ? I am not able to print more than 100K lines.

Beyond that i get the error "-- pager buffer overflowed --" .
Also, how do I modify this limit ?

Thanks & Regards,
Siddarth
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10409): https://lists.fd.io/g/vpp-dev/message/10409
Mute This Topic: https://lists.fd.io/mt/25237417/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] git.fd.io expired certificate error

[Chris Luke]

FWIW, this is why Coverity scans have stopped, too.

Chris (back from PTO)

From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Monday, August 6, 2018 11:21
To: helpd...@fd.io
Cc: vpp-dev@lists.fd.io
Subject: [EXTERNAL] [vpp-dev] git.fd.io expired certificate error

Please fix AYEC:

Chrome is complaining: "This server could not prove that it is git.fd.io; its 
security certificate expired 3 days ago. This may be caused by a 
misconfiguration or an attacker intercepting your connection. Your computer's 
clock is currently set to Monday, August 6, 2018. Does that look right? If not, 
you should correct your system's clock and then refresh this page."

The cert appears to have expired:

Common Name (CN) git.fd.io
Organization (O) 
Organizational Unit (OU)   
Common Name (CN) Let's Encrypt Authority X3
Organization (O) Let's Encrypt
Organizational Unit (OU)   
Issued On  Saturday, May 5, 2018 at 1:35:20 PM
Expires On Friday, August 3, 2018 at 1:35:20 PM
SHA-256 Fingerprint   05 99 81 C2 61 86 D9 5B C2 83 8A B9 FC 7E 51 9B
0D 2A 1C 57 5B 91 C0 9A AB 97 7F EC 84 23 A2 03
SHA-1 Fingerprint 16 7A E3 74 90 DE DE A5 64 26 8B FC 6F CC 0C A6
AE 60 45 D9

Thanks... Dave

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

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

Re: [EXTERNAL] Re: [vpp-dev] 18.07 RC1: stable/1807 branch pulled, master reopened

[Chris Luke]

I do not recall a discussion about this.

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Damjan 
Marion via Lists.Fd.Io
Sent: Wednesday, July 18, 2018 7:19 AM
To: Edward Warnicke 
Cc: vpp-dev@lists.fd.io
Subject: [EXTERNAL] Re: [vpp-dev] 18.07 RC1: stable/1807 branch pulled, master 
reopened


I can see that we have 18.11-rc0 tag. Have we decided to break our 3-month 
cadence?

--
Damjan


On 17 Jul 2018, at 04:27, Edward Warnicke 
mailto:hagb...@gmail.com>> wrote:

We've reached 18.07 RC1.  The stable/1807 branch has been pulled.

Master is reopened.

Due to a maintenance window today, I have not been able to test merge pushing 
of packages to apt/yum repos for stable/1807.  I will do so tomorrow.

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

View/Reply Online (#9851): https://lists.fd.io/g/vpp-dev/message/9851
Mute This Topic: https://lists.fd.io/mt/23538528/675642
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[dmar...@me.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

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

Re: [EXTERNAL] Re: [vpp-dev] (nten-vedge-ml 357) Re: [vpp] VXLAN arp response packet is dropped

[Chris Luke]

Satomi,

Please consider using services like pastebin or gist for posting text files. 
Attachments like zip files, and especially password protected ones,  don't 
really belong on mailing lists.

Not least because my security people get excited and delete such messages on 
sight (antivirus can't scan inside), but they're wasteful when you consider 
everyone on the list gets a copy.

Thanks,
Chris.

> -Original Message-
> From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of 
> Sent: Wednesday, July 18, 2018 5:00 AM
> To: Neale Ranns (nranns) ; vpp-dev@lists.fd.io
> Cc: Norimasa Asai (noasai) ; エッジ仮想化hcoML
> ; 小柳達也様
> ; N転P_西岡孟朗様
> 
> Subject: [EXTERNAL] Re: [vpp-dev] (nten-vedge-ml 357) Re: [vpp] VXLAN arp
> response packet is dropped
> 
> The password is here.
> 
> E!(k,g
> 
> On 2018/07/18 17:58, 井上里美 wrote:
> > Hi, neale san,
> >
> > Thank you for your reply.
> > Sure!
> >
> > Satomi
> >
> > On 2018/07/18 17:27, Neale Ranns (nranns) wrote:
> >> Can I see the packet trace?
> >>
> >> /neale
> >>
> >> -Original Message-
> >> From: 井上里美 
> >> Date: Wednesday, 18 July 2018 at 09:54
> >> To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io"
> >> 
> >> Cc: "Norimasa Asai (noasai)" , エッジ仮想化hcoML
> >> , 小柳達也様
> >> , N転P_西岡孟朗様
> >> 
> >> Subject: [vpp] VXLAN arp response packet is dropped
> >>
> >>  Hi neale san,
> >>      Thank you for your reply.
> >>  We used a vpp packet trace.
> >>  show trace is no error but on the caputure device,ARP request
> >> packet is
> >>  droped.
> >>  It happend the same event even L2.
> >>      Could you give me some advice?
> >>      【Architecture】
> >>  　 ＿＿
> >>  ｜　　  ｜→caputure device→IXIA(port 2)
> >>  ｜VPP｜
> >>  ｜　　　｜←IXIA(port 1)
> >>  ｜＿＿｜
> >>      On 2018/07/06 21:39, Neale Ranns (nranns) wrote:
> >>  > Hi Satomi
> >>  >
> >>  > Debugging packet loss is much easier with a VPP packet trace…
> >>  >
> >>  > Regards,
> >>  > neale
> >>  >
> >>  > -Original Message-
> >>  > From:  on behalf of 井上里美
> >> 
> >>  > Date: Friday, 6 July 2018 at 12:38
> >>  > To: "vpp-dev@lists.fd.io" 
> >>  > Cc: "Norimasa Asai (noasai)" , エッジ仮想化
> hcoML
> >> , 小柳達也様
> >> , N転P_西岡孟朗様
> >> 
> >>  > Subject: [vpp-dev] [pw] [vpp] VXLAN arp response packet is
> >> dropped
> >>  >
> >>  >  The password is here.
> >>  >  1j^?iKvC]C;%
> >>  >
> >>  >  On 2018/07/06 19:37, 井上里美 wrote:
> >>  >  > Hi VPP Team,
> >>  >  >
> >>  >  > I'm Satomi Inoue and I belong to NTT laboratories.
> >>  >  > Could you tell me why ARP response packet is dropped?
> >>  >  >
> >>  >  > We set up vxlan while looking at
> >>  >  > ”Using_VPP_as_a_VXLAN_Tunnel_Terminator”manual.
> >>  >  > The procedure is as follows.
> >>  >  >
> >>  >  > [The result]
> >>  >  > ・ARP request packet : IXIA(port2)→VPP→IXIA(port1):OK
> >>  >  > ・ARP response packet : IXIA(port1)→VPP→IXIA(port2):NG
> >>  >  > 　→We checked it by trace command. Loopback interface in
> >> VPP drop the
> >>  >  > ARP response packet.
> >>  >  >
> >>  >  > [set up vxlan]
> >>  >  > 1. Create sub-interface
> >>  >  > vpp# create sub-interfaces
> >> VirtualFunctionEthernet0/9/0 1
> >>  >  > vpp# set interface state
> >> VirtualFunctionEthernet0/9/0.1 up
> >>  >  >
> >>  >  > 2. Create bridge-domain
> >>  >  > create bridge-domain 10001 learn 1 forward 1
> >> uu-flood 1 arp-term 0
> >>  >  >
> >>  >  > 3. Create Loopback interface
> >>  >  > vpp# loopback create mac 1a:2b:3c:4d:5e:6f
> >>  >  > vpp# set interface state loop0 up
> >>  >  > vpp# set interface ip address loop0 1.1.1.1/32
> >>  >  > vpp# set interface ip table loop0 7
> >>  >  >
> >>  >  > 4. Apply loopback interface to bride-domain
> >>  >  > vpp# set interface l2 bridge loop0 10001 bvi
> >>  >  >
> >>  >  > 5.Apply sub-interface to bride-domain
> >>  >  > vpp# set interface l2 bridge
> >> VirtualFunctionEthernet0/9/0.1 10001 0
> >>  >  >
> >>  >  > 6.Create VXLAN tunnel
> >>  >  > vpp# create vxlan tunnel src 1.1.1.1 dst 20.10.0.1
> >> vni 10001
> >>  >  > encap-vrf-id 7 decap-next l2
> >>  >  > vpp# set interface l2 bridge vxlan_tunnel0 10001 1
> >>  >  >
> >>  >  > Regards,
> >>  >  > Satomi
> >>  >
> >>  >  --
> >>  >
> >>  >
> >>  >
> >>  >
> >>  >
> >>      --
> >>  -
> >>      井上里美(Satomi Inoue)
> >>  〒180-8585 東京都武蔵野市緑町3-9-11
> >>  PHONE:0422-59-4151
> >>  E-MAIL:inoue.sat...@lab.ntt.co.jp
> >>
> >
> 
> --
> 

Re: [EXTERNAL] [vpp-dev] Using Ncurses library in VPP CLI

[Chris Luke]

Correction, it seems the modern ncurses, built with wide character support, 
does support multiple sessions. It’s poorly documented and would still be 
difficult to integrate properly. I stand by the position that fancy rendering 
belongs in an API-driven application.

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of Chris Luke
Sent: Wednesday, July 4, 2018 9:07
To: david.leitch@gmail.com; vpp-dev@lists.fd.io
Subject: Re: [EXTERNAL] [vpp-dev] Using Ncurses library in VPP CLI

David,

Ncurses will never work for socket connections since it makes assumptions about 
having a tty device and only uses stdin/stdout. It also does not allow more 
than one ncurses instance at the same time; all its state is global, so it will 
never work for multiple CLI sessions.

The CLI code does track if the session is ANSI capable so you can emit your own 
sequences. If you have fancy things in mind, you’re probably generally better 
off writing an independent application that makes use of the API. (which is 
what I did for the – as yet unreleased – vpptop utility)

One key issue with the snippet below, if you built it in to a VPP CLI command, 
is it will block the main thread indefinitely waiting for that keypress. There 
are ways around that, but not the stdin/stdout/tty/session issue.

Chris

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of 
david.leitch@gmail.com<mailto:david.leitch@gmail.com>
Sent: Wednesday, July 4, 2018 4:00
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [EXTERNAL] [vpp-dev] Using Ncurses library in VPP CLI

Hi,
Is it possible to use Ncurses library function on VPP CLI Command to have nice 
view,
i used  a basic sample but does not work, compile with -lncurses and use this 
commands :

  initscr(); /* Start curses mode  */
 printw("Hello World !!!"); /* Print Hello World  */
 refresh(); /* Print it on to the real screen */
 getch();   /* Wait for user input*/
 endwin();  /* End curses mode*/


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

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

Re: [EXTERNAL] [vpp-dev] Using Ncurses library in VPP CLI

[Chris Luke]

David,

Ncurses will never work for socket connections since it makes assumptions about 
having a tty device and only uses stdin/stdout. It also does not allow more 
than one ncurses instance at the same time; all its state is global, so it will 
never work for multiple CLI sessions.

The CLI code does track if the session is ANSI capable so you can emit your own 
sequences. If you have fancy things in mind, you’re probably generally better 
off writing an independent application that makes use of the API. (which is 
what I did for the – as yet unreleased – vpptop utility)

One key issue with the snippet below, if you built it in to a VPP CLI command, 
is it will block the main thread indefinitely waiting for that keypress. There 
are ways around that, but not the stdin/stdout/tty/session issue.

Chris

From: vpp-dev@lists.fd.io  On Behalf Of 
david.leitch@gmail.com
Sent: Wednesday, July 4, 2018 4:00
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] [vpp-dev] Using Ncurses library in VPP CLI

Hi,
Is it possible to use Ncurses library function on VPP CLI Command to have nice 
view,
i used  a basic sample but does not work, compile with -lncurses and use this 
commands :

  initscr(); /* Start curses mode  */
 printw("Hello World !!!"); /* Print Hello World  */
 refresh(); /* Print it on to the real screen */
 getch();   /* Wait for user input*/
 endwin();  /* End curses mode*/


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

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

Re: [EXTERNAL] Re: [vpp-dev] VPP ARM Build/Installation

[Chris Luke]

My best guess, not knowing your environment, is that you don’t have 
ca-certificates installed.

From: Jit Mehta 
Sent: Monday, July 2, 2018 16:50
To: Luke, Chris 
Cc: Brian Brooks ; vpp-dev@lists.fd.io
Subject: [EXTERNAL] Re: [vpp-dev] VPP ARM Build/Installation

All,

I see the below error when running 'apt-get update/install' during VPP binaries 
installation based on these steps: 
https://wiki.fd.io/view/VPP/Installing_VPP_binaries_from_packages#Ubuntu.2FDebian

Any pointers on how to fix this?

Thanks
Jit


root@ubuntu:/home/lab/Vpp/src# cat /etc/apt/sources.list.d/99fd.io.list

deb [trusted=yes] 
https://nexus.fd.io/content/repositories/fd.io.stable.1804.ubuntu.xenial.main/ 
./



root@ubuntu:/home/lab/Vpp/src# sudo apt-get update

Hit:1 http://ports.ubuntu.com/ubuntu-ports xenial InRelease

Hit:2 http://ports.ubuntu.com/ubuntu-ports xenial-updates InRelease

Ign:3 
https://nexus.fd.io/content/repositories/fd.io.stable.1804.ubuntu.xenial.main 
./ InRelease

Hit:4 http://ports.ubuntu.com/ubuntu-ports xenial-backports InRelease

Hit:5 http://ports.ubuntu.com/ubuntu-ports xenial-security InRelease

Ign:6 
https://nexus.fd.io/content/repositories/fd.io.stable.1804.ubuntu.xenial.main 
./ Release

Ign:7 
https://nexus.fd.io/content/repositories/fd.io.stable.1804.ubuntu.xenial.main 
./ Packages

Ign:8 
https://nexus.fd.io/content/repositories/fd.io.stable.1804.ubuntu.xenial.main 
./ Translation-en

Ign:7 
https://nexus.fd.io/content/repositories/fd.io.stable.1804.ubuntu.xenial.main 
./ Packages

Ign:8 
https://nexus.fd.io/content/repositories/fd.io.stable.1804.ubuntu.xenial.main 
./ Translation-en

Ign:7 
https://nexus.fd.io/content/repositories/fd.io.stable.1804.ubuntu.xenial.main 
./ Packages

Ign:8 
https://nexus.fd.io/content/repositories/fd.io.stable.1804.ubuntu.xenial.main 
./ Translation-en

Ign:7 
https://nexus.fd.io/content/repositories/fd.io.stable.1804.ubuntu.xenial.main 
./ Packages

Ign:8 
https://nexus.fd.io/content/repositories/fd.io.stable.1804.ubuntu.xenial.main 
./ Translation-en

Ign:7 
https://nexus.fd.io/content/repositories/fd.io.stable.1804.ubuntu.xenial.main 
./ Packages

Ign:8 
https://nexus.fd.io/content/repositories/fd.io.stable.1804.ubuntu.xenial.main 
./ Translation-en

Err:7 
https://nexus.fd.io/content/repositories/fd.io.stable.1804.ubuntu.xenial.main 
./ Packages

  server certificate verification failed. CAfile: 
/etc/ssl/certs/ca-certificates.crt CRLfile: none

Ign:8 
https://nexus.fd.io/content/repositories/fd.io.stable.1804.ubuntu.xenial.main 
./ Translation-en

Reading package lists... Done

E: Failed to fetch 
https://nexus.fd.io/content/repositories/fd.io.stable.1804.ubuntu.xenial.main/./Packages
  server certificate verification failed. CAfie

E: Some index files failed to download. They have been ignored, or old ones 
used instead.



root@ubuntu:/home/lab/Vpp/src# sudo apt-get install vpp vpp-lib

Reading package lists... Done

Building dependency tree

Reading state information... Done

E: Unable to locate package vpp

E: Unable to locate package vpp-lib

root@ubuntu:/home/lab/Vpp/src#


On Mon, Jul 2, 2018 at 11:55 AM, Jit Mehta 
mailto:jitendra.harshad...@gmail.com>> wrote:
Thanks for your responses  Chris, Brian, Sirshak and Gabrielle.

I will try this out and post back if I run into any issues.

Thanks!
Jit

On Mon, Jul 2, 2018 at 9:59 AM, Luke, Chris 
mailto:chris_l...@comcast.com>> wrote:
Ubuntu aarch64 packages use the same recipe as amd64; 
https://wiki.fd.io/view/VPP/Installing_VPP_binaries_from_packages#Ubuntu.2FDebian

Chris

From: vpp-dev@lists.fd.io 
[mailto:vpp-dev@lists.fd.io] On Behalf Of Brian 
Brooks
Sent: Monday, July 02, 2018 12:56 PM
To: Jit Mehta 
mailto:jitendra.harshad...@gmail.com>>; 
vpp-dev@lists.fd.io
Subject: [EXTERNAL] Re: [vpp-dev] VPP ARM Build/Installation

Hi Jit,

On AArch64 machine:

$ git clone https://gerrit.fd.io/r/vpp
$ cd vpp
$ make build-release

Packages in nexus (not exactly sure which one):
https://nexus.fd.io/#view-repositories;fd.io.master.ubuntu-arm.xenial.main~browsestorage

Brian

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Jit Mehta
Sent: Friday, June 29, 2018 11:28 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP ARM Build/Installation

Hello,

Is there a way I can download and install aarch64 binaries?
If not, is there a wiki that lists how to build aarch64 targets?

Thanks,
Jit
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 

Re: [vpp-dev] VPP ARM Build/Installation

[Chris Luke]

Ubuntu aarch64 packages use the same recipe as amd64; 
https://wiki.fd.io/view/VPP/Installing_VPP_binaries_from_packages#Ubuntu.2FDebian

Chris

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Brian Brooks
Sent: Monday, July 02, 2018 12:56 PM
To: Jit Mehta ; vpp-dev@lists.fd.io
Subject: [EXTERNAL] Re: [vpp-dev] VPP ARM Build/Installation

Hi Jit,

On AArch64 machine:

$ git clone https://gerrit.fd.io/r/vpp
$ cd vpp
$ make build-release

Packages in nexus (not exactly sure which one):
https://nexus.fd.io/#view-repositories;fd.io.master.ubuntu-arm.xenial.main~browsestorage

Brian

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Jit Mehta
Sent: Friday, June 29, 2018 11:28 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP ARM Build/Installation

Hello,

Is there a way I can download and install aarch64 binaries?
If not, is there a wiki that lists how to build aarch64 targets?

Thanks,
Jit
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 (#9762): https://lists.fd.io/g/vpp-dev/message/9762
Mute This Topic: https://lists.fd.io/mt/22895892/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [EXTERNAL] [vpp-dev] How to disable assert in VPP

[Chris Luke]

You can provide your own ASSERT mechanism in vppinfra/error_bootstrap.h

As is typical, we do not compile ASSERTs for non-debug builds. They add a 
measurable overhead and peak forwarding performance will be impacted.

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of chetan bhasin
Sent: Friday, June 15, 2018 5:11
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] [vpp-dev] How to disable assert in VPP

Hi ,

For deployment , we want to replace assert with error log. Is there a way in 
VPP to do that?

Thanks,
Chetan


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

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

Re: [EXTERNAL] [vpp-dev] VPP & CPU

[Chris Luke]

Since those are all Intel platforms and you propose building on an Intel 
platform, just build and use it as-is. If you're not modifying anything just 
use the packages we produce.

Most of the performance critical places that make use of CPU optimizations do 
some magic to build more than one version of a function with different CPU 
optimizations and then select the correct version when the runtime linker loads 
the binary. That means we need not worry about cross-compiling for specific 
optimizations within an architecture.

Chris

From: vpp-dev@lists.fd.io  On Behalf Of xulang
Sent: Friday, June 15, 2018 4:57
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] [vpp-dev] VPP & CPU

Hi all,
I want to run vpp on those kinds of CPU, such as N2600 D525 2117U.
Is that possible? How can I do it if I build vpp on CPU I7?


Regards,
xlangyun





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

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

Re: [EXTERNAL] [vpp-dev] Missing functions?

[Chris Luke]

FWIW, it builds for me, top of tree.

Chris.

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Jon Loeliger
Sent: Wednesday, June 13, 2018 1:24 PM
To: vpp-dev 
Subject: [EXTERNAL] [vpp-dev] Missing functions?


Hi!

With the current VPP top-of-tree here:

commit c7d50970d4ed8a4889b4374e6a1559aef7d3dcc0
Author: Andrew Yourtchenko mailto:ayour...@gmail.com>>
Date:   Tue Jun 12 15:15:49 2018 +0200

acl-plugin: change the src/dst L3 info in 5tuple struct to be always 
contiguous with L4 data

We seem to have some new linking issues like this:

/build-root/install-vpp-native/vpp/lib64/libvlib.so: undefined reference to 
`_vlib_init_function_map_stat_segment_init'
/build-root/install-vpp-native/vpp/lib64/libvlib.so: undefined reference to 
`_vlib_init_function_vpe_api_init'

Has anyone else seen issues like that?

Thanks,
jdl



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

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

Re: [EXTERNAL] [vpp-dev] VPP 17.04 Bridge

[Chris Luke]

Ewan,

There is no such issue that I am aware of. Have you tried your setup by 
building from the master branch? Or an older version? Did you search our Jira? 
https://jira.fd.io/browse/VPP

Otherwise, in general, more details will be required; if you do not find an 
existing issue, please open a new one in Jira with examples of what you mean, 
with details of your environment and configuration.

Thanks,
Chris.

From: vpp-dev@lists.fd.io  On Behalf Of xulang
Sent: Tuesday, June 12, 2018 22:48
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] [vpp-dev] VPP 17.04 Bridge

Hi all,
If I add more than four phy interfaces into one bridge,
VPP will corrupt at many different places.
Is there any bug in this feature?




Regards,
Ewan





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

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

Re: [EXTERNAL] Re: RE: [vpp-dev] vpp input '\b' problem

[Chris Luke]

Give the patch in https://gerrit.fd.io/r/12969 a go which should fix this issue.

It caused surgery all over the CLI command line editor with a few interesting 
corner cases so I’ve marked it -2 for now until I can beat on it a bit. I would 
appreciate it if you could test it too.

Thanks,
Chris.

From: 贾铁振 
Sent: Thursday, May 24, 2018 21:06
To: Luke, Chris ; vpp-dev 
Subject: [EXTERNAL] Re: RE: [vpp-dev] vpp input '\b' problem

We have add a jira ticket for it https://jira.fd.io in the VPP project and 
assign it to you, this jira ticket is VPP-1295.






From: Luke, Chris
Date: 2018-05-24 19:44
To: 贾铁振; vpp-dev
Subject: RE: [vpp-dev] vpp input '\b' problem
Hmm, that looks like a terminal interaction I somehow missed when I wrote that 
code[1]. Not impossible to solve, but it may not be soon. If you could, please 
add a jira ticket for it https://jira.fd.io in the VPP project and assign it to 
me.

Thanks,
Chris.

[1] Sending backspace to the terminal doesn’t do what you would expect on the 
left edge. This also impacts when you cursor-up/down through the CLI history if 
those lines are longer than the terminal width.

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of ???
Sent: Wednesday, May 23, 2018 22:31
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: [EXTERNAL] [vpp-dev] vpp input '\b' problem

When VPP cli configuring multi line content, then continuously input '\b', or 
press' backspace '/' backspace 'continuously, the CLI cursor can only go back 
to the left of the line and cannot return to the last line. How can this 
problem be solved?

Example：
first:
VPP# a
aa
aaa

then input 'backspace' , can only be deleted last seven 'a'
VPP# a
aa




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

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

Re: [vpp-dev] vpp input '\b' problem

[Chris Luke]

Hmm, that looks like a terminal interaction I somehow missed when I wrote that 
code[1]. Not impossible to solve, but it may not be soon. If you could, please 
add a jira ticket for it https://jira.fd.io in the VPP project and assign it to 
me.

Thanks,
Chris.

[1] Sending backspace to the terminal doesn’t do what you would expect on the 
left edge. This also impacts when you cursor-up/down through the CLI history if 
those lines are longer than the terminal width.

From: vpp-dev@lists.fd.io  On Behalf Of ???
Sent: Wednesday, May 23, 2018 22:31
To: vpp-dev 
Subject: [EXTERNAL] [vpp-dev] vpp input '\b' problem

When VPP cli configuring multi line content, then continuously input '\b', or 
press' backspace '/' backspace 'continuously, the CLI cursor can only go back 
to the left of the line and cannot return to the last line. How can this 
problem be solved?

Example：
first:
VPP# a
aa
aaa

then input 'backspace' , can only be deleted last seven 'a'
VPP# a
aa

Re: [EXTERNAL] [vpp-dev] git.fd.io not updating

[Chris Luke]

The mirror to github[1] has the same last commit, too.

https://github.com/FDio/vpp/commits/master

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of Florin Coras
Sent: Monday, May 21, 2018 19:35
To: helpd...@fd.io
Cc: vpp-dev ; Vanessa Valderrama 

Subject: [EXTERNAL] [vpp-dev] git.fd.io not updating

Hi,

It would seem that git.fd.io [1] thinks that we last 
committed a patch to vpp almost 1 week ago. Any idea what might’ve triggered 
this?

Thanks,
Florin

[1] https://git.fd.io/vpp/log/

Re: [EXTERNAL] Re: Re: [csit-dev] [vpp-dev] A 404 error occurred in the process of sudo apt-get update. How to solve it?

[Chris Luke]

We’re not able to give detailed basic linux support here. Are you following a 
guide that had you execute a step to install the packages? That will tell you 
which files it modified to add the repository lines. Somewhere in 
/etc/apt/sources.list.d/

Chris.

From: 汤超 <nwnj...@fiberhome.com>
Sent: Wednesday, May 2, 2018 20:34
To: Luke, Chris <chris_l...@cable.comcast.com>; vpp-dev <vpp-dev@lists.fd.io>
Cc: csit-dev <csit-...@lists.fd.io>
Subject: [EXTERNAL] Re: Re: [csit-dev] [vpp-dev] A 404 error occurred in the 
process of sudo apt-get update. How to solve it?

Yes, I found this problem, but how should I modify it? Is the 
etc/apt/source.list file modified? How should I modify it?

My source file content：

#deb cdrom:[Ubuntu 16.04.4 LTS _Xenial Xerus_ - Release amd64 (20180228)]/ 
xenial main restricted

# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
deb http://cn.archive.ubuntu.com/ubuntu/ xenial main restricted
# deb-src http://cn.archive.ubuntu.com/ubuntu/ xenial main restricted

## Major bug fix updates produced after the final release of the
## distribution.
deb http://cn.archive.ubuntu.com/ubuntu/ xenial-updates main restricted
# deb-src http://cn.archive.ubuntu.com/ubuntu/ xenial-updates main restricted

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team. Also, please note that software in universe WILL NOT receive any
## review or updates from the Ubuntu security team.
deb http://cn.archive.ubuntu.com/ubuntu/ xenial universe
# deb-src http://cn.archive.ubuntu.com/ubuntu/ xenial universe
deb http://cn.archive.ubuntu.com/ubuntu/ xenial-updates universe
# deb-src http://cn.archive.ubuntu.com/ubuntu/ xenial-updates universe

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team, and may not be under a free licence. Please satisfy yourself as to
## your rights to use the software. Also, please note that software in
## multiverse WILL NOT receive any review or updates from the Ubuntu
## security team.
deb http://cn.archive.ubuntu.com/ubuntu/ xenial multiverse
# deb-src http://cn.archive.ubuntu.com/ubuntu/ xenial multiverse
deb http://cn.archive.ubuntu.com/ubuntu/ xenial-updates multiverse
# deb-src http://cn.archive.ubuntu.com/ubuntu/ xenial-updates multiverse

## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
deb http://cn.archive.ubuntu.com/ubuntu/ xenial-backports main restricted 
universe multiverse
# deb-src http://cn.archive.ubuntu.com/ubuntu/ xenial-backports main restricted 
universe multiverse

## Uncomment the following two lines to add software from Canonical's
## 'partner' repository.
## This software is not part of Ubuntu, but is offered by Canonical and the
## respective vendors as a service to Ubuntu users.
# deb http://archive.canonical.com/ubuntu xenial partner
# deb-src http://archive.canonical.com/ubuntu xenial partner

deb http://security.ubuntu.com/ubuntu xenial-security main restricted
# deb-src http://security.ubuntu.com/ubuntu xenial-security main restricted
deb http://security.ubuntu.com/ubuntu xenial-security universe
# deb-src http://security.ubuntu.com/ubuntu xenial-security universe
deb http://security.ubuntu.com/ubuntu xenial-security multiverse
# deb-src http://security.ubuntu.com/ubuntu xenial-security multiverse
deb http://download.virtualbox.org/virtualbox/debian xenial contrib
deb http://download.virtualbox.org/virtualbox/debian xenial contrib
deb http://download.virtualbox.org/virtualbox/debian xenial contrib
deb http://download.virtualbox.org/virtualbox/debian xenial contrib


nwnj...@fiberhome.com<mailto:nwnj...@fiberhome.com>

From: Chris Luke<mailto:chris_l...@comcast.com>
Date: 2018-05-02 19:06
To: 汤超<mailto:nwnj...@fiberhome.com>; vpp-dev<mailto:vpp-dev@lists.fd.io>
CC: csit-dev<mailto:csit-...@lists.fd.io>
Subject: Re: [csit-dev] [vpp-dev] A 404 error occurred in the process of sudo 
apt-get update. How to solve it?
‘fd.io.ubuntu..main’ is not a valid URL – spot the double-dot. It’s missing the 
word ‘xenial’.

Chris.


From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> On Behalf Of ??
Sent: Tuesday, May 1, 2018 22:41
To: vpp-dev <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Cc: csit-dev <csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>>
Subject: [EXTERNAL] [vpp-dev] A 404 error occurred in the process of sudo 
apt-get update. How to solve it?

A 404 error occurred in the process of sudo apt-get update. How to solve it?
fiber@ubuntu:/etc/apt$ sudo apt-get update
Have y

Re: [vpp-dev] A 404 error occurred in the process of sudo apt-get update. How to solve it?

[Chris Luke]

‘fd.io.ubuntu..main’ is not a valid URL – spot the double-dot. It’s missing the 
word ‘xenial’.

Chris.


From: vpp-dev@lists.fd.io  On Behalf Of ??
Sent: Tuesday, May 1, 2018 22:41
To: vpp-dev 
Cc: csit-dev 
Subject: [EXTERNAL] [vpp-dev] A 404 error occurred in the process of sudo 
apt-get update. How to solve it?

A 404 error occurred in the process of sudo apt-get update. How to solve it?
fiber@ubuntu:/etc/apt$ sudo apt-get update
Have you ever met？

Hit:1 http://archive.ubuntukylin.com:10006/ubuntukylin xenial InRelease
Hit:2 http://download.virtualbox.org/virtualbox/debian xenial InRelease
Hit:3 http://cn.archive.ubuntu.com/ubuntu xenial InRelease
Get:4 http://security.ubuntu.com/ubuntu xenial-security InRelease [107 kB]
Hit:5 http://cn.archive.ubuntu.com/ubuntu xenial-updates InRelease
Hit:6 http://cn.archive.ubuntu.com/ubuntu xenial-backports InRelease
Ign:7 https://nexus.fd.io/content/repositories/fd.io.ubuntu.xenial.main ./ 
InRelease
Ign:8 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ InRelease
Ign:10 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ Release
Ign:11 https://nexus.fd.io/content/repositories/fd.io.ubuntu.xenial.main ./ 
Release.gpg
Ign:12 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ Packages
Ign:13 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ 
Translation-en_US
Ign:14 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ 
Translation-en
Ign:12 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ Packages
Ign:13 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ 
Translation-en_US
Ign:14 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ 
Translation-en
Ign:12 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ Packages
Ign:13 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ 
Translation-en_US
Ign:14 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ 
Translation-en
Ign:12 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ Packages
Ign:13 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ 
Translation-en_US
Ign:14 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ 
Translation-en
Ign:12 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ Packages
Ign:13 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ 
Translation-en_US
Ign:14 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ 
Translation-en
Err:12 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ Packages
  404  Not Found
Ign:13 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ 
Translation-en_US
Ign:14 https://nexus.fd.io/content/repositories/fd.io.ubuntu..main ./ 
Translation-en
Fetched 107 kB in 10s (9,909 B/s)
Reading package lists... Done
W: Target Packages (contrib/binary-amd64/Packages) is configured multiple times 
in /etc/apt/sources.list:52 and /etc/apt/sources.list:53
W: Target Packages (contrib/binary-i386/Packages) is configured multiple times 
in /etc/apt/sources.list:52 and /etc/apt/sources.list:53
W: Target Packages (contrib/binary-all/Packages) is configured multiple times 
in /etc/apt/sources.list:52 and /etc/apt/sources.list:53
W: Target Translations (contrib/i18n/Translation-en_US) is configured multiple 
times in /etc/apt/sources.list:52 and /etc/apt/sources.list:53
W: Target Translations (contrib/i18n/Translation-en) is configured multiple 
times in /etc/apt/sources.list:52 and /etc/apt/sources.list:53
W: Target DEP-11 (contrib/dep11/Components-amd64.yml) is configured multiple 
times in /etc/apt/sources.list:52 and /etc/apt/sources.list:53
W: Target DEP-11-icons (contrib/dep11/icons-64x64.tar) is configured multiple 
times in /etc/apt/sources.list:52 and /etc/apt/sources.list:53
W: Target Packages (contrib/binary-amd64/Packages) is configured multiple times 
in /etc/apt/sources.list:52 and /etc/apt/sources.list:54
W: Target Packages (contrib/binary-i386/Packages) is configured multiple times 
in /etc/apt/sources.list:52 and /etc/apt/sources.list:54
W: Target Packages (contrib/binary-all/Packages) is configured multiple times 
in /etc/apt/sources.list:52 and /etc/apt/sources.list:54
W: Target Translations (contrib/i18n/Translation-en_US) is configured multiple 
times in /etc/apt/sources.list:52 and /etc/apt/sources.list:54
W: Target Translations (contrib/i18n/Translation-en) is configured multiple 
times in /etc/apt/sources.list:52 and /etc/apt/sources.list:54
W: Target DEP-11 (contrib/dep11/Components-amd64.yml) is configured multiple 
times in /etc/apt/sources.list:52 and /etc/apt/sources.list:54
W: Target DEP-11-icons (contrib/dep11/icons-64x64.tar) is configured multiple 
times in /etc/apt/sources.list:52 and /etc/apt/sources.list:54
W: Target Packages (contrib/binary-amd64/Packages) is configured multiple times 
in /etc/apt/sources.list:52 and /etc/apt/sources.list:55
W: Target Packages 

Re: [vpp-dev] router plugin ISIS

[Chris Luke]

IS-IS is not an IP protocol, it’s a layer 2 protocol, meaning it has its own 
Ethertype.

Chris.

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Gulakh
Sent: Monday, April 30, 2018 9:42 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] router plugin ISIS

Hi,
i want to extend router plugin code to support is-is, i.e., sending is-is 
packets up to the control plane!
First, i registered ISIS in tap inject, by adding the following line:
ip4_register_protocol (IP_PROTOCOL_ISIS, im->tx_node_index);
 in tap_inject_enable (void) function located at 
vppsb/router/router/tap_inject.c file!
However, the problem remained unsolved.
Is there a special issue related to is-is that i should know?
Anyone can help me?
Regards,
Gulakh

[vpp-dev] VPP 18.04 has been released! Artifacts are available on nexus.fd.io

[Chris Luke]

All,

I am happy to announce that VPP 18.04 has been released! The release notes can 
be found at https://docs.fd.io/vpp/18.04/release_notes_1804.html.

The various release artifacts have made their way to the right places on 
nexus.fd.io.

Packaging for Centos 7 (Intel), openSUSE Leap 42.3 (Intel), Ubuntu Xenial 
(Intel) and Ubuntu Xenial (ARM) are available. Details on how to install them 
are available at 
https://wiki.fd.io/view/VPP/Installing_VPP_binaries_from_packages.

Packages for the Intel platforms have been tested; I will follow up with ARM 
package testing once I get my arm64 box setup!

Our thanks to all of the VPP and FD.io community who have contributed to the 
18.04 VPP release.

Cheers,
Chris.

[vpp-dev] Notice: Branch stable/1804 closed for changes

[Chris Luke]

All,

Today is VPP 18.04 release day; to help the release go smoothly we close the 
branch to changes during the release process. From this point, any changes 
submitted for review will go ignored until after the release is complete.

Committers,

Please avoid merging any changes into stable/1804 until further notice, please.

Thanks,
Chris.

[vpp-dev] VPP 18.04 release day is tomorrow!

[Chris Luke]

All,

Release day is upon us. The tentative plan is that tomorrow morning, around 
07:00 US Eastern time I'll declare the stable branch closed to new patches. If 
you have critical fixes for stable, that is your deadline to get them in for 
the release.

Thanks,
Chris.

[vpp-dev] Draft VPP 18.04 release notes

[Chris Luke]

All,

A first pass at the release notes for VPP 18.04 are available for review in 
https://gerrit.fd.io/r/#/c/12038/ . I have not yet walked the commit history 
looking for juicy key features to include in the list, I'll do that tomorrow. 
Suggestions are, of course, welcome!

A preview can be seen at 
http://brae.flirble.org/~chrisy/vpp/d0/dde/release_notes_1804.html .

Cheers,
Chris.

[vpp-dev] Reminder: stable/1804 will release on Wednesday!

[Chris Luke]

All,

A reminder that VPP 18.04 will be released this Wednesday, April 25th.

We're still accepting critical bug fixes, but at this point I expect few 
patches between now and then. That said, feedback on the stability of the 
branch is always welcome.

Cheers,
Chris.

Re: [csit-dev] [vpp-dev] ARM vpp-dpdk-dkms nexus artifacts - CSIT

[Chris Luke]

Given 18.04 is just one week away I would suggest the path of least disturbance 
at least until after the release. I abhor complications. :)

Chris.


From: csit-...@lists.fd.io [mailto:csit-...@lists.fd.io] On Behalf Of Ed Kern
Sent: Wednesday, April 18, 2018 11:10 AM
To: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) 
Cc: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) 
; Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at 
Cisco) ; Maciek Konstantynowicz (mkonstan) 
; Vanessa Valderrama ; 
csit-...@lists.fd.io; vpp-dev ; hc2...@lists.fd.io; 
honeycomb-...@lists.fd.io
Subject: Re: [csit-dev] [vpp-dev] ARM vpp-dpdk-dkms nexus artifacts - CSIT

Dont get me wrong..im behind vratko’s thinking about doing the restructure…just 
didnt want to rush that in..(unless that fix is more simple than it appears) 
but wanted
to get you working again right away.

There is no point in just deleting the arm packages since they would just get 
repopulated quickly

although I am still thinking about other options to explore..

Ed


On Apr 18, 2018, at 9:05 AM, Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at 
Cisco) > wrote:

Thank you for the inputs. I agree that we can put temporary workaround 
although. Unless someone beats me I will do tomorrow.
I think that long term solution is more than welcomed. Looking on this not only 
thru optics of CSIT but anyonw who will look on Nexus and would wonder why 
RELEASE is only arm64.

Any views who is maintaining nexus storage from configuration point of view?

Peter Mikus
Engineer – Software
Cisco Systems Limited

From: Ed Kern (ejk)
Sent: Wednesday, April 18, 2018 5:00 PM
To: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) 
>; Peter Mikus -X (pmikus - 
PANTHEON TECHNOLOGIES at Cisco) >
Cc: Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) 
>; Maciek Konstantynowicz 
(mkonstan) >; Vanessa Valderrama 
>; 
csit-...@lists.fd.io; vpp-dev 
>; 
hc2...@lists.fd.io; 
honeycomb-...@lists.fd.io
Subject: Re: [csit-dev] [vpp-dev] ARM vpp-dpdk-dkms nexus artifacts - CSIT

vratko: responding to the thread but NOT to your email..  im going to assume 
your correct that it is abusing the version field
and that nexus could/should be doing something different..and what your saying 
about version timing makes sense since the arm64
flavor certainly came long after the amd64 was build and pushed to nexus.

BUT..just as a datapoint and possible short term workaround

If csit would just use apt-get download vpp-dpdk-dkms it appears (even with the 
current config/misconfig ) to pull the correct deb
depending on your source arch. not sure if this could be a short term 
fix/workaround/replacement to your curl command.

Ed





On Apr 18, 2018, at 8:46 AM, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES 
at Cisco) > wrote:

I have some experience with Maven and Nexus.

>   io.fd.vpp
>   vpp-dpdk-dkms
>   18.02-vpp1_arm64
>   deb
>   deb

That sets "deb" to be both the classifier and the type.
That is correct for the type, as it usually corresponds to the file extension.
But we can use classifier to designate architecture.
For more information, search for "Classifier:" (without quotes) here [3].

By the way, the incorrect thing we currently do
is to overload the version field.
Versions are assumed to be ordered linearly,
so when comparing 18.02-vpp1_arm64 and 18.02-vpp1_amd64, one has to be newer.

Here is my proposed fix:

  io.fd.vpp
  vpp-dpdk-dkms
  18.02-vpp1
  arm64
  deb

Also, the code snippets which currently download the deb file
should be updated to include the classifier value in the URL.

Vratko.

[3] https://maven.apache.org/pom.html#Dependencies

From: csit-...@lists.fd.io 
> On Behalf Of Marek Gradzki 
-X (mgradzki - PANTHEON TECHNOLOGIES at Cisco)
Sent: Wednesday, 2018-April-18 16:24
To: Maciek Konstantynowicz (mkonstan) 
>; Peter Mikus -X (pmikus - 
PANTHEON TECHNOLOGIES at Cisco) >; Ed 
Kern (ejk) >; Vanessa Valderrama 
>
Cc: csit-...@lists.fd.io; vpp-dev 
>; 

Re: [vpp-dev] IP Reassembly does not work at 18.04

[Chris Luke]

Yes please, ideally with a Jira ref in the title :)

Chris

> -Original Message-
> From: Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)
> [mailto:ksek...@cisco.com]
> Sent: Tuesday, April 17, 2018 12:01 PM
> To: Luke, Chris ;
> wangchuan...@163.com; vpp-dev 
> Subject: RE: [vpp-dev] IP Reassembly does not work at 18.04
> 
> Yes it does, do I need to double commit?
> 
> > -Original Message-
> > From: Luke, Chris 
> > Sent: Tuesday, April 17, 2018 6:00 PM
> > To: Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)
> > ; wangchuan...@163.com; vpp-dev  > d...@lists.fd.io>
> > Subject: RE: [vpp-dev] IP Reassembly does not work at 18.04
> >
> > Does this impact stable/1804 also?
> >
> > Chris.
> >
> > > -Original Message-
> > > From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of
> > > Klement Sekera
> > > Sent: Tuesday, April 17, 2018 11:50 AM
> > > To: wangchuan...@163.com; vpp-dev 
> > > Subject: Re: [vpp-dev] IP Reassembly does not work at 18.04
> > >
> > > Hi,
> > >
> > > This patch should fix the CLI issue...
> > >
> > > https://gerrit.fd.io/r/#/c/11851/
> > >
> > > Regards,
> > > Klement
> > >
> > > > -Original Message-
> > > > From: vpp-dev@lists.fd.io  On Behalf Of
> > > > wangchuan...@163.com
> > > > Sent: Tuesday, April 17, 2018 10:55 AM
> > > > To: Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)
> > > > ; vpp-dev 
> > > > Subject: Re: [vpp-dev] IP Reassembly does not work at 18.04
> > > >
> > > > Thanks
> > > > But it still fail by return : Invalid interface name
> > > >
> > > > my CLI: set interface reassembly GigabitEthernet2/0/0  ip4 also
> > > > not good to use Idx i am sure the intfc-name is right.
> > > >
> > > >
> > > > Help please!
> > > >
> > > > 
> > > >
> > > > wangchuan...@163.com
> > > >
> > > >
> > > > From: Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at
> > > > Cisco) 
> > > > Date: 2018-04-17 16:22
> > > > To: wangchuan...@163.com  ;
> > > vpp-dev
> > > > 
> > > > Subject: RE: [vpp-dev] IP Reassembly does not work at 18.04
> > > > Hi,
> > > >
> > > > IP reassembly is a feature which needs to be enabled - did you
> > > enable
> > > > reassembly on your interface? - it doesn't look so from your packet
> trace.
> > > > You can use `set interface reassembly' CLI or the corresponding
> > > > API `ip_reassembly_enable_disable'.
> > > >
> > > > Regards,
> > > > Klement
> > > >
> > > > > -Original Message-
> > > > > From: vpp-dev@lists.fd.io  On Behalf Of
> > > > > wangchuan...@163.com
> > > > > Sent: Tuesday, April 17, 2018 8:39 AM
> > > > > To: vpp-dev 
> > > > > Subject: [vpp-dev] IP Reassembly does not work at 18.04
> > > > >
> > > > > Hello,
> > > > > I see VPP can support IP Reassembly at 18.04.
> > > > > I compile the deb and install at ubuntu 16.04,  start 
> > > > vppctl and up
> > > > the
> > > > > interface & set ip-A, then i could ping the ip(no extra-parm).
> > > > > But it failed with "-l 1473"(at windows), who can help? Thanks
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > first segment-pkt's trace node path:
> > > > > dpdk-input -> ip4-input -> ip4-lookup -> ip4-local ->
> > > > ip4-icmp-input ->
> > > > ip4-
> > > > > icmp-echo-request
> > > > > -> ip4-load-balance -> ip4-rewrite -> GigabitEthernetX-output 
> > > > ->
> > > > > GigabitEthernetX-tx
> > > > >
> > > > >
> > > > > second's trace node path:
> > > > > dpdk-input -> ip4-input -> ip4-lookup -> ip4-local ->
> > > > ip4-icmp-input ->
> > > > ip4-
> > > > > punt -> error-punt
> > > > >
> > > > > 
> > > > >
> > > > > wangchuan...@163.com
> > > >
> > > >
> > >
> > > 


-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#8953): https://lists.fd.io/g/vpp-dev/message/8953
View All Messages In Topic (7): https://lists.fd.io/g/vpp-dev/topic/17452007
Mute This Topic: https://lists.fd.io/mt/17452007/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] IP Reassembly does not work at 18.04

[Chris Luke]

Does this impact stable/1804 also?

Chris.

> -Original Message-
> From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Klement
> Sekera
> Sent: Tuesday, April 17, 2018 11:50 AM
> To: wangchuan...@163.com; vpp-dev 
> Subject: Re: [vpp-dev] IP Reassembly does not work at 18.04
> 
> Hi,
> 
> This patch should fix the CLI issue...
> 
> https://gerrit.fd.io/r/#/c/11851/
> 
> Regards,
> Klement
> 
> > -Original Message-
> > From: vpp-dev@lists.fd.io  On Behalf Of
> > wangchuan...@163.com
> > Sent: Tuesday, April 17, 2018 10:55 AM
> > To: Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)
> > ; vpp-dev 
> > Subject: Re: [vpp-dev] IP Reassembly does not work at 18.04
> >
> > Thanks
> > But it still fail by return : Invalid interface name
> >
> > my CLI: set interface reassembly GigabitEthernet2/0/0  ip4 also not
> > good to use Idx i am sure the intfc-name is right.
> >
> >
> > Help please!
> >
> > 
> >
> > wangchuan...@163.com
> >
> >
> > From: Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at
> > Cisco) 
> > Date: 2018-04-17 16:22
> > To: wangchuan...@163.com  ;
> vpp-dev
> > 
> > Subject: RE: [vpp-dev] IP Reassembly does not work at 18.04
> > Hi,
> >
> > IP reassembly is a feature which needs to be enabled - did you
> enable
> > reassembly on your interface? - it doesn't look so from your packet trace.
> > You can use `set interface reassembly' CLI or the corresponding API
> > `ip_reassembly_enable_disable'.
> >
> > Regards,
> > Klement
> >
> > > -Original Message-
> > > From: vpp-dev@lists.fd.io  On Behalf Of
> > > wangchuan...@163.com
> > > Sent: Tuesday, April 17, 2018 8:39 AM
> > > To: vpp-dev 
> > > Subject: [vpp-dev] IP Reassembly does not work at 18.04
> > >
> > > Hello,
> > > I see VPP can support IP Reassembly at 18.04.
> > > I compile the deb and install at ubuntu 16.04,  start vppctl and 
> > up
> > the
> > > interface & set ip-A, then i could ping the ip(no extra-parm).
> > > But it failed with "-l 1473"(at windows), who can help? Thanks
> > >
> > >
> > >
> > >
> > > first segment-pkt's trace node path:
> > > dpdk-input -> ip4-input -> ip4-lookup -> ip4-local ->
> > ip4-icmp-input ->
> > ip4-
> > > icmp-echo-request
> > > -> ip4-load-balance -> ip4-rewrite -> GigabitEthernetX-output ->
> > > GigabitEthernetX-tx
> > >
> > >
> > > second's trace node path:
> > > dpdk-input -> ip4-input -> ip4-lookup -> ip4-local ->
> > ip4-icmp-input ->
> > ip4-
> > > punt -> error-punt
> > >
> > > 
> > >
> > > wangchuan...@163.com
> >
> >
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#8951): https://lists.fd.io/g/vpp-dev/message/8951
View All Messages In Topic (5): https://lists.fd.io/g/vpp-dev/topic/17452007
Mute This Topic: https://lists.fd.io/mt/17452007/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VPP VCL Lib error #vpp

[Chris Luke]

Dave,

Let me know if you can reproduce this and you think this is severe enough to 
postpone the 18.04 release, which is currently set for Wednesday of next week.

Chris.

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Dave Wallace
Sent: Tuesday, April 17, 2018 9:54 AM
To: duct...@viettel.com.vn; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP VCL Lib error #vpp

This is a bug.  Please open a Jira ticket with your configuration and debug 
data and I will investigate.

Thanks,
-daw-
On 4/17/18 8:46 AM, duct...@viettel.com.vn wrote:

Hello,

I am trying to use the VCL lib to connect VPP and my server app.
My code worked perfectly fine with VPP 18.01. But when I upgrade to VPP 18.04 
(and 18.07 also), it hasn't worked anymore.
The code still works if i try with 1 client at a times. But with more than 1 
client at a moment, the server is just hanged up. Trying to debug into the 
code, I find out that the server stuck at the vppcom_session_accept function. A 
bit further, the event thread creates an infinitive loop (with fifo_depth = 2, 
ev->recycle=1 and recycle_count=1).
Is this a bug or does the new version require some specific ways to use the lib 
and I did something wrong?
Any help will be highly appreciated!

[vpp-dev] Note: Verify jobs failing

[Chris Luke]

All,

Some verify jobs are failing because of an issue with the pypi/pythonhosted 
repositories.

In particular, the Centos containers happened to rebuild during the current 
outage of the remote repository and it wasn't caught, meaning that the Centos 
based verify jobs don't have a working Python environment.

Once the repositories work again, Ed Kern will rebuild the broken container 
image and we'll be back in business.

Chris.

Re: [vpp-dev] Build error with my_plugin.api.h file.

[Chris Luke]

I’d recommend working from master, personally. :) Though that DPDK version 
should work fine; there was a period not long ago in which DPDK broke their 
packages and invalidated the checksums we had, but I thought that was evident 
only on master and only briefly, not 18.01*.

Chris.


From: Sara Gittlin [mailto:sara.gitt...@gmail.com]
Sent: Monday, April 16, 2018 12:05 PM
To: Luke, Chris 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Build error with my_plugin.api.h file.

Chris
i did it and now i have another problem (which i saw also before)
"Bad Checksum! Please remove /home/vpp/dpdk/dpdk-17.11.tar.xz and retry"
maybe in addition to my original problem my version is not stable
my version is  git clone the master and then checkout * (HEAD detached at 
v18.01.1)

Thank you again
-Sara


On Mon, Apr 16, 2018 at 6:41 PM, Luke, Chris 
> wrote:
Bit of a long-shot, but it is plausible that autotools didn’t rebuild 
completely after you added your plugin files I suppose. It’s sometimes worth 
cleaning the tree to force it. “make wipe” or to be doubly sure “git clean 
-fxd” (making sure you have your local files added to git etc)

Chris

From: Sara Gittlin 
[mailto:sara.gitt...@gmail.com]
Sent: Monday, April 16, 2018 11:29 AM
To: Luke, Chris 
>
Cc: vpp-dev@lists.fd.io

Subject: Re: [vpp-dev] Build error with my_plugin.api.h file.

Thank you Neale and Chris

Neale -
this is my_policer.api  file:  ( i dont have other files related to api)
option version = "1.0.0";

autoreply define my_policer_if_action {
/* Client identifier, set from api_main.my_client_index */
u32 client_index;

/* Arbitrary context, so client can match reply to request */
u32 context;

/* Enable / disable the feature */
u8 action;

/* Interface handle */
u32 sw_if_index;
};
Chris
this is the line from my_policer.am file

API_FILES += my_policer/my_policer.api
-Sara

On Mon, Apr 16, 2018 at 6:18 PM, Luke, Chris 
> wrote:
Do you list the .api files in the variable API_FILES in your plugin .am file?

Chris

From: vpp-dev@lists.fd.io 
[mailto:vpp-dev@lists.fd.io] On Behalf Of Sara 
Gittlin
Sent: Monday, April 16, 2018 11:08 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Build error with my_plugin.api.h file.

I see that this file (and the my_plugin.api.json)  are  not auto generated in 
the build
Why ?
-Sara

On Mon, Apr 16, 2018 at 5:27 PM, Sara Gittlin 
> wrote:
Hello,

I've encountered this build error few times and managed to get rid of it 
somehow.
the error  is always with the my_plugin.api.h  file.
Can you tell me what is the problem here ?
-
 /bin/sh ./config.status
config.status: creating Makefile
config.status: creating plugins/Makefile
config.status: creating vpp-api/python/Makefile
config.status: creating vpp-api/java/Makefile
config.status: creating vpp-api/vapi/Makefile
config.status: creating vpp-api/vom/Makefile
config.status: executing libtool commands
config.status: executing depfiles commands
make  all-recursive
make[3]: Entering directory '/home/vpp/build-root/build-vpp-native/vpp'
Making all in .
make[4]: Entering directory '/home/vpp/build-root/build-vpp-native/vpp'
make[4]: Nothing to be done for 'all-am'.
make[4]: Leaving directory '/home/vpp/build-root/build-vpp-native/vpp'
Making all in plugins
make[4]: Entering directory '/home/vpp/build-root/build-vpp-native/vpp/plugins'
  APIGEN   my_forwarder/my_forwarder.api.h
  APIGEN   my_policer/my_policer.api.h
(null):53 syntax error
make[4]: *** [Makefile:3301: my_forwarder/my_forwarder.api.h] Error 1
make[4]: *** Waiting for unfinished jobs
(null):53 syntax error
make[4]: *** [Makefile:3301: my_policer/my_policer.api.h] Error 1
make[4]: Leaving directory '/home/vpp/build-root/build-vpp-native/vpp/plugins'
make[3]: *** [Makefile:7757: all-recursive] Error 1
make[3]: Leaving directory '/home/vpp/build-root/build-vpp-native/vpp'
make[2]: *** [Makefile:3967: all] Error 2
make[2]: Leaving directory '/home/vpp/build-root/build-vpp-native/vpp'
make[1]: *** [Makefile:686: vpp-build] Error 2
make[1]: Leaving directory '/home/vpp/build-root'
make: *** [Makefile:339: build-release] Error 2
Thank you
-Sara

Re: [vpp-dev] Build error with my_plugin.api.h file.

[Chris Luke]

Bit of a long-shot, but it is plausible that autotools didn’t rebuild 
completely after you added your plugin files I suppose. It’s sometimes worth 
cleaning the tree to force it. “make wipe” or to be doubly sure “git clean 
-fxd” (making sure you have your local files added to git etc)

Chris

From: Sara Gittlin [mailto:sara.gitt...@gmail.com]
Sent: Monday, April 16, 2018 11:29 AM
To: Luke, Chris 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Build error with my_plugin.api.h file.

Thank you Neale and Chris

Neale -
this is my_policer.api  file:  ( i dont have other files related to api)
option version = "1.0.0";

autoreply define my_policer_if_action {
/* Client identifier, set from api_main.my_client_index */
u32 client_index;

/* Arbitrary context, so client can match reply to request */
u32 context;

/* Enable / disable the feature */
u8 action;

/* Interface handle */
u32 sw_if_index;
};

Chris
this is the line from my_policer.am file

API_FILES += my_policer/my_policer.api
-Sara

On Mon, Apr 16, 2018 at 6:18 PM, Luke, Chris 
> wrote:
Do you list the .api files in the variable API_FILES in your plugin .am file?

Chris

From: vpp-dev@lists.fd.io 
[mailto:vpp-dev@lists.fd.io] On Behalf Of Sara 
Gittlin
Sent: Monday, April 16, 2018 11:08 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Build error with my_plugin.api.h file.

I see that this file (and the my_plugin.api.json)  are  not auto generated in 
the build
Why ?
-Sara

On Mon, Apr 16, 2018 at 5:27 PM, Sara Gittlin 
> wrote:
Hello,

I've encountered this build error few times and managed to get rid of it 
somehow.
the error  is always with the my_plugin.api.h  file.
Can you tell me what is the problem here ?
-
 /bin/sh ./config.status
config.status: creating Makefile
config.status: creating plugins/Makefile
config.status: creating vpp-api/python/Makefile
config.status: creating vpp-api/java/Makefile
config.status: creating vpp-api/vapi/Makefile
config.status: creating vpp-api/vom/Makefile
config.status: executing libtool commands
config.status: executing depfiles commands
make  all-recursive
make[3]: Entering directory '/home/vpp/build-root/build-vpp-native/vpp'
Making all in .
make[4]: Entering directory '/home/vpp/build-root/build-vpp-native/vpp'
make[4]: Nothing to be done for 'all-am'.
make[4]: Leaving directory '/home/vpp/build-root/build-vpp-native/vpp'
Making all in plugins
make[4]: Entering directory '/home/vpp/build-root/build-vpp-native/vpp/plugins'
  APIGEN   my_forwarder/my_forwarder.api.h
  APIGEN   my_policer/my_policer.api.h
(null):53 syntax error
make[4]: *** [Makefile:3301: my_forwarder/my_forwarder.api.h] Error 1
make[4]: *** Waiting for unfinished jobs
(null):53 syntax error
make[4]: *** [Makefile:3301: my_policer/my_policer.api.h] Error 1
make[4]: Leaving directory '/home/vpp/build-root/build-vpp-native/vpp/plugins'
make[3]: *** [Makefile:7757: all-recursive] Error 1
make[3]: Leaving directory '/home/vpp/build-root/build-vpp-native/vpp'
make[2]: *** [Makefile:3967: all] Error 2
make[2]: Leaving directory '/home/vpp/build-root/build-vpp-native/vpp'
make[1]: *** [Makefile:686: vpp-build] Error 2
make[1]: Leaving directory '/home/vpp/build-root'
make: *** [Makefile:339: build-release] Error 2
Thank you
-Sara

Re: [vpp-dev] Build error with my_plugin.api.h file.

[Chris Luke]

Do you list the .api files in the variable API_FILES in your plugin .am file?

Chris

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Sara Gittlin
Sent: Monday, April 16, 2018 11:08 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Build error with my_plugin.api.h file.

I see that this file (and the my_plugin.api.json)  are  not auto generated in 
the build
Why ?
-Sara

On Mon, Apr 16, 2018 at 5:27 PM, Sara Gittlin 
> wrote:
Hello,

I've encountered this build error few times and managed to get rid of it 
somehow.
the error  is always with the my_plugin.api.h  file.
Can you tell me what is the problem here ?
-
 /bin/sh ./config.status
config.status: creating Makefile
config.status: creating plugins/Makefile
config.status: creating vpp-api/python/Makefile
config.status: creating vpp-api/java/Makefile
config.status: creating vpp-api/vapi/Makefile
config.status: creating vpp-api/vom/Makefile
config.status: executing libtool commands
config.status: executing depfiles commands
make  all-recursive
make[3]: Entering directory '/home/vpp/build-root/build-vpp-native/vpp'
Making all in .
make[4]: Entering directory '/home/vpp/build-root/build-vpp-native/vpp'
make[4]: Nothing to be done for 'all-am'.
make[4]: Leaving directory '/home/vpp/build-root/build-vpp-native/vpp'
Making all in plugins
make[4]: Entering directory '/home/vpp/build-root/build-vpp-native/vpp/plugins'
  APIGEN   my_forwarder/my_forwarder.api.h
  APIGEN   my_policer/my_policer.api.h
(null):53 syntax error
make[4]: *** [Makefile:3301: my_forwarder/my_forwarder.api.h] Error 1
make[4]: *** Waiting for unfinished jobs
(null):53 syntax error
make[4]: *** [Makefile:3301: my_policer/my_policer.api.h] Error 1
make[4]: Leaving directory '/home/vpp/build-root/build-vpp-native/vpp/plugins'
make[3]: *** [Makefile:7757: all-recursive] Error 1
make[3]: Leaving directory '/home/vpp/build-root/build-vpp-native/vpp'
make[2]: *** [Makefile:3967: all] Error 2
make[2]: Leaving directory '/home/vpp/build-root/build-vpp-native/vpp'
make[1]: *** [Makefile:686: vpp-build] Error 2
make[1]: Leaving directory '/home/vpp/build-root'
make: *** [Makefile:339: build-release] Error 2
Thank you
-Sara

Re: [vpp-dev] vec_new() vs. vec_validate()

[Chris Luke]

Vec_new always allocates storage, vec_validate ensures that an existing 
allocation is at least a certain size, or create a new one if the pointer is 
NULL. The latter is typically used when the storage will be used as an array 
and you want to make sure it's large enough to store element N.

See 
https://docs.fd.io/vpp/18.07/db/d65/vec_8h.html#a003a343880e8218b2398b72ae16c5163
 and 
https://docs.fd.io/vpp/18.07/db/d65/vec_8h.html#a3b2e25abfbea7eea806d37920ba769e3.

The other subtle difference is that you need to tell vec_new the type of the 
elements in the array (so it knows the size) whereas vec_validate can glean 
that from the type of the vector (possibly NULL) you pass in.

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of Bly, Mike
Sent: Thursday, April 12, 2018 15:30
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vec_new() vs. vec_validate()

Hello,

After some digging, near as I can tell, for a new pointer to a new entity, it 
would seem that vec_new() is pretty much providing the same results as 
vec_validate(), albeit, with one less memset(bob, o, sizeof(*bob)) being 
performed. However, I see a 10:1 usage (preference?) of vec_validate() vs. 
vec_new() in the existing vpp src, so I was hoping someone could share some of 
the "why" here as to when one should use either.

-Mike

Re: [vpp-dev] [csit-dev] VPP 18.04-RC2 release milestone

[Chris Luke]

Thanks Dave, I look forward to it.

Chris.

From: csit-...@lists.fd.io <csit-...@lists.fd.io> On Behalf Of Dave Wallace
Sent: Thursday, April 12, 2018 10:10
To: csit-...@lists.fd.io
Subject: Re: [csit-dev] VPP 18.04-RC2 release milestone

Chris,

As discussed at yesterday's CSIT weekly meeting, the CSIT team is working to 
produce an initial set of performance results graphs for 18.04 that can be 
reviewed at next Tuesday's VPP meeting.

Thanks,
-daw-
On 04/11/2018 05:36 PM, Chris Luke wrote:
All,

I have created the v18.04-rc2 tag on the HEAD of VPP branch stable/1804 and 
verified that the build artifacts arrived on nexus.fd.io[1][2]. This completes 
the RC2 release milestone for VPP 18.04.

As a reminder, per the release 
plan<https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_18.04#Release_Milestones>,
 the VPP 18.04 release is in two weeks on Wednesday April 25th, 2018. I would 
greatly appreciate if all those developers who contributed code towards 18.04 
would check the release deliverables 
list<https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_18.04#Release_Deliverables>
 and add/update accordingly.

I note that CSIT has created the release branch rls1804 and anticipate that 
they will start testing 
soon<https://wiki.fd.io/view/CSIT/csit1804_plan#Release_Milestones>. CSIT 
expects to publish their performance report for 18.04 on May 2nd, 2018.

VPP branch stable/1804 is still open for patches, though it is important to 
note that we are now focused only on patches which address critical issues (as 
determined by the VPP committers), ideally limited to addressing bugs found by 
CSIT testing.

Per the standard process, all bug fixes to stable branches should follow these 
best practices:



  *   All bug fixes must be double-committed to the stable branch as well as to 
the master branch:

 *   Commit first to the stable branch, then "git cherry-pick" into master.
 *   Manual merges may be required, depending on the degree of divergence 
between throttle and master.

  *   All bug fixes need to have a Jira ticket:

 *   Please put Jira IDs into the commit messages.
 *   Please use the same Jira ID for both the stable branch and master.


Thanks,
Chris.

[1] Package cloud does not yet have packages for 18.04; this is an issue that 
LF folk are still looking into.
[2] Opensuse is failing in the merge job; this is being worked on and should be 
resolved next week.

[vpp-dev] VPP 18.04-RC2 release milestone

[Chris Luke]

All,

I have created the v18.04-rc2 tag on the HEAD of VPP branch stable/1804 and 
verified that the build artifacts arrived on nexus.fd.io[1][2]. This completes 
the RC2 release milestone for VPP 18.04.

As a reminder, per the release 
plan,
 the VPP 18.04 release is in two weeks on Wednesday April 25th, 2018. I would 
greatly appreciate if all those developers who contributed code towards 18.04 
would check the release deliverables 
list
 and add/update accordingly.

I note that CSIT has created the release branch rls1804 and anticipate that 
they will start testing 
soon. CSIT 
expects to publish their performance report for 18.04 on May 2nd, 2018.

VPP branch stable/1804 is still open for patches, though it is important to 
note that we are now focused only on patches which address critical issues (as 
determined by the VPP committers), ideally limited to addressing bugs found by 
CSIT testing.

Per the standard process, all bug fixes to stable branches should follow these 
best practices:


  *   All bug fixes must be double-committed to the stable branch as well as to 
the master branch:
 *   Commit first to the stable branch, then "git cherry-pick" into master.
 *   Manual merges may be required, depending on the degree of divergence 
between throttle and master.
  *   All bug fixes need to have a Jira ticket:
 *   Please put Jira IDs into the commit messages.
 *   Please use the same Jira ID for both the stable branch and master.


Thanks,
Chris.

[1] Package cloud does not yet have packages for 18.04; this is an issue that 
LF folk are still looking into.
[2] Opensuse is failing in the merge job; this is being worked on and should be 
resolved next week.

[vpp-dev] 18.04 RC2 this Wednesday!

[Chris Luke]

All,

Gentle reminder that 18.04 RC2 will be posted on Wednesday.

Note: After Wednesday's RC2 Milestone, only critical bug fixes will be merged 
into branch stable/1804.  Please review open anomalies for candidates to be 
fixed this week. Also, please remember to open a Jira ticket for all patches 
submitted to stable branches.

Cheers,
Chris.

Re: [vpp-dev] Build failure on 18.04

[Chris Luke]

That looks like you have a connectivity issue to one of the download sites for 
DPDK, nasm, and/or aeslib.

Check you can reach http://fast.dpdk.org, http://www.nasm.us and 
http://github.com and that they give non-zero length responses.

It occurs to me that perhaps the Makefile should display what it is trying to 
download so one can try the same URL, will add that later if I get a moment.

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of Shashi Kant Singh
Sent: Monday, April 9, 2018 1:48
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Build failure on 18.04

Hi All

I did a fresh checkout and tried to do make build of release 18.04, but get 
following errors:

Regards
Shashi


[root@vbbubng6-shashi-8 vpp]# git branch -a
* (detached from origin/stable/1804)
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/stable/1606
  remotes/origin/stable/1609
  remotes/origin/stable/1701
  remotes/origin/stable/1704
  remotes/origin/stable/1707
  remotes/origin/stable/1710
  remotes/origin/stable/1801
  remotes/origin/stable/1804
  remotes/origin/stable/test

[root@vbbubng6-shashi-8 vpp]# make build
make[1]: Entering directory `/bng5/shashi-8/vpp5/vpp/build-root'
 Arch for platform 'vpp' is native 
 Finding source for dpdk 
..

make[2]: Entering directory `/bng5/shashi-8/vpp5/vpp/dpdk'
==
Building DPDK from source. Consider installing development
package by invoking 'make dpdk-install-dev' from the
top level directory
==
make config
Building IPSec-MB 0.48 library
make[3]: Entering directory `/bng5/shashi-8/vpp5/vpp/dpdk'
make[3]: warning: jobserver unavailable: using -j1.  Add `+' to parent make 
rule.
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100  9.9M  100  9.9M0 0  1130k  0  0:00:09  0:00:09 --:--:-- 2260k
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0   3510 00 0  0  0 --:--:--  0:00:02 --:--:-- 0
100  781k  100  781k0 0   165k  0  0:00:04  0:00:04 --:--:--  376k
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:--  0:00:01 --:--:-- 0
curl: (52) Empty reply from server
make[3]: *** [/bng5/shashi-8/vpp5/vpp/dpdk/v0.48.tar.gz] Error 52
make[3]: Leaving directory `/bng5/shashi-8/vpp5/vpp/dpdk'
make[2]: *** [ebuild-build] Error 2
make[2]: Leaving directory `/bng5/shashi-8/vpp5/vpp/dpdk'

Re: [vpp-dev] Patches for 18.04

[Chris Luke]

You can cherry pick them to the stable branch, though preferably with a Jira ID 
in the first line (you can amend the commit message after you cherry pick it).

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of Thomas F Herbert
Sent: Friday, April 6, 2018 14:38
To: vpp-dev@lists.fd.io
Cc: vpp-dev ; Billy McFall 
Subject: [vpp-dev] Patches for 18.04


Chris,

I submitted two patches to master that should be in stable/18.04.

11556: Merged in Master: https://gerrit.fd.io/r/11556

11551: Submitted but not merged yet in master: https://gerrit.fd.io/r/11551

What should I do?

Should I resubmit both patches direct to stable/18.04?

--Tom
--
Thomas F Herbert
NFV and Fast Data Planes
Networking Group Office of the CTO
Red Hat

Re: [vpp-dev] 18.04 RC1 is cut, master and stable/1804 are open

[Chris Luke]

All,

I'm going to open up stable for patches now. I've tested the Ubuntu packages  
from Nexus (https://wiki.fd.io/view/VPP/Installing_VPP_binaries_from_packages) 
and they seem to install and run fine on a freshly installed VM. Packagecloud 
is still devoid of packages and LF admins are looking into why; it seems the 
push script stopped a while ago independently of RC1 branch.

Summary:

  *   VPP master branch is open for all patches slated for VPP 18.07 (and 
beyond) as normal.
  *   VPP branch stable/1804 is open for bug fix patches only.
Per the standard process, all bug fixes to the stable branch should follow the 
best practices:

  *   All bug fixes must be double-committed to the release throttle as well as 
to the master branch
 *   Commit first to the release throttle branch, then "git cherry-pick" 
into master
 *   Manual merges may be required, depending on the degree of divergence 
between throttle and master
  *   All bug fixes need to have a Jira ticket
 *   Please put Jira IDs into the commit messages.
 *   Please use the same Jira ID for both the stable branch and master.
Thanks go to Dave Barach for providing entertainment, Dave Wallace for his 
excellent rework of the guide, Vanessa and Ed Warnicke for their infrastructure 
support.

Cheers,
Chris

From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Chris Luke
Sent: Wednesday, April 4, 2018 22:40
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] 18.04 RC1 is cut, master is open again

All,

The stable/1804 branch was created earlier; master is now open again for 
general patches.

I'm not ready to accept fixes on the new stable branch. This is pending 
determining why packagecloud hasn't received any packages yet and giving the 
artifacts a test, but should have news on this tomorrow.

Chris.

[vpp-dev] 18.04 RC1 is cut, master is open again

[Chris Luke]

All,

The stable/1804 branch was created earlier; master is now open again for 
general patches.

I'm not ready to accept fixes on the new stable branch. This is pending 
determining why packagecloud hasn't received any packages yet and giving the 
artifacts a test, but should have news on this tomorrow.

Chris.

[vpp-dev] RC1 branch on Wednesday!

[Chris Luke]

All,

A reminder that the RC1 branch is this week on Wednesday! We’re still accepting 
low-risk patches on master ahead of the branch.

Milestone

Date

Deliverables

RC1

2018-04-04 (F0+14)

Code complete, pull first release throttle branch, only bug fixes accepted on 
throttle train. After pull: main branch reopens for new feature / risky 
commits. First artifacts posted.


Cheers,
Chris.

Re: [vpp-dev] Auto script invocation after VPP init completed

[Chris Luke]

The VPP config file (/etc/vpp/startup.conf) allows an "exec" command which 
loads a file and runs it like the lines are input to the CLI.

https://wiki.fd.io/view/VPP/Command-line_Arguments#.22unix.22_parameters see 
"exec"

which is closely related to the CLI command of the same name:

https://docs.fd.io/vpp/18.04/clicmd_src_vlib_unix_cli_c.html#clicmd_exec

Chris.

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Avi Cohen (A)
> Sent: Sunday, April 1, 2018 7:09
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Auto script invocation after VPP init completed
> 
> Hi All
> 
> I want to automatically invoke a script after VPP init is completed.
> This script just set all interfaces up and set ip-addresses
> 
> What us the best-practice for that ?
> 
> Best Regards
> Avi
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#8752): https://lists.fd.io/g/vpp-dev/message/8752
View All Messages In Topic (2): https://lists.fd.io/g/vpp-dev/topic/16658059
Mute This Topic: https://lists.fd.io/mt/16658059/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Semantics of field 'link_speed' in 'sw_interface_details' API.

[Chris Luke]

That only really leaves us one order of magnitude of growth…! :)

Chris

From:  on behalf of Damjan Marion 
Date: Thursday, March 29, 2018 at 12:53
To: "vpp-dev@lists.fd.io" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] Semantics of field 'link_speed' in 
'sw_interface_details' API.


Yes, but too late for 18.04. We can do that change later after rc1 is out.
I personally prefer that we simply keep speed as numeric value in 1kbps steps.
That should be fine for up to 4Tbps.


On 27 Mar 2018, at 14:58, Dmitry Vakhrushev 
> wrote:

Hi,

Changes in commit: 03f47f1e738051db1412a93c2b90a7426f81f648

This commit provided new ethernet speeds which store as speed bit in a 
variable. And the current version of API for 'sw_interface_details' is not 
correct for that changes.
Current variable in sw_interface_details API interface doesn't support all 
speeds because it was limited to 8 bits (this field has type u8).

I'd like to change the type to u32.

Can I do that?
Or can we change the semantics of representation of speed?
For example, speed in Mb or enum of speeds.

Now we have:
1) link_speed (now is u8, but need at least u16):
1 = 10M,
2 = 100M,
4 = 1G,
8 = 2_5G,
16 = 5G,
32 = 10G, etc.

We can do it like (need u32):
a) 10 = 10M.
100 = 100M,
1000 = 1G,
2500 = 2_5G,
5000 = 5G, etc.
or like this (need u8 field without changes):
b) 1 = 10M.
2 = 100M,
3 = 1G,
4 = 2_5G,
5 = 5G, etc.

Thank you,
-dmitry

[vpp-dev] RC1 branch in one week!

[Chris Luke]

All,

A reminder that the RC1 branch is in one week! We’re still accepting low-risk 
patches on master ahead of the branch.

Milestone

Date

Deliverables

RC1

2018-04-04 (F0+14)

Code complete, pull first release throttle branch, only bug fixes accepted on 
throttle train. After pull: main branch reopens for new feature / risky 
commits. First artifacts posted.


Cheers,
Chris.

[vpp-dev] API freeze today

[Chris Luke]

All,

Per https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_18.04,

Milestone

Date

Deliverables

F0

2018-03-21

APIs frozen. Only low-risk changes accepted on main branch.


VPP 18.04 is now at milestone F0.

This means no more API changes will be considered in master by committers until 
after the branch for RC1 on April 4th.

Additionally we avoid merging "risky" changes into master until the branch, 
unless there is reasonable justification.

Chris.

Re: [vpp-dev] Coverity Scan seems to be back

[Chris Luke]

Possibly, but that’s what my browser history had already anyway.

It seems they had a surge in initial jobs too; the one I kicked off is only 
just being analyzed at their end. One hopes and assumes this will improve.

Chris

From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Burt Silverman
Sent: Saturday, March 17, 2018 19:57
To: vpp-dev@lists.fd.io
Cc: vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Coverity Scan seems to be back

They set up scan.coverity.com<http://scan.coverity.com> so that if you type 
http://scan.coverity.com you might start thinking your home wlan is broken or 
your browser is broken because they don't automatically transfer you to 
https://scan.coverity.com. I guess they must be paranoid after the recent break 
in.
Burt

On Fri, Mar 16, 2018 at 5:36 PM, Chris Luke 
<chris_l...@comcast.com<mailto:chris_l...@comcast.com>> wrote:
Coverity’s Scan service appears to be back. They should have emailed registered 
users about resetting their passwords.

I’ve also kicked off a build to test it and get things going again.

Hopefully we have time to knock out some fixes for static analysis issues 
before the branch in a few weeks!

Chris.

[vpp-dev] Coverity Scan seems to be back

[Chris Luke]

Coverity's Scan service appears to be back. They should have emailed registered 
users about resetting their passwords.

I've also kicked off a build to test it and get things going again.

Hopefully we have time to knock out some fixes for static analysis issues 
before the branch in a few weeks!

Chris.

[vpp-dev] Reminder: 18.04 API freeze is next Wednesday!

[Chris Luke]

API freeze next week; get your API-related patches in soon!

https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_18.04

Milestone

Date

Deliverables

F0

2018-03-21

APIs frozen. Only low-risk changes accepted on main branch.



Cheers,
Chris.

Re: [vpp-dev] vppsb's librtnl is broken with top of VPP tree

[Chris Luke]

Oh, doh, it's vppsb that has the issue. I'll go back to sleep. :)

Chris

[vpp-dev] 18.04 API freeze in two weeks

[Chris Luke]

A friendly early warning folks: API freeze for the 18.04 release is in two 
weeks!

Milestone

Date

Deliverables

F0

2018-03-21

APIs frozen. Only low-risk changes accepted on main branch.


Cheers,
Chris

Re: [vpp-dev] VPP Node or plug-in load dynamically at run-time

[Chris Luke]

We’ve talked about it a few times. It’s not inconceivable to add the ability to 
load plugins at runtime but it would come with risks to stability and so quite 
unlikely.

Being able to unload them at runtime is however a complete non-starter without 
a herculean effort and even more serious risks; ergo, very unlikely.

Chris.

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Satish
Sent: Wednesday, February 14, 2018 9:22 AM
To: vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP Node or plug-in load dynamically at run-time

Thanks For the clarification Ray and the quick response :)

On Wed, Feb 14, 2018 at 7:49 PM, Ray Kinsella 
> wrote:
I don't believe it is.

Ray K


On 14/02/2018 14:19, satish karunanithi wrote:
Thanks for the pointers. But i would like to know is it possible to load the 
plugin/nodes without restarting the VPP?

Re: [vpp-dev] VPP code clarification

[Chris Luke]

Krishna,

I’ll try to give some high level guidance, however much of this is also 
explained in various places in the wiki. 
https://wiki.fd.io/view/File:Fd.io_vpp_overview_29.03.17.pptx is a good start.

There are two different uses of the word vector: As a dimensioned allocation of 
memory (so it can be used like an array) or as a bundle of packets that need to 
be processed. The latter is a specific case of the former.

The IP stack is built as a graph of nodes. Each node represents a small piece 
of the overall stack functionality. Further, each node in the graph processes 
all the packets it is presented with; this is the where vectors of packets are 
processed. If you look at the implementation of each node you will observe a 
while loop for this. In some cases VPP processes 2 or 4 packets in parallel in 
this loop by interleaving the instructions for more than one packet. This loop 
also determines the disposition of each packet which typically involves 
queueing it for another node; not all the packets in a single vector end up 
with the same outward disposition. Thus, there’s no single loop that alone 
processes packets, rather there’s a collection of loops that process parts of 
the network stack.

FIB lookup could happen in several places; but obvious places to look are nodes 
named something like ‘ip4-lookup’.

I hope that gets you started.

Chris.

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Krishna 
Tippur Gururaj
Sent: Friday, February 9, 2018 16:08
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP code clarification

Hello All,

I am a graduate student at Rochester Institute of Technology, NY, and I am 
working with Prof. Minseok Kwon on implementing various probabilistic filters 
around the VPP fib lookup logic.

I am having a hard time trying to figure out the code flow so I am sending this 
out requesting for some help on the same.

1. There is a point in the VPP code where the vector elements (packets) are 
looped over one by one; somewhere down the chain, the fib lookup is done for 
each packet. Could you please tell me where that "for" loop (or something 
similar) exists, from where each packet in a vector is processed individually?

2. I was trying to figure out how VPP determines the size of a vector while 
processing the packets. I found the vec_create() and other such calls in 
vppinfra/ but was unable to determine how they are used in actual packet 
processing. Could you please tell me where the vector size is determined?

Thanks in advance for the guidance and help!

--
Regards,
Krishna Tippur Gururaj
Computer Science graduate student, RIT
(585) 532-3636

[vpp-dev] FW: Coverity build failed with 18 errors

[Chris Luke]

FYI, Coverity has just failed to build because of issues in BIER (and maybe
VOM); some of these may have existed a while, because these all seem to be
warnings and Coverity fails a build based on number of rejected build units
exceeding a % threshold. Likely BIER was merged and triggered the threshold.

I note that BIER is using C99 stdint types; Coverity appears to be fussy
about how these get defined (missing include?); also we agreed here on this
list just a few weeks ago that VPP uses its own typedefs for specified-width
integers (u64 etc) so we should not be using such C99 types anyway.

For those interested, the Coverity build log is available at
https://vpp.flirble.org/coverity/20171109/build-log.txt though please don't
ask me to interpret it!

Chris.

-Original Message-
From: VPP [mailto:v...@brae.flirble.org] 
Sent: Thursday, November 9, 2017 15:29
To: chr...@flirble.org
Subject: Coverity build failed with 18 errors

Coverity build failed with 18 errors.

Latest commit: v18.01-rc0-251-g75e974b

Error counts from cov-int/build-log.txt:
84205:[ERROR] [104291] EXECUTING: /bin/sed s|:*$||
84459:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/fib/fib_path.c".
91374:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_fmask.c".
91462:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_fmask_db.c".
91532:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_entry.c".
91700:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_output.c".
91775:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_table.c".
91828:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_lookup.c".
91840:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_fmask.c".
91847:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_fmask_db.c".
91954:[ERROR] 5 errors detected in the compilation of
"../../../src/vnet/bier/bier_types.c".
91982:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_entry.c".
92104:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_output.c".
92160:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_table.c".
92396:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_lookup.c".
92796:[ERROR] 5 errors detected in the compilation of
"../../../src/vnet/bier/bier_types.c".
93191:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_test.c".
93644:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_test.c".

Probable error information from the compiler:
84180:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_fmas
k.h",
84181-  line 57: error #20: identifier "uint32_t" is undefined
84182-  uint32_t bfmb_count;
84183-  ^
--
84428:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_fmas
k.h",
84429-  line 57: error #20: identifier "uint32_t" is undefined
84430-  uint32_t bfmb_count;
84431-  ^
--
87392:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_
string
87393-  .h", line 56: warning #20: identifier "uint16_t" is
undefined
87394-  uint16_t index;
87395-  ^
--
87397:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_
string
87398-  .h", line 72: warning #20: identifier "uint16_t" is
undefined
87399-  uint16_t index;
87400-  ^
--
87402:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_
string
87403-  .h", line 87: warning #20: identifier "uint16_t" is
undefined
87404-  uint16_t index;
87405-  ^
--
87423:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_
string
87424-  .h", line 54: warning #1563: function
"bier_bit_string_is_zero" not
87425-  emitted, consider modeling it or review parse diagnostics to
improve
87426-  fidelity
--
87430:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_
string
87431-  .h", line 69: warning #1563: function
"bier_bit_string_clear_string"
87432-  not emitted, consider modeling it or review parse
diagnostics to
87433-  improve fidelity
--
87437:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_
string
87438-  .h", line 84: warning #1563: function
87439-  "bier_bit_string_logical_and_string" not emitted, consider
modeling
87440-  it or review parse diagnostics to improve fidelity
--
87868:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_
string
87869-  .h", line 56: warning #20: identifier "uint16_t" is
undefined
87870-  uint16_t index;
87871-  ^
--
87873:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_
string
87874-  .h", line 72: warning #20: identifier "uint16_t" is
undefined