[vpp-dev] Crash in tcp46_input_inline, vpp 21.06

[Vijay Kumar]

Hi experts,

I am seeing the below pasted call stack. We are using vpp 21.06. The crash
is in tcp_update_time_now() called inside tcp46_input_inline. I had not
done any changes to *tcp46_input_inline *graph node. All I did was add this
patch mentioned below. This patch was applied recently in the function*
tcp46_listen_inline()* to increment error counters.

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

NOTE
===
The VPP was working fine for a long time even after applying the above
patch but recently we added more features and the crash may be happening as
a side-effect of the new code we added.

Pls let me know if you have seen this crash or if you may have some
suggestions for this crash???


Call stack
=

#0 0x7f59ccfc888c in __pthread_kill_implementation () from
/lib64/libc.so.6
#1 0x7f59ccf7b6a6 in raise () from /lib64/libc.so.6
#2 0x7f59ccf65865 in abort () from /lib64/libc.so.6
#3 0x55bf7f28d30a in os_exit (code=) at
/usr/src/debug/vpp-21.06.0-5~gfad0b64b3_dirty.x86_64/src/vpp/vnet/main.c:477
#4 
#5 0x7f59cdf7bb23 in tcp_update_time_now (wrk=0xa640) at
/usr/src/debug/vpp-21.06.0-5~gfad0b64b3_dirty.x86_64/src/vnet/tcp/tcp_inlines.h:226
#6 tcp46_input_inline (is_nolookup=0 '\000', is_ip4=0, frame=, node=, vm=0x7f58ab281e00)
at
/usr/src/debug/vpp-21.06.0-5~gfad0b64b3_dirty.x86_64/src/vnet/tcp/tcp_input.c:2876
#7 tcp6_input_node_fn_skx (vm=0x7f58ab281e00, node=0x7f584e33c440,
from_frame=0x7f58ab49e900)
at
/usr/src/debug/vpp-21.06.0-5~gfad0b64b3_dirty.x86_64/src/vnet/tcp/tcp_input.c:3051
#8 0x7f59cd30bc05 in dispatch_node (last_time_stamp=,
frame=, dispatch_state=VLIB_NODE_STATE_POLLING,
type=VLIB_NODE_TYPE_INTERNAL, node=0x7f584e33c440, vm=0x7f58ab281e00)
at /usr/src/debug/vpp-21.06.0-5~gfad0b64b3_dirty.x86_64/src/vlib/main.c:1063
#9 dispatch_pending_node (vm=vm@entry=0x7f58ab281e00,
pending_frame_index=pending_frame_index@entry=6, last_time_stamp=)
at /usr/src/debug/vpp-21.06.0-5~gfad0b64b3_dirty.x86_64/src/vlib/main.c:1243
#10 0x7f59cd30d9b7 in vlib_main_or_worker_loop (is_main=0,
vm=0x7f58ab281e00)
at /usr/src/debug/vpp-21.06.0-5~gfad0b64b3_dirty.x86_64/src/vlib/main.c:1832
#11 vlib_worker_loop (vm=0x7f58ab281e00) at
/usr/src/debug/vpp-21.06.0-5~gfad0b64b3_dirty.x86_64/src/vlib/main.c:1966
#12 0x7f59cd28261c in clib_calljmp () at
/usr/src/debug/vpp-21.06.0-5~gfad0b64b3_dirty.x86_64/src/vppinfra/longjmp.S:123
#13 0x7f54837fdc80 in ?? ()
#14 0x7f584847b1e9 in eal_thread_loop.cold () from
/usr/lib/vpp_plugins/dpdk_plugin.so
#15 0x in ?? ()




Regards,
Vijay Kumar N

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

[vpp-dev] Connect QEMU VM to Internet through VPP/DPDK #azure #vhost #dpdk

[feng.wang via lists.fd.io]

Hello,

