[vpp-dev] VPP build failure in master branch - plugins/quic

[Majumdar, Kausik]

Hi All,

I have pulled latest VPP codebase from the master and tried to run "build.sh" 
from the /vpp/build-root/vagrant folder. I see following build errors. Anyone 
seen this ? Is there any patch available ?

I didn't see it when I built from v20.01 release.

[1671/1816] Building C object plugins/quic/CMakeFiles/quic_plugin.dir/quic.c.o
FAILED: plugins/quic/CMakeFiles/quic_plugin.dir/quic.c.o
/opt/rh/devtoolset-7/root/bin/cc -Dquic_plugin_EXPORTS 
-I/root/vpp_master/vpp/build-root/rpmbuild/vpp-20.05/src -I. -Iinclude 
-I/root/vpp_master/vpp/build-root/rpmbuild/vpp-20.05/src/plugins -Iplugins 
-I/opt/vpp/external/x86_64/include -Wno-address-of-packed-member -g -fPIC 
-Werror -Wall -march=corei7 -mtune=corei7-avx  -O2 -fstack-protector 
-DFORTIFY_SOURCE=2 -fno-common  -fPIC -MD -MT 
plugins/quic/CMakeFiles/quic_plugin.dir/quic.c.o -MF 
plugins/quic/CMakeFiles/quic_plugin.dir/quic.c.o.d -o 
plugins/quic/CMakeFiles/quic_plugin.dir/quic.c.o   -c 
/root/vpp_master/vpp/build-root/rpmbuild/vpp-20.05/src/plugins/quic/quic.c
/root/vpp_master/vpp/build-root/rpmbuild/vpp-20.05/src/plugins/quic/quic.c: In 
function 'quic_init_crypto_context':
/root/vpp_master/vpp/build-root/rpmbuild/vpp-20.05/src/plugins/quic/quic.c:277:32:
 error: 'quicly_transport_parameters_t {aka struct 
st_quicly_transport_parameters_t}' has no member named 'max_idle_timeout'; did 
you mean 'idle_timeout'?
   quicly_ctx->transport_params.max_idle_timeout = qm->connection_timeout;
^~~~
idle_timeout
/root/vpp_master/vpp/build-root/rpmbuild/vpp-20.05/src/plugins/quic/quic.c: At 
top level:
cc1: error: unrecognized command line option '-Wno-address-of-packed-member' 
[-Werror]
cc1: all warnings being treated as errors
[1672/1816] Building C object 
plugins/quic/CMakeFiles/quic_plugin.dir/quic_crypto.c.o
FAILED: plugins/quic/CMakeFiles/quic_plugin.dir/quic_crypto.c.o
/opt/rh/devtoolset-7/root/bin/cc -Dquic_plugin_EXPORTS 
-I/root/vpp_master/vpp/build-root/rpmbuild/vpp-20.05/src -I. -Iinclude 
-I/root/vpp_master/vpp/build-root/rpmbuild/vpp-20.05/src/plugins -Iplugins 
-I/opt/vpp/external/x86_64/include -Wno-address-of-packed-member -g -fPIC 
-Werror -Wall -march=corei7 -mtune=corei7-avx  -O2 -fstack-protector 
-DFORTIFY_SOURCE=2 -fno-common  -fPIC -MD -MT 
plugins/quic/CMakeFiles/quic_plugin.dir/quic_crypto.c.o -MF 
plugins/quic/CMakeFiles/quic_plugin.dir/quic_crypto.c.o.d -o 
plugins/quic/CMakeFiles/quic_plugin.dir/quic_crypto.c.o   -c 
/root/vpp_master/vpp/build-root/rpmbuild/vpp-20.05/src/plugins/quic/quic_crypto.c
/root/vpp_master/vpp/build-root/rpmbuild/vpp-20.05/src/plugins/quic/quic_crypto.c:
 In function 'quic_crypto_decrypt_packet':
/root/vpp_master/vpp/build-root/rpmbuild/vpp-20.05/src/plugins/quic/quic_crypto.c:258:5:
 error: implicit declaration of function 
'quicly_get_next_expected_packet_number'; did you mean 
'quicly_determine_packet_number'? [-Werror=implicit-function-declaration]
 quicly_get_next_expected_packet_number (qctx->conn);
 ^~
 quicly_determine_packet_number
/root/vpp_master/vpp/build-root/rpmbuild/vpp-20.05/src/plugins/quic/quic_crypto.c:
 At top level:
cc1: error: unrecognized command line option '-Wno-address-of-packed-member' 
[-Werror]
cc1: all warnings being treated as errors
[1674/1816] Building C object 
plugins/rdma/CMakeFiles/rdma_plugin_avx2.dir/input.c.o
ninja: build stopped: subcommand failed.
make[3]: *** [Makefile:693: vpp-build] Error 1
make[3]: Leaving directory 
'/root/vpp_master/vpp/build-root/rpmbuild/vpp-20.05/build-root'
make[2]: *** [Makefile:929: install-packages] Error 1
make[2]: Leaving directory 
'/root/vpp_master/vpp/build-root/rpmbuild/vpp-20.05/build-root'
error: Bad exit status from /var/tmp/rpm-tmp.uvq9PV (%build)


RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.uvq9PV (%build)
make[1]: *** [RPM] Error 1
make[1]: Leaving directory `/root/vpp_master/vpp/extras/rpm'
make: *** [pkg-rpm] Error 2
[root@localhost vagrant]#

Thanks,
Kausik

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

View/Reply Online (#15669): https://lists.fd.io/g/vpp-dev/message/15669
Mute This Topic: https://lists.fd.io/mt/71693777/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] Issue with ipsec (dpdk) and SA deletion?

[Sergio G.M.]

Hi Christian,

I don't think you have missed anything, as far as I can tell it is a bug.
Wondering how it is done in the non-DPDK case with handoff. I don't know
the handoff internals but from a quick glance, and I might be wrong here,
it seems that you would run into a similar situation.

Cheers,
Sergio

On Mon, Mar 2, 2020 at 8:49 PM Christian Hopps  wrote:

> So this came up in another thread for a question I had about locking, but
> I didn't want the point to get lost since a lot of other things were
> discussed.
>
> When an SA is deleted it is done from an API that is not marked mp safe,
> therefore it is done with the worker thread barrier. The ipsec code then
> assumes it is safe to delete the SA data, and does so.
>
> However, packets associated with the now deleted SA may exist in the
> middle of traversing the node graph on the dpdk crypto offload device
> queue. So, after the SA is deleted and the API releases the barrier, the
> crypto-input polling node will start running again, dequeueing newly
> decrypted (or encrypted) packets and injecting them back into the node
> graph.
>
> I believe this is a problem e.g., taking a look at
> https://github.com/FDio/vpp/blob/master/src/plugins/dpdk/ipsec/esp_decrypt.c#L543
>
> This is extracting the sa_index from the buffer, getting a pointer to the
> data and then acting on it. In fact, this SA (pool element) may no longer
> be valid, or it may have been re-used at this point.
>
> Is this a bug, or have I missed something?
>
> Thanks,
> Chris.
>
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15667): https://lists.fd.io/g/vpp-dev/message/15667
Mute This Topic: https://lists.fd.io/mt/71683366/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: [vpp-dev] APPROVED: add Matt Smith as a vpp committer, subject to TSC approval this Thursday

[Matthew Smith via Lists.Fd.Io]

Thanks Dave (et al)!!

-Matt


On Mon, Mar 2, 2020 at 2:52 PM Dave Barach via 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 (#15665): https://lists.fd.io/g/vpp-dev/message/15665
Mute This Topic: https://lists.fd.io/mt/71684715/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Dave Barach via Lists.Fd.Io]

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 (#15664): https://lists.fd.io/g/vpp-dev/message/15664
Mute This Topic: https://lists.fd.io/mt/71684715/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 committers: formal vote to add Matt Smith as a vpp committer

[Dave Wallace]

+1

On 3/2/2020 9:15 AM, d...@barachs.net wrote:


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

[vpp-dev] Issue with ipsec (dpdk) and SA deletion?

[Christian Hopps]

So this came up in another thread for a question I had about locking, but I 
didn't want the point to get lost since a lot of other things were discussed.

When an SA is deleted it is done from an API that is not marked mp safe, 
therefore it is done with the worker thread barrier. The ipsec code then 
assumes it is safe to delete the SA data, and does so.

However, packets associated with the now deleted SA may exist in the middle of 
traversing the node graph on the dpdk crypto offload device queue. So, after 
the SA is deleted and the API releases the barrier, the crypto-input polling 
node will start running again, dequeueing newly decrypted (or encrypted) 
packets and injecting them back into the node graph.

I believe this is a problem e.g., taking a look at 
https://github.com/FDio/vpp/blob/master/src/plugins/dpdk/ipsec/esp_decrypt.c#L543

This is extracting the sa_index from the buffer, getting a pointer to the data 
and then acting on it. In fact, this SA (pool element) may no longer be valid, 
or it may have been re-used at this point.

Is this a bug, or have I missed something?

Thanks,
Chris.


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

View/Reply Online (#15662): https://lists.fd.io/g/vpp-dev/message/15662
Mute This Topic: https://lists.fd.io/mt/71683366/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: [vpp-dev] vpp project committers: formal vote to add Matt Smith as a vpp committer

[Paul Vinciguerra]

+1

> On Mar 2, 2020, at 9:20 AM, d...@barachs.net wrote:
> 
> 
> 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 (#15660): https://lists.fd.io/g/vpp-dev/message/15660
Mute This Topic: https://lists.fd.io/mt/71675525/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 does not start: Comm: vpp Not tainted 4.15.0-88-generic

[Pac Ette]

Will downgrade to previous Kernel version (4.15.0-76-generic).

Thanks Benoit and Dave!

On Mon, Mar 2, 2020 at 5:21 AM Dave Barach (dbarach) 
wrote:

> Known kernel bug. See https://bugzilla.kernel.org/show_bug.cgi?id=206133.
> Workaround: stick with 4.15.0-76-generic until the kernel fix propagates.
>
>
>
> D.
>
>
>
> *From:* vpp-dev@lists.fd.io  *On Behalf Of *Pac Ette
> *Sent:* Sunday, March 1, 2020 10:07 PM
> *To:* vpp-dev@lists.fd.io
> *Subject:* [vpp-dev] VPP does not start: Comm: vpp Not tainted
> 4.15.0-88-generic
>
>
>
> Hi,
>
>
>
> I am running VPP 20.02 compiled on machine with 4.15.0-88-generic.
>
> VPP does not start and when I reboot the machine, reboot just hangs trying
> to kill VPP process.
>
>
>
> It works fine on 4.15.0-76-generic.
>
>
>
> Here is the info for error:
>
>
>
> 4.15.0-88-generic
> Distributor ID: Ubuntu
> Description: Ubuntu 18.04.3 LTS
> Release: 18.04
> Codename: bionic
>
>
>
> [   21.504715] general protection fault:  [#1] SMP NOPTI
> [   21.510161] Modules linked in: overlay arc4 uio_pci_generic uio
> intel_rapl pnd2_edac x86_pkg_temp_thermal intel_powerclamp coretemp
> kvm_intel kvm ath10k_pci ath10k_core irqbypass intel_cstate ath
> intel_rapl_perf mac80211 cdc_ether qmi_wwan qcserial r8152 cdc_wdm usb_wwan
> usbserial usbnet mii cfg80211 mac_hid shpchp sch_fq_codel ib_iser rdma_cm
> iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
> ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456
> async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq
> libcrc32c raid1 raid0 multipath linear dm_snapshot dm_bufio
> crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel
> aes_x86_64 ixgbe crypto_simd glue_helper igb cryptd ahci i2c_algo_bit dca
> ptp mdio pps_core libahci i2c_ismt
> [   21.579798] CPU: 1 PID: 740 Comm: vpp Not tainted 4.15.0-88-generic
> #88-Ubuntu
> [   21.594649] RIP: 0010:remove_files.isra.1+0x24/0x70
> [   21.599566] RSP: 0018:b6da00dabc00 EFLAGS: 00010282
> [   21.604870] RAX: c5e978b250456029 RBX: 9200ee82a000 RCX:
> 
> [   21.612079] RDX: 9200effe1488 RSI: 9200ee82a000 RDI:
> 9200eee43330
> [   21.619307] RBP: b6da00dabc18 R08:  R09:
> 9200ee806d60
> [   21.626535] R10: b6da00dabc18 R11:  R12:
> 9200eee43330
> [   21.633737] R13: 9200effe1488 R14:  R15:
> 0060
> [   21.640949] FS:  7f87f5ec87c0() GS:9200ffd0()
> knlGS:
> [   21.649121] CS:  0010 DS:  ES:  CR0: 80050033
> [   21.654918] CR2: 55d986512298 CR3: 645d2000 CR4:
> 003406e0
> [   21.662095] Call Trace:
> [   21.664587]  sysfs_remove_group+0x44/0x90
> [   21.668639]  sysfs_remove_groups+0x2e/0x50
> [   21.672742]  device_remove_attrs+0x47/0x80
> [   21.676872]  device_del+0x161/0x3b0
> [   21.680400]  cdev_device_del+0x1a/0x40
> [   21.684180]  posix_clock_unregister+0x26/0x50
> [   21.688560]  ptp_clock_unregister+0x72/0x80 [ptp]
> [   21.693305]  igb_ptp_stop+0x23/0x50 [igb]
> [   21.697360]  igb_remove+0x4b/0x170 [igb]
> [   21.701315]  pci_device_remove+0x3e/0xb0
> [   21.705266]  device_release_driver_internal+0x13a/0x220
> [   21.710552]  device_release_driver+0x12/0x20
> [   21.714841]  unbind_store+0x87/0x150
> [   21.718439]  drv_attr_store+0x27/0x40
> [   21.722131]  sysfs_kf_write+0x3c/0x50
> [   21.725857]  kernfs_fop_write+0x125/0x1a0
> [   21.729895]  __vfs_write+0x1b/0x40
> [   21.75]  vfs_write+0xb1/0x1a0
> [   21.736672]  SyS_write+0x5c/0xe0
> [   21.739915]  do_syscall_64+0x73/0x130
> [   21.743644]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> [   21.748772] RIP: 0033:0x7f87f45eb281
> [   21.752358] RSP: 002b:7f87b38d19a8 EFLAGS: 3246 ORIG_RAX:
> 0001
> [   21.759993] RAX: ffda RBX: 7f87b3a31300 RCX:
> 7f87f45eb281
> [   21.767186] RDX: 000c RSI: 7f87b3a31300 RDI:
> 000c
> [   21.774381] RBP: 000c R08: 0010 R09:
> 
> [   21.781609] R10: 000e R11: 3246 R12:
> 7f87b3a31380
> [   21.788783] R13: 7f87b3a31380 R14: 55847edfcda2 R15:
> 7f87b4551150
> [   21.795980] Code: 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 85 f6 48 89
> e5 41 55 41 54 49 89 d5 53 49 89 fc 74 24 48 8b 06 48 89 f3 48 85 c0 74 19
> <48> 8b 30 31 d2 48 83 c3 08 4c 89 e7 e8 bb d4 ff ff 48 8b 03 48
> [   21.815037] RIP: remove_files.isra.1+0x24/0x70 RSP: b6da00dabc00
> [   21.821489] ---[ end trace 85030bc0a549fa72 ]---
>
>
>
>
>
> ● vpp.service - vector packet processing engine
>Loaded: loaded (/lib/systemd/system/vpp.service; enabled; vendor
> preset: enabled)
>   Drop-In: /etc/systemd/system/vpp.service.d
>└─override.conf
>Active: activating (start-post) (Result: signal) since Mon 2020-03-02
> 02:48:15 UTC; 1min 15s ago
>   Process: 740 ExecStart=/usr/bin/vpp -c /etc/vpp/startup.conf
> 

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

[Damjan Marion via Lists.Fd.Io]

+1

> On 2 Mar 2020, at 15:15, d...@barachs.net wrote:
> 
> 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 (#15658): https://lists.fd.io/g/vpp-dev/message/15658
Mute This Topic: https://lists.fd.io/mt/71675525/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 committers: formal vote to add Matt Smith as a vpp committer

[John Lo (loj) via Lists.Fd.Io]

+1   -John

From: vpp-dev@lists.fd.io  On Behalf Of d...@barachs.net
Sent: Monday, March 02, 2020 9:16 AM
To: vpp-dev@lists.fd.io
Subject: [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 (#15657): https://lists.fd.io/g/vpp-dev/message/15657
Mute This Topic: https://lists.fd.io/mt/71675525/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 committers: formal vote to add Matt Smith as a vpp committer

[Florin Coras]

+1

Regards,
Florin

> On Mar 2, 2020, at 6:15 AM, d...@barachs.net wrote:
> 
> 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 (#15656): https://lists.fd.io/g/vpp-dev/message/15656
Mute This Topic: https://lists.fd.io/mt/71675525/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 committers: formal vote to add Matt Smith as a vpp committer

[Dave Barach via Lists.Fd.Io]

+1 for me.

From: vpp-dev@lists.fd.io  On Behalf Of Edward Warnicke
Sent: Monday, March 2, 2020 10:06 AM
To: Ole Troan 
Cc: Dave Barach ; vpp-dev 
Subject: Re: [vpp-dev] vpp project committers: formal vote to add Matt Smith as 
a vpp committer

> On 2 Mar 2020, at 15:15, d...@barachs.net wrote:
>
> 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 (#15655): https://lists.fd.io/g/vpp-dev/message/15655
Mute This Topic: https://lists.fd.io/mt/71675525/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 committers: formal vote to add Matt Smith as a vpp committer

[Edward Warnicke]

+1

On Mon, Mar 2, 2020 at 8:52 AM Ole Troan  wrote:

> +1
>
> Best regards,
> Ole
>
> > On 2 Mar 2020, at 15:15, d...@barachs.net wrote:
> >
> > 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 (#15654): https://lists.fd.io/g/vpp-dev/message/15654
Mute This Topic: https://lists.fd.io/mt/71675525/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 committers: formal vote to add Matt Smith as a vpp committer

[Ole Troan]

+1

Best regards,
Ole

> On 2 Mar 2020, at 15:15, d...@barachs.net wrote:
> 
> 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 (#15653): https://lists.fd.io/g/vpp-dev/message/15653
Mute This Topic: https://lists.fd.io/mt/71675525/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 committers: formal vote to add Matt Smith as a vpp committer

[Andrew Yourtchenko]

+1

--a

> On 2 Mar 2020, at 15:20, d...@barachs.net wrote:
> 
> 
> 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 (#15652): https://lists.fd.io/g/vpp-dev/message/15652
Mute This Topic: https://lists.fd.io/mt/71675525/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 committers: formal vote to add Matt Smith as a vpp committer

[Neale Ranns via Lists.Fd.Io]

+1

/neale

From:  on behalf of "d...@barachs.net" 
Date: Monday 2 March 2020 at 15:20
To: "vpp-dev@lists.fd.io" 
Subject: [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 (#15651): https://lists.fd.io/g/vpp-dev/message/15651
Mute This Topic: https://lists.fd.io/mt/71675525/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 project committers: formal vote to add Matt Smith as a vpp committer

[dave]

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

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

[Noreply Jenkins]

Coverity run failed today.

Current number of outstanding issues are 4
Newly detected: 0
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 (#15649): https://lists.fd.io/g/vpp-dev/message/15649
Mute This Topic: https://lists.fd.io/mt/71675021/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] Facing issue while bringing up vpp 19.08 with Bonding configuration and Mellanox nics

[chetan bhasin]

Thanks Benoit for the response!

I am trying vpp1908 with DPDK 19.02 now and lets see how it behaves.

Thanks,
Chetan

On Mon, Mar 2, 2020 at 2:13 PM Benoit Ganne (bganne) 
wrote:

> The backtrace ends up in the Mellanox DPDK driver, so the bug is most
> probably in DPDK.
> The fact that (2) works but not (1) might hint towards a race condition /
> timing issue.
>
> ben
>
> > -Original Message-
> > From: vpp-dev@lists.fd.io  On Behalf Of chetan
> bhasin
> > Sent: lundi 2 mars 2020 07:53
> > To: vpp-dev 
> > Subject: [vpp-dev] Facing issue while bringing up vpp 19.08 with Bonding
> > configuration and Mellanox nics
> >
> > Hello Everyone,
> >
> > We are trying to bring-up stable/vpp1908 with bonded configuration
> > 1) its getting crash in case we mention
> > "startup-config /root/vanilla_1908/vpp/vpp.conf" ,
> > 2)if we bring up vpp first and then apply configuration using exec
> command
> > , it works fine
> > "exec /root/vanilla_1908/vpp/vpp.conf"
> >
> > Note -  point (1) mentioned above is working fine with stable/vpp2001.
> > There is dpdk version difference as well between stable/vpp1908(dpdk
> > 19.05) vs stable/vpp2001 (dpdk 19.08)
> >
> > Can anybody please suggest an area in vpp we can look into or there could
> > be bug in dpdk 19.05 resolved in dpdk19.08.
> >
> > Configuration :(vpp.conf)
> > create bond mode active-backup
> > bond add BondEthernet0 TwentyFiveGigabitEthernet5d/0/0
> > bond add BondEthernet0 TwentyFiveGigabitEthernet5d/0/1
> > set interface state BondEthernet0 up
> > create sub-interfaces BondEthernet0 811
> > set interface tag BondEthernet0.811 vbond10.811
> > set interface state BondEthernet0.811 up
> > set interface ip address BondEthernet0.811 192.168.10.11/24
> > 
> > create sub-interfaces BondEthernet0 812
> > set interface tag BondEthernet0.812 vbond10.812
> > set interface state BondEthernet0.812 up
> > set interface ip address BondEthernet0.812 192.168.20.11/24
> > 
> > ip route add   16.0.0.0/8   via 192.168.10.1
> > ip route add   48.0.0.0/8   via 192.168.20.1
> > set interface state TwentyFiveGigabitEthernet5d/0/0 up
> > set interface state TwentyFiveGigabitEthernet5d/0/1 up
> >
> >
> > VPP CLI's
> > vpp# show hardware-interfaces
> >
> > BondEthernet0  3 up   BondEthernet0
> >   Link speed: unknown
> >   Ethernet address b8:83:03:8b:ef:44
> > TwentyFiveGigabitEthernet5d/0/01 up
> > TwentyFiveGigabitEthernet5d/0/0
> >   Link speed: 25 Gbps
> >   Ethernet address b8:83:03:8b:ef:44
> >   Mellanox ConnectX-4 Family
> > carrier up full duplex mtu 9206
> > flags: admin-up pmd rx-ip4-cksum
> > rx: queues 4 (max 65535), desc 1024 (min 0 max 65535 align 1)
> > tx: queues 4 (max 65535), desc 4096 (min 0 max 65535 align 1)
> > TwentyFiveGigabitEthernet5d/0/12 up
> > TwentyFiveGigabitEthernet5d/0/1
> >   Link speed: 25 Gbps
> >   Ethernet address b8:83:03:8b:ef:44
> >   Mellanox ConnectX-4 Family
> > carrier up full duplex mtu 9206
> > flags: admin-up pmd rx-ip4-cksum
> > rx: queues 4 (max 65535), desc 1024 (min 0 max 65535 align 1)
> > tx: queues 4 (max 65535), desc 4096 (min 0 max 65535 align 1)
> > pci: device 15b3:1015 subsystem 1590:00d3 address :5d:00.01 numa
> 0
> > max rx packet len: 65536
> >
> >
> >
> > Back-trace looks like as below
> > #0  mlx5_read_dev_counters (dev=dev@entry=0x7f71ebf50940
> > , stats=stats@entry=0x1fffc3518)
> > at /nfs-bfs/workspace/gkeown/integra/mainline/ngp/mainline/third-
> > party/vpp/vanilla_1908/build-root/build-vpp-native/external/dpdk-
> > 19.05/drivers/net/mlx5/mlx5_stats.c:186
> > #1  0x7f71eae756b4 in mlx5_stats_init (dev=dev@entry=0x7f71ebf50940
> > )
> > at /nfs-bfs/workspace/gkeown/integra/mainline/ngp/mainline/third-
> > party/vpp/vanilla_1908/build-root/build-vpp-native/external/dpdk-
> > 19.05/drivers/net/mlx5/mlx5_stats.c:309
> > #2  0x7f71eae70b27 in mlx5_dev_start (dev=0x7f71ebf50940
> > )
> > at /nfs-bfs/workspace/gkeown/integra/mainline/ngp/mainline/third-
> > party/vpp/vanilla_1908/build-root/build-vpp-native/external/dpdk-
> > 19.05/drivers/net/mlx5/mlx5_trigger.c:178
> > #3  0x7f71eabc8e18 in rte_eth_dev_start (port_id=0)
> > at /nfs-bfs/workspace/gkeown/integra/mainline/ngp/mainline/third-
> > party/vpp/vanilla_1908/build-root/build-vpp-native/external/dpdk-
> > 19.05/lib/librte_ethdev/rte_ethdev.c:1429
> > #4  0x7f71eb74fffd in dpdk_device_start (xd=xd@entry=0x7f71ef09fb80)
> > at /nfs-bfs/workspace/gkeown/integra/mainline/ngp/mainline/third-
> > party/vpp/vanilla_1908/src/plugins/dpdk/device/common.c:168
> > #5  0x7f71eb7555c8 in dpdk_interface_admin_up_down (vnm= > out>, hw_if_index=, flags=)
> > at /nfs-bfs/workspace/gkeown/integra/mainline/ngp/mainline/third-
> > party/vpp/vanilla_1908/src/plugins/dpdk/device/device.c:427
> > #6  0x7f72f196d9c8 in vnet_sw_interface_set_flags_helper
> > 

Re: [vpp-dev] VPP does not start: Comm: vpp Not tainted 4.15.0-88-generic

[Dave Barach via Lists.Fd.Io]

Known kernel bug. See https://bugzilla.kernel.org/show_bug.cgi?id=206133. 
Workaround: stick with 4.15.0-76-generic until the kernel fix propagates.

D.

From: vpp-dev@lists.fd.io  On Behalf Of Pac Ette
Sent: Sunday, March 1, 2020 10:07 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP does not start: Comm: vpp Not tainted 4.15.0-88-generic

Hi,

I am running VPP 20.02 compiled on machine with 4.15.0-88-generic.
VPP does not start and when I reboot the machine, reboot just hangs trying to 
kill VPP process.

It works fine on 4.15.0-76-generic.

Here is the info for error:

4.15.0-88-generic
Distributor ID: Ubuntu
Description: Ubuntu 18.04.3 LTS
Release: 18.04
Codename: bionic

[   21.504715] general protection fault:  [#1] SMP NOPTI
[   21.510161] Modules linked in: overlay arc4 uio_pci_generic uio intel_rapl 
pnd2_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm 
ath10k_pci ath10k_core irqbypass intel_cstate ath intel_rapl_perf mac80211 
cdc_ether qmi_wwan qcserial r8152 cdc_wdm usb_wwan usbserial usbnet mii 
cfg80211 mac_hid shpchp sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core 
iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 
btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq 
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear 
dm_snapshot dm_bufio crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc 
aesni_intel aes_x86_64 ixgbe crypto_simd glue_helper igb cryptd ahci 
i2c_algo_bit dca ptp mdio pps_core libahci i2c_ismt
[   21.579798] CPU: 1 PID: 740 Comm: vpp Not tainted 4.15.0-88-generic 
#88-Ubuntu
[   21.594649] RIP: 0010:remove_files.isra.1+0x24/0x70
[   21.599566] RSP: 0018:b6da00dabc00 EFLAGS: 00010282
[   21.604870] RAX: c5e978b250456029 RBX: 9200ee82a000 RCX: 
[   21.612079] RDX: 9200effe1488 RSI: 9200ee82a000 RDI: 9200eee43330
[   21.619307] RBP: b6da00dabc18 R08:  R09: 9200ee806d60
[   21.626535] R10: b6da00dabc18 R11:  R12: 9200eee43330
[   21.633737] R13: 9200effe1488 R14:  R15: 0060
[   21.640949] FS:  7f87f5ec87c0() GS:9200ffd0() 
knlGS:
[   21.649121] CS:  0010 DS:  ES:  CR0: 80050033
[   21.654918] CR2: 55d986512298 CR3: 645d2000 CR4: 003406e0
[   21.662095] Call Trace:
[   21.664587]  sysfs_remove_group+0x44/0x90
[   21.668639]  sysfs_remove_groups+0x2e/0x50
[   21.672742]  device_remove_attrs+0x47/0x80
[   21.676872]  device_del+0x161/0x3b0
[   21.680400]  cdev_device_del+0x1a/0x40
[   21.684180]  posix_clock_unregister+0x26/0x50
[   21.688560]  ptp_clock_unregister+0x72/0x80 [ptp]
[   21.693305]  igb_ptp_stop+0x23/0x50 [igb]
[   21.697360]  igb_remove+0x4b/0x170 [igb]
[   21.701315]  pci_device_remove+0x3e/0xb0
[   21.705266]  device_release_driver_internal+0x13a/0x220
[   21.710552]  device_release_driver+0x12/0x20
[   21.714841]  unbind_store+0x87/0x150
[   21.718439]  drv_attr_store+0x27/0x40
[   21.722131]  sysfs_kf_write+0x3c/0x50
[   21.725857]  kernfs_fop_write+0x125/0x1a0
[   21.729895]  __vfs_write+0x1b/0x40
[   21.75]  vfs_write+0xb1/0x1a0
[   21.736672]  SyS_write+0x5c/0xe0
[   21.739915]  do_syscall_64+0x73/0x130
[   21.743644]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[   21.748772] RIP: 0033:0x7f87f45eb281
[   21.752358] RSP: 002b:7f87b38d19a8 EFLAGS: 3246 ORIG_RAX: 
0001
[   21.759993] RAX: ffda RBX: 7f87b3a31300 RCX: 7f87f45eb281
[   21.767186] RDX: 000c RSI: 7f87b3a31300 RDI: 000c
[   21.774381] RBP: 000c R08: 0010 R09: 
[   21.781609] R10: 000e R11: 3246 R12: 7f87b3a31380
[   21.788783] R13: 7f87b3a31380 R14: 55847edfcda2 R15: 7f87b4551150
[   21.795980] Code: 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 85 f6 48 89 e5 
41 55 41 54 49 89 d5 53 49 89 fc 74 24 48 8b 06 48 89 f3 48 85 c0 74 19 <48> 8b 
30 31 d2 48 83 c3 08 4c 89 e7 e8 bb d4 ff ff 48 8b 03 48
[   21.815037] RIP: remove_files.isra.1+0x24/0x70 RSP: b6da00dabc00
[   21.821489] ---[ end trace 85030bc0a549fa72 ]---


● vpp.service - vector packet processing engine
   Loaded: loaded (/lib/systemd/system/vpp.service; enabled; vendor preset: 
enabled)
  Drop-In: /etc/systemd/system/vpp.service.d
   └─override.conf
   Active: activating (start-post) (Result: signal) since Mon 2020-03-02 
02:48:15 UTC; 1min 15s ago
  Process: 740 ExecStart=/usr/bin/vpp -c /etc/vpp/startup.conf (code=killed, 
signal=SEGV)
  Process: 739 ExecStartPre=/sbin/modprobe uio_pci_generic (code=exited, 
status=0/SUCCESS)
  Process: 728 ExecStartPre=/sbin/modprobe uio_pci_generic (code=exited, 
status=0/SUCCESS)
 Main PID: 740 (code=killed, signal=SEGV); Control PID: 741 (bash)
Tasks: 2 (limit: 4626)

Mar 02 02:48:18 333c55ab vpp[740]: load_one_plugin:189: Loaded plugin: 
tlspicotls_plugin.so 

Re: [vpp-dev] clib_waring is not printing

[Dave Barach via Lists.Fd.Io]

You’ve configured both “unix interactive” and “unix nodaemon” – a bit odd – but 
that probably isn’t the issue.

I’d guess that your container simply isn’t configured to produce syslog output. 
See https://docs.docker.com/config/containers/logging/syslog/

D.

From: vpp-dev@lists.fd.io  On Behalf Of sothy
Sent: Monday, March 2, 2020 7:58 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] clib_waring is not printing

Hello,
I compile and running vpp with plugin. vpp version is 19.08. I'm running within 
a docker container.
The following commands are used for compilation and running.

$make UNATTENDED=yes install-dep

$make pkg-deb V=1


$apt-get install --no-install-recommends -yy liblz4-tool tar \

/src/vpp/build-root/vpp_*.deb \

/src/vpp/build-root/vpp-plugin-core_*.deb \

/src/vpp/build-root/libvppinfra_*.deb \

/src/vpp/build-root/vpp-api-python_*.deb

To run:

/usr/bin/vpp -c ./startup.conf

In my startup.conf,

unix {
  nodaemon
  log /tmp/vpp.log
  full-coredump
  gid vpp
  interactive
  cli-listen localhost:5002
  exec init.conf
}

api-trace {
  on
}

api-segment {
  gid vpp
}



But I didnt see clib_warning message in terminal or syslog (/var/log/syslog).

Any reasons? Thanks



Best regards

Sothy


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

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

[vpp-dev] clib_waring is not printing

[sothy]

Hello,
I compile and running vpp with plugin. vpp version is 19.08. I'm running
within a docker container.
The following commands are used for compilation and running.

$make UNATTENDED=yes install-dep

$make pkg-deb V=1

$apt-get install --no-install-recommends -yy liblz4-tool tar \

/src/vpp/build-root/vpp_*.deb \

/src/vpp/build-root/vpp-plugin-core_*.deb \

/src/vpp/build-root/libvppinfra_*.deb \

/src/vpp/build-root/vpp-api-python_*.deb

To run:

/usr/bin/vpp -c ./startup.conf

In my startup.conf,

unix {
  nodaemon
  log /tmp/vpp.log
  full-coredump
  gid vpp
  interactive
  cli-listen localhost:5002
  exec init.conf
}

api-trace {
  on
}

api-segment {
  gid vpp
}


But I didnt see clib_warning message in terminal or syslog
(/var/log/syslog).

Any reasons? Thanks


Best regards

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

View/Reply Online (#15645): https://lists.fd.io/g/vpp-dev/message/15645
Mute This Topic: https://lists.fd.io/mt/71673585/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] VRF-aware bypass nodes

[Nick Zavaritsky]

Hi John,

Patch submitted.

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


On 27. Feb 2020, at 00:46, John Lo (loj) 
mailto:l...@cisco.com>> wrote:


Hi Nick,

I agree the current bypass node for various tunnel types, including geneve, 
gtpu, vxlan, and vxlan_gbp all have this issue in its hash lookup using only 
incoming packet DIP without checking VRF.  It is generally not an issue if 
bypass feature is enabled on all interfaces which are on the same VRF/IP-table 
corresponding to the same underlay network.  If another underlay VRF is setup 
on other interfaces with bypass enabled, the bypass error as you described will 
happen.

I have no objection if you like to submit a patch to fix this limitation.  I 
hope you are willing to fix bypass node not just for gtpu but all 4 tunnel 
types.  The code for all 4 bypass nodes are very similar except  tunnel type 
check, validation, and node names, etc.

Regards,
John

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Nick Zavaritsky
Sent: Wednesday, February 26, 2020 12:23 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VRF-aware bypass nodes

Hi,

There are multiple kinds of bypass nodes in vpp. Bypass nodes intercept packets 
matching certain criteria and pass them directly to the protocol handler node. 
I am going to use GTPU as the illustrating example.

Bypass node SHOULD intercept packets with destination IP matching a local 
address and UDP destination port equal to 2152.

Bypass node MUST NOT intercept a packet if destination IP doesn’t match a local 
address. Otherwise enabling GTPU bypass would change the observable system 
behaviour.

An address is local within a certain VRF. It’s possible that an address is 
local in one VRF but it’s not in another. But GTPU bypass node is not VRF aware.

Image a vpp setup with 2 interfaces, associated with different VRF-s. The first 
interface address is 10.0.10.100, the other one — 192.168.0.7. Both have GTPU 
bypass enabled. Now GTPU bypass in the second interface will intercept packets 
sent to 10.0.10.100 (the first interface’s address), though it shouldn’t.

This is a somewhat contrived example, but it looks like bypass node should be 
VRF-aware for correctness.

Am I missing something?

Would you be open to a patch making GTPU bypass VRF-aware?

Best,
Nick

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

View/Reply Online (#15644): https://lists.fd.io/g/vpp-dev/message/15644
Mute This Topic: https://lists.fd.io/mt/71569502/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 does not start: Comm: vpp Not tainted 4.15.0-88-generic

[Benoit Ganne (bganne) via Lists.Fd.Io]

Hi,

Yes, Dave ran into the same issue some time ago, it looks like latest Ubuntu 
kernel introduced a regression, probably 
https://bugzilla.kernel.org/show_bug.cgi?id=206133

At this time you might have at least 2 workarounds:
 1) downgrade your kernel back to previous version
 2) blacklist igb module - or maybe just unload it manually before starting VPP

ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Pac Ette
> Sent: lundi 2 mars 2020 04:07
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] VPP does not start: Comm: vpp Not tainted 4.15.0-88-
> generic
> 
> Hi,
> 
> I am running VPP 20.02 compiled on machine with 4.15.0-88-generic.
> VPP does not start and when I reboot the machine, reboot just hangs trying
> to kill VPP process.
> 
> It works fine on 4.15.0-76-generic.
> 
> Here is the info for error:
> 
> 4.15.0-88-generic
> Distributor ID: Ubuntu
> Description: Ubuntu 18.04.3 LTS
> Release: 18.04
> Codename: bionic
> 
> 
> [   21.504715] general protection fault:  [#1] SMP NOPTI
> [   21.510161] Modules linked in: overlay arc4 uio_pci_generic uio
> intel_rapl pnd2_edac x86_pkg_temp_thermal intel_powerclamp coretemp
> kvm_intel kvm ath10k_pci ath10k_core irqbypass intel_cstate ath
> intel_rapl_perf mac80211 cdc_ether qmi_wwan qcserial r8152 cdc_wdm
> usb_wwan usbserial usbnet mii cfg80211 mac_hid shpchp sch_fq_codel ib_iser
> rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi
> scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10
> raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor
> raid6_pq libcrc32c raid1 raid0 multipath linear dm_snapshot dm_bufio
> crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel
> aes_x86_64 ixgbe crypto_simd glue_helper igb cryptd ahci i2c_algo_bit dca
> ptp mdio pps_core libahci i2c_ismt
> [   21.579798] CPU: 1 PID: 740 Comm: vpp Not tainted 4.15.0-88-generic
> #88-Ubuntu
> [   21.594649] RIP: 0010:remove_files.isra.1+0x24/0x70
> [   21.599566] RSP: 0018:b6da00dabc00 EFLAGS: 00010282
> [   21.604870] RAX: c5e978b250456029 RBX: 9200ee82a000 RCX:
> 
> [   21.612079] RDX: 9200effe1488 RSI: 9200ee82a000 RDI:
> 9200eee43330
> [   21.619307] RBP: b6da00dabc18 R08:  R09:
> 9200ee806d60
> [   21.626535] R10: b6da00dabc18 R11:  R12:
> 9200eee43330
> [   21.633737] R13: 9200effe1488 R14:  R15:
> 0060
> [   21.640949] FS:  7f87f5ec87c0() GS:9200ffd0()
> knlGS:
> [   21.649121] CS:  0010 DS:  ES:  CR0: 80050033
> [   21.654918] CR2: 55d986512298 CR3: 645d2000 CR4:
> 003406e0
> [   21.662095] Call Trace:
> [   21.664587]  sysfs_remove_group+0x44/0x90
> [   21.668639]  sysfs_remove_groups+0x2e/0x50
> [   21.672742]  device_remove_attrs+0x47/0x80
> [   21.676872]  device_del+0x161/0x3b0
> [   21.680400]  cdev_device_del+0x1a/0x40
> [   21.684180]  posix_clock_unregister+0x26/0x50
> [   21.688560]  ptp_clock_unregister+0x72/0x80 [ptp]
> [   21.693305]  igb_ptp_stop+0x23/0x50 [igb]
> [   21.697360]  igb_remove+0x4b/0x170 [igb]
> [   21.701315]  pci_device_remove+0x3e/0xb0
> [   21.705266]  device_release_driver_internal+0x13a/0x220
> [   21.710552]  device_release_driver+0x12/0x20
> [   21.714841]  unbind_store+0x87/0x150
> [   21.718439]  drv_attr_store+0x27/0x40
> [   21.722131]  sysfs_kf_write+0x3c/0x50
> [   21.725857]  kernfs_fop_write+0x125/0x1a0
> [   21.729895]  __vfs_write+0x1b/0x40
> [   21.75]  vfs_write+0xb1/0x1a0
> [   21.736672]  SyS_write+0x5c/0xe0
> [   21.739915]  do_syscall_64+0x73/0x130
> [   21.743644]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> [   21.748772] RIP: 0033:0x7f87f45eb281
> [   21.752358] RSP: 002b:7f87b38d19a8 EFLAGS: 3246 ORIG_RAX:
> 0001
> [   21.759993] RAX: ffda RBX: 7f87b3a31300 RCX:
> 7f87f45eb281
> [   21.767186] RDX: 000c RSI: 7f87b3a31300 RDI:
> 000c
> [   21.774381] RBP: 000c R08: 0010 R09:
> 
> [   21.781609] R10: 000e R11: 3246 R12:
> 7f87b3a31380
> [   21.788783] R13: 7f87b3a31380 R14: 55847edfcda2 R15:
> 7f87b4551150
> [   21.795980] Code: 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 85 f6 48 89
> e5 41 55 41 54 49 89 d5 53 49 89 fc 74 24 48 8b 06 48 89 f3 48 85 c0 74 19
> <48> 8b 30 31 d2 48 83 c3 08 4c 89 e7 e8 bb d4 ff ff 48 8b 03 48
> [   21.815037] RIP: remove_files.isra.1+0x24/0x70 RSP: b6da00dabc00
> [   21.821489] ---[ end trace 85030bc0a549fa72 ]---
> 
> 
> 
> ● vpp.service - vector packet processing engine
>Loaded: loaded (/lib/systemd/system/vpp.service; enabled; vendor
> preset: enabled)
>   Drop-In: /etc/systemd/system/vpp.service.d
>└─override.conf
>Active: activating (start-post) (Result: signal) since Mon 2020-03-02
> 02:48:15 UTC; 1min 15s ago
>   Process: 740 

Re: [vpp-dev] Facing issue while bringing up vpp 19.08 with Bonding configuration and Mellanox nics

[Benoit Ganne (bganne) via Lists.Fd.Io]

The backtrace ends up in the Mellanox DPDK driver, so the bug is most probably 
in DPDK.
The fact that (2) works but not (1) might hint towards a race condition / 
timing issue.

ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of chetan bhasin
> Sent: lundi 2 mars 2020 07:53
> To: vpp-dev 
> Subject: [vpp-dev] Facing issue while bringing up vpp 19.08 with Bonding
> configuration and Mellanox nics
> 
> Hello Everyone,
> 
> We are trying to bring-up stable/vpp1908 with bonded configuration
> 1) its getting crash in case we mention
> "startup-config /root/vanilla_1908/vpp/vpp.conf" ,
> 2)if we bring up vpp first and then apply configuration using exec command
> , it works fine
> "exec /root/vanilla_1908/vpp/vpp.conf"
> 
> Note -  point (1) mentioned above is working fine with stable/vpp2001.
> There is dpdk version difference as well between stable/vpp1908(dpdk
> 19.05) vs stable/vpp2001 (dpdk 19.08)
> 
> Can anybody please suggest an area in vpp we can look into or there could
> be bug in dpdk 19.05 resolved in dpdk19.08.
> 
> Configuration :(vpp.conf)
> create bond mode active-backup
> bond add BondEthernet0 TwentyFiveGigabitEthernet5d/0/0
> bond add BondEthernet0 TwentyFiveGigabitEthernet5d/0/1
> set interface state BondEthernet0 up
> create sub-interfaces BondEthernet0 811
> set interface tag BondEthernet0.811 vbond10.811
> set interface state BondEthernet0.811 up
> set interface ip address BondEthernet0.811 192.168.10.11/24
> 
> create sub-interfaces BondEthernet0 812
> set interface tag BondEthernet0.812 vbond10.812
> set interface state BondEthernet0.812 up
> set interface ip address BondEthernet0.812 192.168.20.11/24
> 
> ip route add   16.0.0.0/8   via 192.168.10.1
> ip route add   48.0.0.0/8   via 192.168.20.1
> set interface state TwentyFiveGigabitEthernet5d/0/0 up
> set interface state TwentyFiveGigabitEthernet5d/0/1 up
> 
> 
> VPP CLI's
> vpp# show hardware-interfaces
> 
> BondEthernet0  3 up   BondEthernet0
>   Link speed: unknown
>   Ethernet address b8:83:03:8b:ef:44
> TwentyFiveGigabitEthernet5d/0/01 up
> TwentyFiveGigabitEthernet5d/0/0
>   Link speed: 25 Gbps
>   Ethernet address b8:83:03:8b:ef:44
>   Mellanox ConnectX-4 Family
> carrier up full duplex mtu 9206
> flags: admin-up pmd rx-ip4-cksum
> rx: queues 4 (max 65535), desc 1024 (min 0 max 65535 align 1)
> tx: queues 4 (max 65535), desc 4096 (min 0 max 65535 align 1)
> TwentyFiveGigabitEthernet5d/0/12 up
> TwentyFiveGigabitEthernet5d/0/1
>   Link speed: 25 Gbps
>   Ethernet address b8:83:03:8b:ef:44
>   Mellanox ConnectX-4 Family
> carrier up full duplex mtu 9206
> flags: admin-up pmd rx-ip4-cksum
> rx: queues 4 (max 65535), desc 1024 (min 0 max 65535 align 1)
> tx: queues 4 (max 65535), desc 4096 (min 0 max 65535 align 1)
> pci: device 15b3:1015 subsystem 1590:00d3 address :5d:00.01 numa 0
> max rx packet len: 65536
> 
> 
> 
> Back-trace looks like as below
> #0  mlx5_read_dev_counters (dev=dev@entry=0x7f71ebf50940
> , stats=stats@entry=0x1fffc3518)
> at /nfs-bfs/workspace/gkeown/integra/mainline/ngp/mainline/third-
> party/vpp/vanilla_1908/build-root/build-vpp-native/external/dpdk-
> 19.05/drivers/net/mlx5/mlx5_stats.c:186
> #1  0x7f71eae756b4 in mlx5_stats_init (dev=dev@entry=0x7f71ebf50940
> )
> at /nfs-bfs/workspace/gkeown/integra/mainline/ngp/mainline/third-
> party/vpp/vanilla_1908/build-root/build-vpp-native/external/dpdk-
> 19.05/drivers/net/mlx5/mlx5_stats.c:309
> #2  0x7f71eae70b27 in mlx5_dev_start (dev=0x7f71ebf50940
> )
> at /nfs-bfs/workspace/gkeown/integra/mainline/ngp/mainline/third-
> party/vpp/vanilla_1908/build-root/build-vpp-native/external/dpdk-
> 19.05/drivers/net/mlx5/mlx5_trigger.c:178
> #3  0x7f71eabc8e18 in rte_eth_dev_start (port_id=0)
> at /nfs-bfs/workspace/gkeown/integra/mainline/ngp/mainline/third-
> party/vpp/vanilla_1908/build-root/build-vpp-native/external/dpdk-
> 19.05/lib/librte_ethdev/rte_ethdev.c:1429
> #4  0x7f71eb74fffd in dpdk_device_start (xd=xd@entry=0x7f71ef09fb80)
> at /nfs-bfs/workspace/gkeown/integra/mainline/ngp/mainline/third-
> party/vpp/vanilla_1908/src/plugins/dpdk/device/common.c:168
> #5  0x7f71eb7555c8 in dpdk_interface_admin_up_down (vnm= out>, hw_if_index=, flags=)
> at /nfs-bfs/workspace/gkeown/integra/mainline/ngp/mainline/third-
> party/vpp/vanilla_1908/src/plugins/dpdk/device/device.c:427
> #6  0x7f72f196d9c8 in vnet_sw_interface_set_flags_helper
> (vnm=vnm@entry=0x7f72f2191f20 , sw_if_index=,
> flags=VNET_SW_INTERFACE_FLAG_ADMIN_UP, helper_flags=(unknown: 0),
> helper_flags@entry=VNET_INTERFACE_SET_FLAGS_HELPER_WANT_REDISTRIBUTE)
> at /nfs-bfs/workspace/gkeown/integra/mainline/ngp/mainline/third-
> party/vpp/vanilla_1908/src/vnet/interface.c:455
> #7  0x7f72f196f10d in vnet_sw_interface_set_flags
>