date:20200303

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

2020-03-03 Thread Majumdar, Kausik


Thanks Nathan for pointing out quick work-around. I will give a try.

Thanks,
Kausik

From: Nathan Skrzypczak 
Sent: Tuesday, March 3, 2020 7:11 AM
To: Nathan Skrzypczak 
Cc: Majumdar, Kausik ; vpp-dev 

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

Message received from external source. Exercise caution when opening 
attachments, clicking links, or exchanging information.

[1] should fix this behavior in the future, checking the lib presence and 
version before trying to compile the quicly plugin.
-Nathan

[1] 
https://gerrit.fd.io/r/c/vpp/+/24872

Le mar. 3 mars 2020 à 10:16, Nathan Skrzypczak via 
Lists.Fd.Io
 mailto:gmail@lists.fd.io>> a 
écrit :
Hi Kausik,

This error comes from a discrepancy between the installed version of libquicly 
and the one required for the build.
For now we sadly do not have a version-checking mechanism, I'll try to write a 
patch to avoid those errors and keep you posted.

To fix the build issue you can :
* If `dpkg -l | grep vpp-ext-deps` gives you an entry, maybe try rebuild 
external deps `make install-ext-deps`
* If not, the older version of quicly might come with the e-build, try `make 
wipe-release && git clean -ffdx` and re-run `build.sh`
* If this keeps bothering you and you don't need quicly, you can just remove 
`./src/plugins/quic/CMakeLists.txt` and rebuild

Hope this helps

-Nathan


Le mar. 3 mars 2020 à 05:27, Majumdar, Kausik 
mailto:kausik.majum...@commscope.com>> a écrit :

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 'qu

Re: [vpp-dev] VRF-aware bypass nodes

2020-03-03 Thread John Lo (loj) via Lists.Fd.Io

Hi Nick,

I reviewed your patch and merged it.  Really appreciate your effort to address 
the VRF limitation and also refactor the common VTEP handling code.

Regards,
John

From: Nick Zavaritsky 
Sent: Monday, March 02, 2020 7:35 AM
To: John Lo (loj) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VRF-aware bypass nodes

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 (#15677): https://lists.fd.io/g/vpp-dev/message/15677
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]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Can i increase the size of vlib buffer opaque2

2020-03-03 Thread Satya Murthy

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 (#15676): https://lists.fd.io/g/vpp-dev/message/15676
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]
-=-=-=-=-=-=-=-=-=-=-=-

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

2020-03-03 Thread Nathan Skrzypczak

[1] should fix this behavior in the future, checking the lib presence and
version before trying to compile the quicly plugin.
-Nathan

[1] https://gerrit.fd.io/r/c/vpp/+/24872

Le mar. 3 mars 2020 à 10:16, Nathan Skrzypczak via Lists.Fd.Io
 a écrit :

> Hi Kausik,
>
> This error comes from a discrepancy between the installed version of
> libquicly and the one required for the build.
> For now we sadly do not have a version-checking mechanism, I'll try to
> write a patch to avoid those errors and keep you posted.
>
> To fix the build issue you can :
> * If `dpkg -l | grep vpp-ext-deps` gives you an entry, maybe try rebuild
> external deps `make install-ext-deps`
> * If not, the older version of quicly might come with the e-build, try
> `make wipe-release && git clean -ffdx` and re-run `build.sh`
> * If this keeps bothering you and you don't need quicly, you can just
> remove `./src/plugins/quic/CMakeLists.txt` and rebuild
>
> Hope this helps
>
> -Nathan
>
>
> Le mar. 3 mars 2020 à 05:27, Majumdar, Kausik <
> kausik.majum...@commscope.com> a écrit :
>
>>
>>
>> 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-pack

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

2020-03-03 Thread Neale Ranns via Lists.Fd.Io


Enjoy the ride 😊

From:  on behalf of "Matthew Smith via Lists.Fd.Io" 

Reply to: "mgsm...@netgate.com" 
Date: Monday 2 March 2020 at 22:11
To: "Dave Barach (dbarach)" 
Cc: "vpp-dev@lists.fd.io" 
Subject: 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 (#15674): https://lists.fd.io/g/vpp-dev/message/15674
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] Coverity run FAILED as of 2020-03-03 14:00:24 UTC

2020-03-03 Thread 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 (#15673): https://lists.fd.io/g/vpp-dev/message/15673
Mute This Topic: https://lists.fd.io/mt/71700578/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

2020-03-03 Thread chetan bhasin

Hi,

So we need to backport from stable/vpp/2001  below patch to fix this in
vpp19.08
https://github.com/FDio/vpp/commit/2fd44a00aa26188ca75f0accd734f21758c199bf#diff-3079293198f7807e4e851645851036ab

Vlib: fix cli process stack overflow

Type: fix

Some cli processes, including configuring an test flow
on an i40e interface consume more than the currently
available stack space.

Signed-off-by: Chenmin Sun 
Change-Id: I3df53d251cd43286f94647384d6e50a463bad15c


Chenmin Sun authored and Dave Barach committed on 8 Oct 2019
1 parent dd60b1b

commit
2fd44a00aa26188ca75f0accd734f21758c199bf

Thanks,
Chetan

On Mon, Mar 2, 2020 at 7:24 PM chetan bhasin 
wrote:

> 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/buil

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

2020-03-03 Thread Nathan Skrzypczak

Hi Kausik,

This error comes from a discrepancy between the installed version of
libquicly and the one required for the build.
For now we sadly do not have a version-checking mechanism, I'll try to
write a patch to avoid those errors and keep you posted.

To fix the build issue you can :
* If `dpkg -l | grep vpp-ext-deps` gives you an entry, maybe try rebuild
external deps `make install-ext-deps`
* If not, the older version of quicly might come with the e-build, try
`make wipe-release && git clean -ffdx` and re-run `build.sh`
* If this keeps bothering you and you don't need quicly, you can just
remove `./src/plugins/quic/CMakeLists.txt` and rebuild

Hope this helps

-Nathan


Le mar. 3 mars 2020 à 05:27, Majumdar, Kausik 
a écrit :

>
>
> 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]#
>

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

Re: [vpp-dev] VRF-aware bypass nodes

[vpp-dev] Can i increase the size of vlib buffer opaque2

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

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

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

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

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

8 matches

Site Navigation

Mail list logo

Footer information