I'm new to VPP. I have a scenario where I need to run a QEMU VM instance on an 
Azure VM and connect the QEMU VM to the Internet through VPP. The QEMU VM is 
connected to the VPP through vhost-user interface and a NIC from the host Azure 
VM is also attached to the VPP. However, I'm struggling to connect the QEMU VM 
to the Internet. I followed the VM example ( 
https://fd.io/docs/vpp/v2101/usecases/vhost/index.html ) on the fd.io website, 
but couldn't even get the ping working. My guess is Azure VNET requires some 
configurations I missed. I really appreciate if someone who has done before can 
provide some pointers or share the configurations of Azure VNET and VPP.

Thanks!
Feng

vpp# show version
vpp v20.09-release built by azureuser on dpdk-test-2 at 2022-05-03T03:54:51
vpp# show int
Name               Idx    State  MTU (L3/IP4/IP6/MPLS)     Counter          
Count
FailsafeEthernet1                 1      up          9000/0/0/0     rx packets  
                 142
rx bytes                   33168
tx packets                    26
tx bytes                    1552
drops                        126
ip4                           96
ip6                           26
VirtualEthernet0/0/0              2      up          9000/0/0/0     rx packets  
                  24
rx bytes                    1524
tx packets                    20
tx bytes                    5296
drops                          3
local0                            0     down          0/0/0/0

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

Re: [vpp-dev] Query on VPP in Aure

[John Martinez]

Hello Matt,

Thank you again for the response.

So we were able to compile but now are unable to start VPP.

We are seeing the following errors:

I rebuilt, and got:

May 02 20:20:24 demo001 vpp[2161]: vpp[2161]: perfmon: skipping source
'intel-uncore' - intel_uncore_init: no uncore units found

May 02 20:20:24 demo001 vpp[2161]: perfmon: skipping source 'intel-uncore'
- intel_uncore_init: no uncore units found

May 02 20:20:24 demo001 vpp[2161]: vpp[2161]: tls_init_ca_chain:617: Could
not initialize TLS CA certificates

May 02 20:20:24 demo001 vpp[2161]: vpp[2161]: tls_mbedtls_init:652: failed
to initialize TLS CA chain

May 02 20:20:24 demo001 vpp[2161]: tls_init_ca_chain:617: Could not
initialize TLS CA certificates

May 02 20:20:24 demo001 vpp[2161]: tls_mbedtls_init:652: failed to
initialize TLS CA chain

May 02 20:20:24 demo001 vpp[2161]: vpp[2161]: tls_init_ca_chain:1083: Could
not initialize TLS CA certificates

May 02 20:20:24 demo001 vpp[2161]: vpp[2161]: tls_openssl_init:1206: failed
to initialize TLS CA chain

May 02 20:20:24 demo001 vpp[2161]: tls_init_ca_chain:1083: Could not
initialize TLS CA certificates

May 02 20:20:24 demo001 vpp[2161]: tls_openssl_init:1206: failed to
initialize TLS CA chain

May 02 20:20:24 demo001 vpp[2161]: vpp[2161]: vlib_vmbus_bind_to_uio:
Skipping VMBUS device 000d3a8a-a89d-000d-3a8a-a89d000d3a8a as host
interface eth0 is up

May 02 20:20:24 demo001 vpp[2161]: vlib_vmbus_bind_to_uio: Skipping VMBUS
device 000d3a8a-a89d-000d-3a8a-a89d000d3a8a as host interface eth0 is up

May 02 20:20:24 demo001 vnet[2161]: dpdk: Interface Ethernet0/2/0 error
-22: Unknown error -22

May 02 20:20:24 demo001 vnet[2161]: dpdk: Interface Ethernet0/2/0 error
-22: Unknown error -22

May 02 20:20:24 demo001 vnet[2161]: dpdk: [0] setup failed Errors:

rte_eth_tx_queue_setup[port:0,
errno:-22]: Unknown error -22

  rte_eth_rx_queue_setup[port:0,
errno:-22]: Unknown error -22

May 02 20:20:25 demo001 vnet[2161]: received signal SIGSEGV, PC
0x7f4ba079c12c, faulting address 0xdd7

May 02 20:20:25 demo001 vnet[2161]: #0  0x7f4ba12a69d7 0x7f4ba12a69d7

May 02 20:20:25 demo001 vnet[2161]: #1  0x7f4ba0be0c20 0x7f4ba0be0c20

May 02 20:20:25 demo001 vnet[2161]: #2  0x7f4ba079c12c 0x7f4ba079c12c

May 02 20:20:25 demo001 vnet[2161]: #3  0x7f4ba079dbfe va_format + 0xee

May 02 20:20:25 demo001 vnet[2161]: #4  0x7f4ba079fb04 format + 0x84

May 02 20:20:25 demo001 vnet[2161]: #5  0x7f4ba079b88c 0x7f4ba079b88c

May 02 20:20:25 demo001 vnet[2161]: #6  0x7f4ba079dbfe va_format + 0xee

May 02 20:20:25 demo001 vnet[2161]: #7  0x7f4ba124a9f8 vlib_log + 0x2a8

May 02 20:20:25 demo001 vnet[2161]: #8  0x7f4b5b160305 0x7f4b5b160305

May 02 20:20:25 demo001 vnet[2161]: #9  0x7f4b5b170382 0x7f4b5b170382

May 02 20:20:25 demo001 vnet[2161]: #10 0x7f4b5b1750a6 0x7f4b5b1750a6

May 02 20:20:25 demo001 vnet[2161]: #11 0x7f4ba124bac6 0x7f4ba124bac6

May 02 20:20:25 demo001 vnet[2161]: #12 0x7f4ba07b3e10 0x7f4ba07b3e10

May 02 20:20:25 demo001 vpp[2161]: Failed to save post-mortem API trace to
/tmp/api_post_mortem.2161

May 02 20:20:25 demo001 systemd[1]: vpp.service: Main process exited,
code=killed, status=6/ABRT

May 02 20:20:25 demo001 systemd[1]: vpp.service: Failed with result
'signal'.

-- Subject: Unit failed





This time, vpp doesn’t even start up due to the above errors.



*Is there a specific kernel version you used?*

--
John M.


On Mon, May 2, 2022 at 1:42 PM Matthew Smith  wrote:

>
> Sorry, there was a typo. You should use DPDK_MLX5_COMMON_PMD=y instead
> of DPDK_MLX_COMMON_PMD=y.
>
> -Matt
>
>
> On Mon, May 2, 2022 at 11:28 AM Johnny Martinez 
> wrote:
>
>> Hello Matt!
>>
>> *Thank you very much for the reply!*
>>
>> Our end goal is to be using Alma Linux but we went ahead and tried it in
>> a fresh Ubuntu 20.04 installation with the same result.
>>
>> It looks like it is unable to compile the *mlx5 drivers*.
>>
>> *I’ve attached the complete build log for your review.*
>>
>>
>>
>> *Build was started with:*
>>
>> *make DPDK_MLX4_PMD=y DPDK_MLX5_PMD=y DPDK_MLX_COMMON_PMD=y pkg-deb | tee
>> /root/vpp-build.log*
>>
>>
>>
>> As an extra precaution, the vpp.mk content is:
>>
>>
>>
>> *MACHINE=$(shell uname -m)*
>>
>> *vpp_arch = native*
>>
>> *vpp_root_packages = vpp*
>>
>> *vpp_debug_TAG_BUILD_TYPE = debug*
>>
>> *vpp_TAG_BUILD_TYPE = release*
>>
>> *vpp_clang_TAG_BUILD_TYPE = release*
>>
>> *vpp_gcov_TAG_BUILD_TYPE = gcov*
>>
>> *vpp_coverity_TAG_BUILD_TYPE = coverity*
>>
>> *vpp_dpdk_inc_dir = /usr/include/dpdk/*
>>
>> *vpp_dpdk_lib_dir = /usr/lib64/*
>>
>> *vpp_uses_dpdk_mlx4_pmd = yes*
>>
>> *DPDK_MLX4_PMD=y*
>>
>> *DPDK_MLX5_PMD=y*
>>
>> *DPDK_MLX_COMMON_PMD=y*
>>
>>
>>
>> The build completes, but there’s an issue with the MLX5 driver. As seen
>> in the build log, the *MLX4 is built, but MLX5 is not*. I’ve tried
>> searching online, but there’s reference to *glue* with regard 

Re: [vpp-dev] Replacing pycodestyle with black

[Dave Wallace]

I'll work on expanding Klement's patch to include all python files in 
the repo.


I'm thinking it makes more sense to have a single target 'make 
checkstyle-python' (and corresponding 'fixstyle-python') that runs black 
against all of the '*.py' files in the repo and deprecate the 
'test-checkstyle' target.  Any objections?


Thanks,
-daw-

On 5/2/22 4:08 PM, Ole Troan wrote:

I’d be happy to have formatting consistency across the project.

Cheers
Ole


On 2 May 2022, at 19:17, Klement Sekera  wrote:

 +Real Ole.

On 2 May 2022, at 19:15, Klement Sekera via lists.fd.io 
  wrote:


Hi Dave,

good catch about requirements.txt. Should be fixed now.

I’m not sure how to proceed with rest of code, seems to be mostly 
Ole’s domain. Thoughts, Ole?


Thanks,
Klement


On 2 May 2022, at 18:50, Dave Wallace  wrote:

Hi Klement,

I agree that black is a much better PEP8 compliance/formatter for 
python code.  I've been using it on my personal python projects for 
a while now.


I left a minor comment on your gerrit change wrt. installation of 
pinned version as part of the rest of the python virtualenv. 
Otherwise it looks good to me.


What about the rest of the python code in the repo?

Thanks,
-daw-

On 5/2/22 6:56 AM, Klement Sekera wrote:

Hey vpp-dev,

looking at our current code style and its PEP8 compliance I see a 
couple of issues


1.) it’s not really PEP8 compliant
2.) we have no test-fixstyle

I decided to make it more PEP8 compliant and found out that to 
just fix W503 to W504 (per 
https://peps.python.org/pep-0008/#should-a-line-break-before-or-after-a-binary-operator), 
we would need to do a lot of manual code style changes. Looking at 
a tool to do that I stumbled upon black 
(https://github.com/psf/black) which aims to be a consistentcode 
style fixer/validator producing minimum diffs. It’s already used 
by many small and large projects and similarly small and large 
organisations. It’s also much faster to validate/format than 
pycodestyle/autopep8 - its runtime on all our files is in seconds.


My proposal is to bite the bullet and accept a change in style in 
exchange for a consistent, auto-formatted, (almost entirely) pep8 
compliant style.


Here’s the diff:

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

Thoughts?

Thanks,
Klement












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

Re: [vpp-dev] Replacing pycodestyle with black

[Ole Troan]

I’d be happy to have formatting consistency across the project. 

Cheers 
Ole

> On 2 May 2022, at 19:17, Klement Sekera  wrote:
> 
>  +Real Ole.
> 
>>> On 2 May 2022, at 19:15, Klement Sekera via lists.fd.io 
>>>  wrote:
>>> 
>>> Hi Dave,
>>> 
>>> good catch about requirements.txt. Should be fixed now.
>>> 
>>> I’m not sure how to proceed with rest of code, seems to be mostly Ole’s 
>>> domain. Thoughts, Ole?
>>> 
>>> Thanks,
>>> Klement
>>> 
>>> On 2 May 2022, at 18:50, Dave Wallace  wrote:
>>> 
>>> Hi Klement,
>>> 
>>> I agree that black is a much better PEP8 compliance/formatter for python 
>>> code.  I've been using it on my personal python projects for a while now.
>>> 
>>> I left a minor comment on your gerrit change wrt. installation of pinned 
>>> version as part of the rest of the python virtualenv.  Otherwise it looks 
>>> good to me.
>>> 
>>> What about the rest of the python code in the repo?
>>> 
>>> Thanks,
>>> -daw-
>>> 
 On 5/2/22 6:56 AM, Klement Sekera wrote:
 Hey vpp-dev,
 
 looking at our current code style and its PEP8 compliance I see a couple 
 of issues
 
 1.) it’s not really PEP8 compliant
 2.) we have no test-fixstyle
 
 I decided to make it more PEP8 compliant and found out that to just fix 
 W503 to W504 (per 
 https://peps.python.org/pep-0008/#should-a-line-break-before-or-after-a-binary-operator),
  we would need to do a lot of manual code style changes. Looking at a tool 
 to do that I stumbled upon black (https://github.com/psf/black) which aims 
 to be a consistent  code style fixer/validator producing minimum diffs. 
 It’s already used by many small and large projects and similarly small and 
 large organisations. It’s also much faster to validate/format than 
 pycodestyle/autopep8 - its runtime on all our files is in seconds.
 
 My proposal is to bite the bullet and accept a change in style in exchange 
 for a consistent, auto-formatted, (almost entirely) pep8 compliant style.
 
 Here’s the diff:
 
 https://gerrit.fd.io/r/c/vpp/+/36043
 
 Thoughts?
 
 Thanks,
 Klement
 
 
>>> 
>> 
>> 
> 
> 
> 
> 

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

Re: [vpp-dev] Replacing pycodestyle with black

[Pim van Pelt]

Hoi,

As a (small) voice of support, Black is a great formatter. Happy to support
it in vpp's Python codebase! It's also the vppcfg formatter of choice :)

groet,
Pim

On Mon, May 2, 2022 at 3:56 AM Klement Sekera  wrote:

> Hey vpp-dev,
>
> looking at our current code style and its PEP8 compliance I see a couple
> of issues
>
> 1.) it’s not really PEP8 compliant
> 2.) we have no test-fixstyle
>
> I decided to make it more PEP8 compliant and found out that to just fix
> W503 to W504 (per
> https://peps.python.org/pep-0008/#should-a-line-break-before-or-after-a-binary-operator),
> we would need to do a lot of manual code style changes. Looking at a tool
> to do that I stumbled upon black (https://github.com/psf/black) which
> aims to be a consistent code style fixer/validator producing minimum diffs.
> It’s already used by many small and large projects and similarly small and
> large organisations. It’s also much faster to validate/format than
> pycodestyle/autopep8 - its runtime on all our files is in seconds.
>
> My proposal is to bite the bullet and accept a change in style in exchange
> for a consistent, auto-formatted, (almost entirely) pep8 compliant style.
>
> Here’s the diff:
>
> https://gerrit.fd.io/r/c/vpp/+/36043
>
> Thoughts?
>
> Thanks,
> Klement
>
> 
>
>

-- 
Pim van Pelt 
PBVP1-RIPE - http://www.ipng.nl/

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21327): https://lists.fd.io/g/vpp-dev/message/21327
Mute This Topic: https://lists.fd.io/mt/90832348/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] Query on VPP in Aure

[Matthew Smith via lists.fd.io]

Sorry, there was a typo. You should use DPDK_MLX5_COMMON_PMD=y instead
of DPDK_MLX_COMMON_PMD=y.

-Matt


On Mon, May 2, 2022 at 11:28 AM Johnny Martinez 
wrote:

> Hello Matt!
>
> *Thank you very much for the reply!*
>
> Our end goal is to be using Alma Linux but we went ahead and tried it in a
> fresh Ubuntu 20.04 installation with the same result.
>
> It looks like it is unable to compile the *mlx5 drivers*.
>
> *I’ve attached the complete build log for your review.*
>
>
>
> *Build was started with:*
>
> *make DPDK_MLX4_PMD=y DPDK_MLX5_PMD=y DPDK_MLX_COMMON_PMD=y pkg-deb | tee
> /root/vpp-build.log*
>
>
>
> As an extra precaution, the vpp.mk content is:
>
>
>
> *MACHINE=$(shell uname -m)*
>
> *vpp_arch = native*
>
> *vpp_root_packages = vpp*
>
> *vpp_debug_TAG_BUILD_TYPE = debug*
>
> *vpp_TAG_BUILD_TYPE = release*
>
> *vpp_clang_TAG_BUILD_TYPE = release*
>
> *vpp_gcov_TAG_BUILD_TYPE = gcov*
>
> *vpp_coverity_TAG_BUILD_TYPE = coverity*
>
> *vpp_dpdk_inc_dir = /usr/include/dpdk/*
>
> *vpp_dpdk_lib_dir = /usr/lib64/*
>
> *vpp_uses_dpdk_mlx4_pmd = yes*
>
> *DPDK_MLX4_PMD=y*
>
> *DPDK_MLX5_PMD=y*
>
> *DPDK_MLX_COMMON_PMD=y*
>
>
>
> The build completes, but there’s an issue with the MLX5 driver. As seen in
> the build log, the *MLX4 is built, but MLX5 is not*. I’ve tried searching
> online, but there’s reference to *glue* with regard to the MLX5, but
> nothing actionable I could find:
>
>
>
> *Part 1: Shows that the library “mlx4” and “mlx5” are included as part of
> “make” (means our build options were correctly interperated):*
>
>
>
> *cmake3 --build
> /root/azure/vpp/build-root/rpmbuild/vpp-22.06/build-root/build-vpp-native/external/build-rdma-core
> -- libccan.a libibverbs.a librdma_util.a libmlx5.a libmlx4.a >
> /root/azure/vpp/build-root/rpmbuild/vpp-22.06/build-root/build-vpp-native/external/rdma-core.build.log*
>
> *sed 's/^Libs.private:.*/Libs.private: -lmlx4 -lmlx5 -libverbs -lrdma_util
> -lccan -lpthread/' -i
> /root/azure/vpp/build-root/rpmbuild/vpp-22.06/build-root/build-vpp-native/external/build-rdma-core/lib/pkgconfig/libibverbs.pc
> >>
> /root/azure/vpp/build-root/rpmbuild/vpp-22.06/build-root/build-vpp-native/external/rdma-core.build.log*
>
>
> *Part 2: Shows that MLX5 is missing “common_mlx5” (which I can’t find a
> way to install…?) so is disabled. MLX4 however, is built:*
>
>
>
> *Using 'PKG_CONFIG_PATH' from environment with value:
> '/root/azure/vpp/build-root/rpmbuild/vpp-22.06/build-root/install-vpp-native/external/lib/pkgconfig'*
>
> *Run-time dependency libmlx4 found: YES 1.0.39.1*
>
> *Using 'PKG_CONFIG_PATH' from environment with value:
> '/root/azure/vpp/build-root/rpmbuild/vpp-22.06/build-root/install-vpp-native/external/lib/pkgconfig'*
>
> *Run-time dependency libibverbs found: YES 1.14.39.1*
>
> *Compiler for C supports arguments -std=c11: YES*
>
> *Compiler for C supports arguments -Wno-strict-prototypes
> -Wstrict-prototypes: YES*
>
> *Compiler for C supports arguments -D_BSD_SOURCE: YES*
>
> *Compiler for C supports arguments -D_DEFAULT_SOURCE: YES*
>
> *Compiler for C supports arguments -D_XOPEN_SOURCE=600: YES*
>
> *Header  has symbol
> "MLX4DV_SET_CTX_ATTR_BUF_ALLOCATORS" with dependencies libmlx4, libibverbs:
> YES*
>
> *Header  has symbol "MLX4DV_QP_MASK_UAR_MMAP_OFFSET"
> with dependencies libmlx4, libibverbs: YES*
>
> *Checking whether type "struct mlx4_wqe_lso_seg" has member "mss_hdr_size"
> with dependencies libmlx4, libibverbs: YES*
>
> *Configuring mlx4_autoconf.h using configuration*
>
> *Compiler for C supports arguments -std=c11: YES*
>
> *Compiler for C supports arguments -Wno-strict-prototypes
> -Wstrict-prototypes: YES*
>
> *Compiler for C supports arguments -D_BSD_SOURCE: YES*
>
> *Compiler for C supports arguments -D_DEFAULT_SOURCE: YES*
>
> *Compiler for C supports arguments -D_XOPEN_SOURCE=600: YES*
>
> *Message: Disabling mlx5 [drivers/net/mlx5]: missing internal dependency
> "common_mlx5"*
>
> *Run-time dependency libmusdk found: NO (tried pkgconfig)*
>
> *Run-time dependency libmusdk found: NO (tried pkgconfig)*
>
> *Run-time dependency netcope-common found: NO (tried pkgconfig)*
>
>
>
> *Part 3: Shows multiple missing “internal dependency” issues:*
>
>
>
> *Message: Disabling dpaa [drivers/dma/dpaa]: missing internal dependency
> "bus_dpaa"*
>
> *Message: Disabling dpaa [drivers/net/dpaa]: missing internal dependency
> "mempool_dpaa"*
>
> *Message: Disabling kni [drivers/net/kni]: missing internal dependency
> "kni"*
>
> *Message: Disabling mlx5 [drivers/net/mlx5]: missing internal dependency
> "common_mlx5"*
>
> *Message: Disabling caam_jr [drivers/crypto/caam_jr]: missing internal
> dependency "bus_dpaa"*
>
> *Message: Disabling mlx5 [drivers/crypto/mlx5]: missing internal
> dependency "common_mlx5"*
>
> *Message: Disabling mlx5 [drivers/compress/mlx5]: missing internal
> dependency "common_mlx5"*
>
> *Message: Disabling mlx5 [drivers/regex/mlx5]: missing internal dependency
> "common_mlx5"*
>
> *Message: Disabling mlx5 [drivers/vdpa/mlx5]: 

[vpp-dev] Help requested with VPP not working with 25G intel adapter #vpp-dev

[jnhegde]

Hello,

Trying to get an Intel adapter to work with VPP and cannot figure out the 
error. Any help is welcome and appreciated!

Adapter:  Intel(R) Ethernet Network Adapter E810-XXVDA2, driver: ice (version: 
5.13.0-40-generic)
VPP: v22.02
Linux: kernel 5.13.0-40-generic, Ubuntu focal 20.04.3 LTS

When I use the adapter outside of VPP, it works just fine. But when interface 
is specified in /etc/vpp/startup.conf and started with vppctl, I see this in 
vpp (error on last line):
Is the error -1 as in EIO?

vpp# show hardware-interfaces TwentyFiveGigabitEthernet37/0/0

Name                Idx   Link  Hardware

TwentyFiveGigabitEthernet37/0/0    1     up   TwentyFiveGigabitEthernet37/0/0

Link speed: 25 Gbps

RX Queues:

queue thread         mode

0     main (0)       polling

Ethernet address b4:96:91:a5:d0:0a

Intel E810 Family

carrier up full duplex max-frame-size 9018

flags: maybe-multiseg tx-offload intel-phdr-cksum rx-ip4-cksum

Devargs:

rx: queues 1 (max 64), desc 1024 (min 64 max 4096 align 32)

tx: queues 1 (max 64), desc 1024 (min 64 max 4096 align 32)

pci: device 8086:159b subsystem 8086:0003 address :37:00.00 numa 0

max rx packet len: 9728

promiscuous: unicast off all-multicast off

vlan offload: strip off filter off qinq off

rx offload avail:  vlan-strip ipv4-cksum udp-cksum tcp-cksum qinq-strip

outer-ipv4-cksum vlan-filter vlan-extend scatter timestamp

keep-crc rss-hash

rx offload active: ipv4-cksum scatter

tx offload avail:  vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum

tcp-tso outer-ipv4-cksum qinq-insert multi-segs mbuf-fast-free

outer-udp-cksum

tx offload active: ipv4-cksum udp-cksum tcp-cksum multi-segs

rss avail:         ipv4-frag ipv4-tcp ipv4-udp ipv4-sctp ipv4-other ipv4

ipv6-frag ipv6-tcp ipv6-udp ipv6-sctp ipv6-other ipv6

l2-payload

rss active:        none

tx burst mode: Scalar

tx burst function: (not available)

rx burst mode: Scalar

rx burst function: (not available)

rx bytes ok                                      2613819

rx missed                                          18468  Errors:

rte_eth_dev_start[port:0, errno:-5]: Unknown error -5

rte_eth_dev_start[port:0, errno:-5]: Unknown error -5

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

Re: [vpp-dev] Replacing pycodestyle with black

[Klement Sekera]

+Real Ole.

On 2 May 2022, at 19:15, Klement Sekera via lists.fd.io 
mailto:klement=graphiant@lists.fd.io>> 
wrote:

Hi Dave,

good catch about requirements.txt. Should be fixed now.

I’m not sure how to proceed with rest of code, seems to be mostly Ole’s domain. 
Thoughts, Ole?

Thanks,
Klement

On 2 May 2022, at 18:50, Dave Wallace 
mailto:dwallac...@gmail.com>> wrote:

Hi Klement,

I agree that black is a much better PEP8 compliance/formatter for python code.  
I've been using it on my personal python projects for a while now.

I left a minor comment on your gerrit change wrt. installation of pinned 
version as part of the rest of the python virtualenv.  Otherwise it looks good 
to me.

What about the rest of the python code in the repo?

Thanks,
-daw-

On 5/2/22 6:56 AM, Klement Sekera wrote:
Hey vpp-dev,

looking at our current code style and its PEP8 compliance I see a couple of 
issues

1.) it’s not really PEP8 compliant
2.) we have no test-fixstyle

