[vpp-dev] Coverity run FAILED as of 2020-03-04 14:00:24 UTC

[Noreply Jenkins]

Coverity run failed today.

Current number of outstanding issues are 3
Newly detected: 0
Eliminated: 1
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 (#15681): https://lists.fd.io/g/vpp-dev/message/15681
Mute This Topic: https://lists.fd.io/mt/71726679/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 increase the size of vlib buffer opaque2

[Dave Barach via Lists.Fd.Io]

There is no chance that such a patch would be merged on my watch. Please 
allocate your use-case-specific metadata from a pool, and carry the metadata 
pool index in opaque2 (or opaque, if you can swing it).

Bloating the vlib_buffer_t to carry use-case-specific metadata is a non-starter.

Dave

From: vpp-dev@lists.fd.io  On Behalf Of Satya Murthy
Sent: Tuesday, March 3, 2020 11:12 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Can i increase the size of vlib buffer opaque2

We are currently using opaque2 which has 10 uint32.
Can i increase this size to 30 uint32s.
What kind of impact/restrictions we have for this opaque2 metadata sizes.

Please let us know.

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

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

[vpp-dev] Ip6 nd not working

[Alberto Compagno via Lists.Fd.Io]

Hi,

I’m experiencing problem with the nd protocol.
I have two nodes, on each of them I have a vf and the underlying pf are 
directly connected through a physical link. In node 1, networking is handled by 
the kernel. In node 2, vpp 20.01 takes care of it.
On both nodes I have configured an ipv6 address (3001::1/64 an 3001::2/64). In 
vpp, I enabled ip6 on the vf and brought the interface up.

The output of show ip6 interfaces is:

VirtualFunctionEthernet3/0/0 is admin up
  Link-local address(es):
fe80::250:56ff:fe87:4611
  Joined group address(es):
ff02::1
ff02::2
ff02::16
  Neighbor Discovery: enabled
ICMP redirects are disabled
ICMP unreachables are not sent
ND DAD is disabled
  Advertised Prefixes:
MTU is 9000
ICMP error messages are unlimited
ICMP redirects are disabled
ICMP unreachables are not sent
ND DAD is disabled
ND advertised reachable time is 0
ND advertised retransmit interval is 0 (msec)
ND router advertisements are sent every 200.0 seconds (min interval is 
150.0)
ND router advertisements live for 600 seconds
Hosts  don't use stateless autoconfig for addresses
ND router advertisements sent 1
ND router solicitations received 0
ND router solicitations dropped 0


If I ping from node 1 to node 2, I can see that neighbor solicitation packets 
(with multicast mac address 33:33:ff:00:00:01) are sent to node 2, however from 
the vpp I don’t see such packets.
Trace is empy as well as vpp counters (show hardware-interfaces) do not 
increase. If I ping from node 2 to node 1 everything works fine.
It seems that packets with a multicast mac address are discarded by the vf, any 
idea why? Might it be a driver problem (I’m using the uio_pci_generic and dpdk 
version is 19.08.0)?

I doubled check the link connectivity by replacing the node running vpp, with a 
node where the kernel handles the networking and everything works fine (ip6 nd 
included).

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

View/Reply Online (#15683): https://lists.fd.io/g/vpp-dev/message/15683
Mute This Topic: https://lists.fd.io/mt/71727120/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 some API changes for 19.08, et al. release branches?

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io]

>> Does that mean we want an api-crc job also for 1908 stream?

After some backporting, CSIT is ready for that job now.
All it takes is a VPP developer to vote +1 (or -1)
this [1] ci-management change.

Vratko.

[1] https://gerrit.fd.io/r/c/ci-management/+/25457

From: vpp-dev@lists.fd.io  On Behalf Of Vratko Polak -X 
(vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io
Sent: Thursday, 2020-February-27 14:56
To: Andrew Yourtchenko 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release 
branches?

> Adding a new API into an existing file will still change the CRC on the 
> plugin/module

Looking into a .api.json file, I see "crc" only for messages,
but the whole file also ends with a "vl_api_version" value.

> if we are aiming for binary compatibility

Crc values guard against backward-incompatible edits.
Vl_api_version changes even for backward compatible edits
(within the same .api file), so perhaps we can tolerate such change.

Vratko.

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Andrew 
Yourtchenko
Sent: Wednesday, February 26, 2020 6:19 PM
To: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) 
mailto:vrpo...@cisco.com>>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release 
branches?

Hmm so that’s an interesting question. Adding a new API into an existing file 
will still change the CRC on the plugin/module - which means that if we are 
aiming for binary compatibility (which is I think what we are doing) - it means 
we can only allow the one-shot addition of new .api files, right ?

--a

On 26 Feb 2020, at 17:26, Vratko Polak -X (vrpolak - PANTHEON TECH SRO at 
Cisco) mailto:vrpo...@cisco.com>> wrote:

> as soon as the CRC of any existing messages does not change, a patch is okay 
> to include into 19.08

Does that mean we want an api-crc job also for 1908 stream?
We currently have api-crc job only for master,
because other branches were not expected to edit .api files.

Vratko.

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Andrew 
Yourtchenko
Sent: Tuesday, February 25, 2020 6:49 PM
To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>
Cc: Christian Hopps mailto:cho...@chopps.org>>; vpp-dev 
mailto:vpp-dev@lists.fd.io>>; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release 
branches?

With my 19.08 release manager hat on,
For the current state of the matters my view is “as soon as the CRC of any 
existing messages does not change, a patch is okay to include into 19.08”.

This applies recursively, meaning that if one add a new message to 1908, it 
comes in as “frozen” with no further changes. Why ? Because if it is not 
perfect API wise it’s not stable, it should first settle down on master.

That’s the logic I had been using so far.

I am currently working on an 19.08 api translation layer  experiment that in 
principle should allow more freedom... but till that is successful that is my 
point of view. Unless the community decides otherwise, of course.

--a


On 25 Feb 2020, at 16:56, Dave Barach via Lists.Fd.Io 
mailto:dbarach=cisco@lists.fd.io>> wrote:

Dear Chris,

Adding missing flags to ipsec_sad_flags shouldn’t break much of anything. Never 
say never, but for me, I wouldn’t hesitate to merge such a patch.

Adding an entirely new message will renumber subsequent core engine messages, 
and implies client recompilation. My $0.02: again, not such a big deal.

What do other people think?

Dave

P.S. in master/latest, enum ipsec_sad_flags has moved to 
.../src/vnet/ipsec/ipsec_types.api...


From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Christian Hopps
Sent: Tuesday, February 25, 2020 10:25 AM
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: Christian Hopps mailto:cho...@chopps.org>>
Subject: [vpp-dev] Can I submit some API changes for 19.08, et al. release 
branches?

I've got a couple of changes to the ipsec API that I'd like to upstream to 
match the vpp "kernel" code I'm going try and upstream to strongswan.

1) Add: Add an ip_route_lookup/reply pair (semver minor++)
2) Fix: Add IS_INBOUND flag (value 0x40) to ipsec_sad_flags (semver patch++)
optional) Fix: possibly add the other missing flags to ipsec_sad_flags so they 
can be properly returned on queries.