I decided to make it more PEP8 compliant and found out that to just fix W503 to 
W504 (per 
https://peps.python.org/pep-0008/#should-a-line-break-before-or-after-a-binary-operator),
 we would need to do a lot of manual code style changes. Looking at a tool to 
do that I stumbled upon black (https://github.com/psf/black) which aims to be a 
consistent  code style fixer/validator producing minimum diffs. It’s already 
used by many small and large projects and similarly small and large 
organisations. It’s also much faster to validate/format than 
pycodestyle/autopep8 - its runtime on all our files is in seconds.

My proposal is to bite the bullet and accept a change in style in exchange for 
a consistent, auto-formatted, (almost entirely) pep8 compliant style.

Here’s the diff:

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

Thoughts?

Thanks,
Klement







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

Re: [vpp-dev] Replacing pycodestyle with black

[Klement Sekera]

Hi Dave,

good catch about requirements.txt. Should be fixed now.

I’m not sure how to proceed with rest of code, seems to be mostly Ole’s domain. 
Thoughts, Ole?

Thanks,
Klement

On 2 May 2022, at 18:50, Dave Wallace 
mailto:dwallac...@gmail.com>> wrote:

Hi Klement,

I agree that black is a much better PEP8 compliance/formatter for python code.  
I've been using it on my personal python projects for a while now.

I left a minor comment on your gerrit change wrt. installation of pinned 
version as part of the rest of the python virtualenv.  Otherwise it looks good 
to me.

What about the rest of the python code in the repo?

Thanks,
-daw-

On 5/2/22 6:56 AM, Klement Sekera wrote:
Hey vpp-dev,

looking at our current code style and its PEP8 compliance I see a couple of 
issues

1.) it’s not really PEP8 compliant
2.) we have no test-fixstyle

I decided to make it more PEP8 compliant and found out that to just fix W503 to 
W504 (per 
https://peps.python.org/pep-0008/#should-a-line-break-before-or-after-a-binary-operator),
 we would need to do a lot of manual code style changes. Looking at a tool to 
do that I stumbled upon black (https://github.com/psf/black) which aims to be a 
consistent code style fixer/validator producing minimum diffs. It’s already 
used by many small and large projects and similarly small and large 
organisations. It’s also much faster to validate/format than 
pycodestyle/autopep8 - its runtime on all our files is in seconds.

My proposal is to bite the bullet and accept a change in style in exchange for 
a consistent, auto-formatted, (almost entirely) pep8 compliant style.

Here’s the diff:

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

Thoughts?

Thanks,
Klement









-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21323): https://lists.fd.io/g/vpp-dev/message/21323
Mute This Topic: https://lists.fd.io/mt/90832348/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] test performance of nginx using vpp host stack#vpp-hoststack

[Florin Coras]

Hi, 

That indeed looks like an issue due to vpp not being able to recycle 
connections fast enough. There are only 64k connections available between vpp 
and the upstream server, so recycling them as fast as possible, i.e., with 0 
timeout as the kernel does after tcp_max_tw_buckets threshold is hit, might 
make it look like performance is moderately good assuming there are less than 
64k active connections (not closing). 

However, as explained in the previous emails, that might lead to connection 
errors (see my previous links). You could try to emulate that with vpp, by just 
setting timewait-time to 0 but the same disclaimer regarding connection errors 
holds. The only other option is to ensure vpp can allocate more connections to 
the upstream server, i.e., either more source IPs or more destination/server 
IPs.

Regards,
Florin 

> On May 2, 2022, at 8:33 AM, weizhen9...@163.com wrote:
> 
> Hi,
> The short link means that after the client send GET request, the client 
> send tcp FIN packet. Instead, the long link means that after the client send 
> GET request,  the client send next http GET request by using the same link 
> and don't need to send syn packet.
> We found that when vpp and the upstream servers used the short link, the 
> performance is lower than nginx proxy using kernel host stack. The picture 
> shows the performance of nginx proxy using vpp host stack.
> 
> Actually, the performance of nginx proxy using vpp host stack is higher than 
> nginx proxy using kernel host stack. I don't understand why?
> Thanks.
> 
> 
> 


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

Re: [vpp-dev] Replacing pycodestyle with black

[Dave Wallace]

Hi Klement,

I agree that black is a much better PEP8 compliance/formatter for python 
code.  I've been using it on my personal python projects for a while now.


I left a minor comment on your gerrit change wrt. installation of pinned 
version as part of the rest of the python virtualenv. Otherwise it looks 
good to me.


What about the rest of the python code in the repo?

Thanks,
-daw-

On 5/2/22 6:56 AM, Klement Sekera wrote:

Hey vpp-dev,

looking at our current code style and its PEP8 compliance I see a 
couple of issues


1.) it’s not really PEP8 compliant
2.) we have no test-fixstyle