I think submitting these for release branches is OK after reading 
https://wiki.fd.io/view/VPP/API_Versioning

I'm coding to 19.08 right now, if I'd like to have those changes in that branch 
I would imagine I'd need to also submit changes for 20.01 and master?

I admit to being confused about the CRC stuff, and the warnings in the 19.08.1 
release notes and what those warnings imply. Is it safe to assume the CRC stuff 
can be ignored and external clients will still work (given 

[vpp-dev] 20.05 DRAFT release plan available

[Andrew Yourtchenko]

Hi all,

I've prepared the draft release plan for 20.05, it is at
https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_20.05

I will be on vacation for the next couple of weeks so won't make the
community meeting to discuss it.

Thanks a lot to Dave Wallace for kindly agreeing to do it - as well as
be point of contact in case you have other matters that require
"Release manager" hat to deal with.

I will have very limited connectivity until 19th March.


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

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

[vpp-dev] setting CLIB_DEBUG value

[sothy]

Hello,
I want to debug the VPP and plugins. so I want to set CLIB_DEBUG=5  I dont
know how to do it; pls help me.

I do following command to run debug symbols:

to compile:

make pkg-deb-debug V=1
to install:

sudo apt-get install --no-install-recommends -yy liblz4-tool tar
./build-root/vpp_*.deb ./build-root/vpp-plugin-core_*.deb
./build-root/libvppinfra_*.deb .//build-root/vpp-api-python_*.deb

In this I cannt set CLIB_DEBUG value. Am I right?

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

View/Reply Online (#15687): https://lists.fd.io/g/vpp-dev/message/15687
Mute This Topic: https://lists.fd.io/mt/71735634/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] setting CLIB_DEBUG value

[Dave Barach via Lists.Fd.Io]

See .../src/CMakeLists.txt, add =5 here:

string(CONCAT CMAKE_C_FLAGS_DEBUG
  "-O0 "
  "-DCLIB_DEBUG "
  "-fstack-protector "
  "-DFORTIFY_SOURCE=2 "
  "-fno-common "

Rebuild w/ “make build” or “make pkg-deb-debug”


From: vpp-dev@lists.fd.io  On Behalf Of sothy
Sent: Wednesday, March 4, 2020 4:09 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] setting CLIB_DEBUG value

Hello,
I want to debug the VPP and plugins. so I want to set CLIB_DEBUG=5  I dont know 
how to do it; pls help me.

I do following command to run debug symbols:

to compile:

make pkg-deb-debug V=1
to install:

sudo apt-get install --no-install-recommends -yy liblz4-tool tar 
./build-root/vpp_*.deb ./build-root/vpp-plugin-core_*.deb 
./build-root/libvppinfra_*.deb .//build-root/vpp-api-python_*.deb

In this I cannt set CLIB_DEBUG value. Am I right?

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

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

[vpp-dev] VPP with FRR Bring-up - tap interface enable causing crash

[Majumdar, Kausik]

Hi All,

I am experiencing VPP crash when I am trying to bring the link up for the VPP 
tap interfaces in Linux. Is this a known issue ? I have tried it few items to 
bring the VPP tap interfaces link up and each time I see VPP crashing. Please 
let me know if there is any workaround.


vpp# show interface
  Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
Counter  Count
TenGigabitEthernet7/0/0   1 down 9000/0/0/0
TenGigabitEthernet7/0/1   2 down 9000/0/0/0
local00 down  0/0/0/0
vpp#
vpp# set interface state TenGigabitEthernet7/0/0 up
vpp# set interface state TenGigabitEthernet7/0/1 up
vpp# set interface ip address TenGigabitEthernet7/0/0 10.0.10.2/24
vpp# set interface ip address TenGigabitEthernet7/0/1 10.0.20.2/24
vpp# show tap
tap tap-inject
vpp# show tap-inject
TenGigabitEthernet7/0/0 -> vpp0
TenGigabitEthernet7/0/1 -> vpp1
vpp#

# ip addr add 10.0.10.2/24 dev vpp0
# ip addr add 10.0.20.2/24 dev vpp1
# ip link set dev vpp0 up
# ip link set dev vpp1 up
Cannot find device "vpp1"
#


/var/log/syslog -

Mar  4 13:38:13 root NetworkManager[1175]:   [1583357893.7966] manager: 
(vpp0): new Tun device (/org/freedesktop/NetworkManager/Devices/30)
Mar  4 13:38:13 root NetworkManager[1175]:   [1583357893.8181] devices 
added (path: /sys/devices/virtual/net/vpp0, iface: vpp0)
Mar  4 13:38:13 root NetworkManager[1175]:   [1583357893.8181] device 
added (path: /sys/devices/virtual/net/vpp0, iface: vpp0): no ifupdown 
configuration found.
Mar  4 13:38:13 root NetworkManager[1175]:   [1583357893.8221] manager: 
(vpp1): new Tun device (/org/freedesktop/NetworkManager/Devices/31)
Mar  4 13:38:13 root NetworkManager[1175]:   [1583357893.8423] devices 
added (path: /sys/devices/virtual/net/vpp1, iface: vpp1)
Mar  4 13:38:13 root NetworkManager[1175]:   [1583357893.8423] device 
added (path: /sys/devices/virtual/net/vpp1, iface: vpp1): no ifupdown 
configuration found.


Mar  4 13:41:07 root avahi-daemon[1097]: Joining mDNS multicast group on 
interface vpp0.IPv4 with address 10.0.10.2.
Mar  4 13:41:07 root NetworkManager[1175]:   [1583358067.6687] device 
(vpp0): state change: unmanaged -> unavailable (reason 'connection-assumed') 
[10 20 41]
Mar  4 13:41:07 root avahi-daemon[1097]: New relevant interface vpp0.IPv4 for 
mDNS.
Mar  4 13:41:07 root avahi-daemon[1097]: Registering new address record for 
10.0.10.2 on vpp0.IPv4.
Mar  4 13:41:07 root NetworkManager[1175]:   [1583358067.6701] keyfile: 
add connection in-memory (48ac355a-b5dd-4099-8ece-7b9137770887,"vpp0")
Mar  4 13:41:07 root NetworkManager[1175]:   [1583358067.6711] device 
(vpp0): state change: unavailable -> disconnected (reason 'connection-assumed') 
[20 30 41]
Mar  4 13:41:07 root NetworkManager[1175]:   [1583358067.6726] device 
(vpp0): Activation: starting connection 'vpp0' 
(48ac355a-b5dd-4099-8ece-7b9137770887)
Mar  4 13:41:07 root vpp[18936]: /usr/bin/vpp: symbol lookup error: 
/usr/lib/x86_64-linux-gnu/vpp_plugins/router.so: undefined symbol: 
vlib_buffer_alloc_from_free_list
Mar  4 13:41:07 root NetworkManager[1175]:   [1583358067.6793] device 
(vpp0): state change: disconnected -> prepare (reason 'none') [30 40 0]
Mar  4 13:41:07 root NetworkManager[1175]:   [1583358067.6803] device 
(vpp0): state change: prepare -> config (reason 'none') [40 50 0]
Mar  4 13:41:07 root NetworkManager[1175]:   [1583358067.6822] device 
(vpp0): state change: config -> ip-config (reason 'none') [50 70 0]
Mar  4 13:41:07 root NetworkManager[1175]:   [1583358067.6925] device 
(vpp0): state change: ip-config -> ip-check (reason 'none') [70 80 0]
Mar  4 13:41:07 root NetworkManager[1175]:   [1583358067.6932] devices 
removed (path: /sys/devices/virtual/net/vpp1, iface: vpp1)
Mar  4 13:41:07 root NetworkManager[1175]:   [1583358067.6937] device 
(vpp0): state change: ip-check -> secondaries (reason 'none') [80 90 0]
Mar  4 13:41:07 root NetworkManager[1175]:   [1583358067.6941] device 
(vpp0): state change: secondaries -> activated (reason 'none') [90 100 0]
Mar  4 13:41:07 root NetworkManager[1175]:   [1583358067.6950] device 
(vpp0): Activation: successful, device activated.
Mar  4 13:41:07 root dbus[1099]: [system] Activating via systemd: service 
name='org.freedesktop.nm_dispatcher' 
unit='dbus-org.freedesktop.nm-dispatcher.service'
Mar  4 13:41:07 root avahi-daemon[1097]: Interface vpp0.IPv4 no longer relevant 
for mDNS.
Mar  4 13:41:07 root avahi-daemon[1097]: Leaving mDNS multicast group on 
interface vpp0.IPv4 with address 10.0.10.2.
Mar  4 13:41:07 root systemd[1]: Starting Network Manager Script Dispatcher 
Service...
Mar  4 13:41:07 root avahi-daemon[1097]: Withdrawing address record for 
10.0.10.2 on vpp0.
Mar  4 13:41:07 root NetworkManager[1175]:   [1583358067.7374] device 
(vpp0): state change: activated -> unmanaged (reason 'unmanaged') [100 10 3]
Mar  4 13:41:07 root NetworkManager[1175]:   [1583358067.7401] devices 
removed (path: /sys/