I decided to make it more PEP8 compliant and found out that to just 
fix W503 to W504 (per 
https://peps.python.org/pep-0008/#should-a-line-break-before-or-after-a-binary-operator), 
we would need to do a lot of manual code style changes. Looking at a 
tool to do that I stumbled upon black (https://github.com/psf/black) 
which aims to be a consistent code style fixer/validator producing 
minimum diffs. It’s already used by many small and large projects and 
similarly small and large organisations. It’s also much faster to 
validate/format than pycodestyle/autopep8 - its runtime on all our 
files is in seconds.


My proposal is to bite the bullet and accept a change in style in 
exchange for a consistent, auto-formatted, (almost entirely) pep8 
compliant style.


Here’s the diff:

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

Thoughts?

Thanks,
Klement




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

[vpp-dev] FD.io Nexus SHUTDOWN: 2022-05-16 16:00 UTC

[Vanessa Valderrama]

*What*:

LF will be decommissioning https://nexus.fd.io on 2022-05-16 at 16:00 
UTC. We believe all required artifacts have been migrated to 
PackageCloud (packages) and S3 (logs and docs).


If your project has artifacts in Nexus that need to be migrated please 
migrate required artifacts or open a ticket at 
support.linuxfoundation.org if you need assistance.



*When*:

2022-05-16 16:00 UTC

*Impact*:

https://nexus.fd.io will no longer be accessible


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21319): https://lists.fd.io/g/vpp-dev/message/21319
Mute This Topic: https://lists.fd.io/mt/90839363/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] test performance of nginx using vpp host stack#vpp-hoststack

[weizhen9612]

Hi,
The short link means that after the client send GET request, the client send 
tcp FIN packet. Instead, the long link means that after the client send GET 
request,  the client send next http GET request by using the same link and 
don't need to send syn packet.
We found that when vpp and the upstream servers used the short link, the 
performance is lower than nginx proxy using kernel host stack. The picture 
shows the performance of nginx proxy using vpp host stack.

Actually, the performance of nginx proxy using vpp host stack is higher than 
nginx proxy using kernel host stack. I don't understand why?
Thanks.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21318): https://lists.fd.io/g/vpp-dev/message/21318
Mute This Topic: https://lists.fd.io/mt/90793836/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] test performance of nginx using vpp host stack#vpp-hoststack

[Florin Coras]

Hi, 

As per this [1], after tcp_max_tw_buckets threshold is hit timewait time is 0 
and this [2] explains what will go wrong. Assuming you’re hitting the 
threshold, 1s timewait-time in vpp will probably not be enough to match 
performance. 

Not sure what you mean by “short link”. If you can’t use multiple source IPs or 
destination IPs in the active opens between vpp and the upstream servers, 
there’s not much that could be done beyond what’s mentioned above as vpp can’t 
allocate connections. If your nginx and server it’s proxying for are colocated, 
and the server can use vcl, you could maybe try to use cut-through sessions as 
those do not consume ports in tcp. 

Regards, 
Florin

[1] https://sysctl-explorer.net/net/ipv4/tcp_max_tw_buckets/ 

[2] 
https://stackoverflow.com/questions/45979123/what-is-the-side-effect-of-setting-tcp-max-tw-buckets-to-a-very-small-value
 


> On May 1, 2022, at 2:09 AM, weizhen9...@163.com wrote:
> 
> Hi,
> I set the timewait_time which is equal to 1s in tcp's configuration. But 
> the performance of nginx proxy using vpp host stack is still lower than nginx 
> proxy using kernel host stack. 
> Now I want to know what can I do to improve the performance? And does 
> nginx proxy using vpp host stack support short link?
> In addition, just as you said above, do I need to sets time-wait to 0? 
> And I don't set tcp-src address. I hope the performance of nginx proxy using 
> vpp host stack is higher than the performance of nginx proxy using kernel 
> host stack in the hardware environment.
> Thanks. 
> 
> 
> 
> 


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

[vpp-dev] Replacing pycodestyle with black

[Klement Sekera]

Hey vpp-dev,

looking at our current code style and its PEP8 compliance I see a couple of 
issues

1.) it’s not really PEP8 compliant
2.) we have no test-fixstyle

I decided to make it more PEP8 compliant and found out that to just fix W503 to 
W504 (per 
https://peps.python.org/pep-0008/#should-a-line-break-before-or-after-a-binary-operator),
 we would need to do a lot of manual code style changes. Looking at a tool to 
do that I stumbled upon black (https://github.com/psf/black) which aims to be a 
consistent code style fixer/validator producing minimum diffs. It’s already 
used by many small and large projects and similarly small and large 
organisations. It’s also much faster to validate/format than 
pycodestyle/autopep8 - its runtime on all our files is in seconds.

My proposal is to bite the bullet and accept a change in style in exchange for 
a consistent, auto-formatted, (almost entirely) pep8 compliant style.

Here’s the diff:

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

Thoughts?

Thanks,
Klement

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

[vpp-dev] RCT - alternative router configuration tool

[Petr Boltík]

Hi,

I'd like to share the simple configuration utility for VPP project. It is
an alternative router configuration tool based on JSON configuration files.
It has a limited feature set (ip addres, vxlan, bridge, dot1q,...). Most
changes in configuration are reflected in the VPP process using the GoVPP
API interface as actions requests (eq add address changes etc.). This
package will transform basic devices like Apu from PC engines into a simple
powerful VPP-based router (prepared for the Debian 11).

Thanks to all the people that work on VPP project.

https://github.com/petrbol/RouterConfigurationTool

Regards

Petr B.

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