Re: [vpp-dev] Headers files missing in VPP version 21.10

[Dave Wallace]

Hi Mauro,

I merged your cherry-pick to stable/21.10 [1] and will work with Andrew 
to schedule a maintenance release.


Thanks,
-daw-

On 11/3/21 1:09 PM, Mauro Sardara (msardara) via lists.fd.io wrote:


Hello All,

I am having an issue with the new VPP version 21.10 because of some 
header files missing.


The issue was fixed in master a few days ago [0], but it is still 
present in the tag v21.10, so
I cherry-picked the change and created a patch for the branch 
stable/2110 [1].


Is it possible to release a new version 21.10.1 containing this fix?

Thanks in advance for your support.

Regards,
Mauro.


[0]https://github.com/FDio/vpp/commit/d9fc708ee0c8c42fa09dda5d29e9cb0f985558dc#diff-931430ce72263164a78d72bf46cfb75cf63d5503fd60293a7f4fd9e70aca2383

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





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20440): https://lists.fd.io/g/vpp-dev/message/20440
Mute This Topic: https://lists.fd.io/mt/86796422/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 regarding packet validation checks in ip6_local

[pankajmalhotra83]

Hi Ole,

The problem I am facing is a bit different. It is not that it is failing for me 
in any scenario, but the implementation seems a little confusing and hence I 
posted this query for clarification. I'll try explaining my test scenario.

The documentation for VPP Configuration File - ‘startup.conf’, specifies a 
parameter 'enable-tcp-udp-checksum' under the dpdk parameters with the 
description 'Enables UDP/TCP RX checksum offload', which, from the description 
seems like can be used to enable L4 Rx checksum offload. But what is observed 
is that irrespective of this parameter being enabled/disabled, the hardware 
computes the checksum and sets the corresponding Rx checksum offload bits(this 
gets reflected in the DPDK MBUF ol_flags)( due to 'no-tx-checksum-offload' not 
being specified in the config file, the default Tx/Rx checksum offload config 
is applicable)

The function dpdk_init() sets the default behavior in the 
buffer_flags_template, which by default assumes that L4 checksum is computed 
and is correct.
/* Default vlib_buffer_t flags, DISABLES tcp/udp checksumming... */
dm->buffer_flags_template = (VLIB_BUFFER_TOTAL_LENGTH_VALID |
VLIB_BUFFER_EXT_HDR_VALID |
VNET_BUFFER_F_L4_CHECKSUM_COMPUTED |
VNET_BUFFER_F_L4_CHECKSUM_CORRECT);

In dpdk_lib_init(), if the 'enable-tcp-udp-checksum' is enabled in config file, 
the flag bits are disabled by the following check.
if (dm->conf->enable_tcp_udp_checksum)
dm->buffer_flags_template &= ~(VNET_BUFFER_F_L4_CHECKSUM_CORRECT
| VNET_BUFFER_F_L4_CHECKSUM_COMPUTED);

Now once hardware has set the corresponding DPDK MBUF 
bits(PKT_RX_L4_CKSUM_GOOD/PKT_RX_L4_CKSUM_BAD), and the packet is locally 
destined IPv6 packet(lands in function ip6_local_inline()):

Scenario 1 : parameter 'enable-tcp-udp-checksum' is added to config file, 
meaning 'Enable UDP/TCP RX checksum offload'
Due to the VNET_BUFFER_F_L4_CHECKSUM_COMPUTED/VNET_BUFFER_F_L4_CHECKSUM_CORRECT 
bits getting negated in dpdk_lib_init(), need_csum would be computed 'True' in 
ip6_local_inline and hence, ip6_tcp_udp_icmp_validate_checksum() would get 
called, which would recompute the checksum again in software, a behavior 
different from what 'enable-tcp-udp-checksum' intends(checksum 
computation/validation is offloaded to H/W but still recomputed in S/W).

if (PREDICT_FALSE (need_csum))
{
flags = ip6_tcp_udp_icmp_validate_checksum (vm, b[0]);
good_l4_csum = flags & VNET_BUFFER_F_L4_CHECKSUM_CORRECT;
error = IP6_ERROR_UNKNOWN_PROTOCOL;
}
else
{
if (ip6_tcp_udp_icmp_bad_length (vm, b[0]))
error = IP6_ERROR_BAD_LENGTH;
}

Scenario 2 : parameter 'enable-tcp-udp-checksum' is not present, hence by 
default VNET_BUFFER_F_L4_CHECKSUM_COMPUTED/VNET_BUFFER_F_L4_CHECKSUM_CORRECT 
bits are set for all Rx'ed packets, need_csum gets computed 'False', hence, no 
checksum is computed in software, and the packet lands in else part, meaning 
that even if the packet checksum is incorrect, it would still get further 
processed, which again doesn't seems correct.

With 'enable-tcp-udp-checksum' not present, the IPv6/UDP(no IPv6 extension 
options present) packets land in else part and ip6_tcp_udp_icmp_bad_length() 
further validates this packet, but the implementation mandatorily expects the 
hop-by-hop extension header to be present and hence incorrectly typecasts the 
hop-by-hop extension header to the UDP header immediately following the IPv6 
header(the ip6_hop_by_hop_ext_t next_hdr field overlapping the udp header 
source_port field), and hence returns a 0 due to this check:
if (!(ext_hdr->next_hdr == IP_PROTOCOL_ICMP6)
|| (ext_hdr->next_hdr == IP_PROTOCOL_UDP))
return 0;

The return value 0 here falsely implies that the ip6_tcp_udp_icmp_bad_length() 
has passed its length validation and proceeds further, but in essence, the 
length validation for IPv6/UDP packet didn't happen.

Hi Florin,
I think, you are partly right in you response, in stating - 'As for the length 
check being done only on the else branch, ip6_tcp_udp_icmp_validate_checksum 
needs to compute the length so I’m guessing the expectation is that the 
checksum validation will fail for bogus length packets.', but this shall be 
true for L4 only, i.e. L4 checksum validation and correctness shall implicitly 
also validate the L4 payload length. I think, the L3 length validation shall 
still be required(payload_length in ipv6 header).  The function 
ip6_tcp_udp_icmp_bad_length() also seems to be validating the payload_length in 
the IPv6 header.

Thanks
Pankaj

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20439): https://lists.fd.io/g/vpp-dev/message/20439
Mute This Topic: https://lists.fd.io/mt/86774091/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] Reason for removing SUSE packaging support

[Benoit Ganne (bganne) via lists.fd.io]

Hi Laszlo,

Thanks! A few comments:
 - I think it would be easier to just merge both patches
 - I would put the Dockerfile under extras/rpm instead of a dedicated 
directory, alongside a small README to explain how to use it for testing
 - you should add yourself in MAINTAINERS as the maintainer for rpm packaging. 
A maintainer duty is to review patches on its subsystem (rpm packaging in your 
case) in gerrit and +1 if they are ready for merging so a committer can merge 
them, and to answer/fix issues when reported

Best
ben

> -Original Message-
> From: Laszlo Király 
> Sent: vendredi 5 novembre 2021 15:56
> To: vpp-dev@lists.fd.io
> Cc: Benoit Ganne (bganne) 
> Subject: Re: [vpp-dev] Reason for removing SUSE packaging support
> 
> Hello,
> 
> I pushed the patches for providing support to build vpp on opensuse leap:
> https://gerrit.fd.io/r/c/vpp/+/34356
> 
> https://gerrit.fd.io/r/c/vpp/+/34357
> 
> The rpm build can be tried out by the provided docker manifest file:
>  docker build -f extras/docker/build/Dockerfile.opensuse .
> 
> 
> Could you give me some advice how to continue with this? Can I add someone
> as a reviewer?
> --
> Laszlo
> 
> 
> 
> From: Benoit Ganne (bganne) 
> Sent: Monday, July 26, 2021 10:08 AM
> To: Laszlo Király 
> Cc: vpp-dev@lists.fd.io 
> Subject: RE: [vpp-dev] Reason for removing SUSE packaging support
> 
> If you provide patches and volunteer to be the maintainer that would be
> great. The main request is to be reactive on the code you maintain (answer
> users and/or bug reports).
> You can start by submitting patches and an entry in MAINTAINERS.
> I suspect the best would be to have extras/rpm/centos/ and
> extras/rpm/suse/ but I am no expert.
> 
> Best
> ben
> 
> > -Original Message-
> > From: vpp-dev@lists.fd.io  On Behalf Of Laszlo
> Király
> > Sent: lundi 26 juillet 2021 08:35
> > To: Damjan Marion 
> > Cc: vpp-dev@lists.fd.io
> > Subject: Re: [vpp-dev] Reason for removing SUSE packaging support
> >
> > Thanks for the clarification.
> > Currently we are building the vpp in SUSE environment and probably must
> be
> > maintained in the long term. If I would like to contribute to build
> > support for opensuse-leap which are the expectations? Are there any
> other
> > todos beside the update of documentation and build scripts?
> >
> > --
> > Laszlo Kiraly
> > Ericsson Software Technology
> > laszlo.kir...@est.tech
> >
> > 
> >
> > From: Damjan Marion 
> > Sent: Monday, July 19, 2021 12:08 PM
> > To: Laszlo Király 
> > Cc: vpp-dev@lists.fd.io 
> > Subject: Re: [vpp-dev] Reason for removing SUSE packaging support
> >
> >
> > Simply because there was nobody interested to volunteer to maintain it.
> >
> > -
> > Damjan
> >
> >
> >
> >
> >On 19.07.2021., at 12:04, Laszlo Király 
> > wrote:
> >
> >
> >
> >
> >Hello,
> >
> >Could somebody evolve why the build support for Suse was removed?
> >Which was the last release with support for build on openSuse?  I
> > found this commit only mentioning this removal:
> >
> >commit bc35f469c89daf0126937580b6972516b5007d3a
> >Author: Dave Wallace 
> >Date:   Fri Sep 18 15:35:01 2020 +
> >
> >build: remove opensuse build infra
> >
> >- VPP on opensuse has not been supported
> >  for several releases.
> >
> >Type: fix
> >
> >Signed-off-by: Dave Wallace 
> >Change-Id: I2b5316ad5c20a843b8936f4ceb473f932a5338d9
> >
> >
> >
> >Is it planned to add it back soon? Or later?
> >
> >--
> >Laszlo Kiraly
> >Ericsson Software Technology
> >
> >laszlo.kir...@est.tech
> >
> >
> >
> >
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20438): https://lists.fd.io/g/vpp-dev/message/20438
Mute This Topic: https://lists.fd.io/mt/84304700/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] Reason for removing SUSE packaging support

[Laszlo Király]

Hello,

I pushed the patches for providing support to build vpp on opensuse leap:
https://gerrit.fd.io/r/c/vpp/+/34356
https://gerrit.fd.io/r/c/vpp/+/34357
The rpm build can be tried out by the provided docker manifest file:
 docker build -f extras/docker/build/Dockerfile.opensuse .

Could you give me some advice how to continue with this? Can I add someone as a 
reviewer?
--
Laszlo


From: Benoit Ganne (bganne) 
Sent: Monday, July 26, 2021 10:08 AM
To: Laszlo Király 
Cc: vpp-dev@lists.fd.io 
Subject: RE: [vpp-dev] Reason for removing SUSE packaging support

If you provide patches and volunteer to be the maintainer that would be great. 
The main request is to be reactive on the code you maintain (answer users 
and/or bug reports).
You can start by submitting patches and an entry in MAINTAINERS.
I suspect the best would be to have extras/rpm/centos/ and extras/rpm/suse/ but 
I am no expert.

Best
ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Laszlo Király
> Sent: lundi 26 juillet 2021 08:35
> To: Damjan Marion 
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] Reason for removing SUSE packaging support
>
> Thanks for the clarification.
> Currently we are building the vpp in SUSE environment and probably must be
> maintained in the long term. If I would like to contribute to build
> support for opensuse-leap which are the expectations? Are there any other
> todos beside the update of documentation and build scripts?
>
> --
> Laszlo Kiraly
> Ericsson Software Technology
> laszlo.kir...@est.tech
>
> 
>
> From: Damjan Marion 
> Sent: Monday, July 19, 2021 12:08 PM
> To: Laszlo Király 
> Cc: vpp-dev@lists.fd.io 
> Subject: Re: [vpp-dev] Reason for removing SUSE packaging support
>
>
> Simply because there was nobody interested to volunteer to maintain it.
>
> —
> Damjan
>
>
>
>
>On 19.07.2021., at 12:04, Laszlo Király 
> wrote:
>
>
>
>
>Hello,
>
>Could somebody evolve why the build support for Suse was removed?
>Which was the last release with support for build on openSuse?  I
> found this commit only mentioning this removal:
>
>commit bc35f469c89daf0126937580b6972516b5007d3a
>Author: Dave Wallace 
>Date:   Fri Sep 18 15:35:01 2020 +
>
>build: remove opensuse build infra
>
>- VPP on opensuse has not been supported
>  for several releases.
>
>Type: fix
>
>Signed-off-by: Dave Wallace 
>Change-Id: I2b5316ad5c20a843b8936f4ceb473f932a5338d9
>
>
>
>Is it planned to add it back soon? Or later?
>
>--
>Laszlo Kiraly
>Ericsson Software Technology
>
>laszlo.kir...@est.tech
>
>
>
>


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

Re: [vpp-dev] how to enable avx512 for all plugins and drivers?

[Damjan Marion via lists.fd.io]

Based on your output looks like you are using quite old version of vpp.
In the recent versions of VPP AVX-512 instructions are used automatically if 
CPU supports them…

— 
Damjan

> On 05.11.2021., at 10:52, haiyan...@ilinkall.cn wrote:
> 
> 
> 
> Dear vpp group:
> 
>I changed dpdk-input node to avx512 as this message said 
> "vpp-dev@lists.fd.io | A question about enable AVX512 instruction in VPP", 
> but others still uses avx2 as below
> 
> so how could i enable it for all the plugins and all the drivers? Thanks for 
> any reply
> 
> 
> 
> 
> 

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

[vpp-dev] how to enable avx512 for all plugins and drivers?

[haiyan...@ilinkall.cn]

Dear vpp group:

   I changed dpdk-input node to avx512 as this message said 
"vpp-dev@lists.fd.io | A question about enable AVX512 instruction in VPP", but 
others still uses avx2 as below
so how could i enable it for all the plugins and all the drivers? Thanks for 
any reply



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20435): https://lists.fd.io/g/vpp-dev/message/20435
Mute This Topic: https://lists.fd.io/mt/86836650/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] Is there a bug in IKEv2 when enable multithread ?

[Guangming]

Thanks ben
With software RSS , the test result is OK.  
This should be ixgbevf RSS issue . 




zhangguangm...@baicells.com
 
From: Benoit Ganne (bganne) via lists.fd.io
Date: 2021-11-05 16:15
To: zhangguangm...@baicells.com
CC: vpp-dev
Subject: Re: [vpp-dev] Is there a bug in IKEv2 when enable multithread ?
Here is my take: currently in the ike plugin we expect all related ike packets 
to arrive on the same NIC queue. I expect all ike packets to use the same UDP 
5-tuple, hence I think this assumption is correct.
If you can share a scenario (in the RFC or even better with an existing ike 
implementation) where it is not correct, we should probably reconsider this.
If it is a RSS issue, you should fix it. You can use 'vppctl set interface 
handoff' for software RSS as a workaround.
 
Best
ben
 
> -Original Message-
> From: zhangguangm...@baicells.com 
> Sent: vendredi 5 novembre 2021 02:55
> To: Benoit Ganne (bganne) 
> Cc: vpp-dev 
> Subject: Re: RE: Is there a bug in IKEv2 when enable multithread ?
> 
>   Yes, the flow with same source/dest ip and ports was assgin to the
> same nic queue is the expected.  But  the  resust is the init and auth
> packet was assign the same queue, but the informatuon reply (infomation
> request was send by vpp) was
> assigned the other queue.
> 
> I also make another test , cpature all the IKEv2 packets and relpay
> the packets those  dest address is vpp,  all the pakcet was assgined to
> the same queue.
> 
> I think there are two cause ,the one is NIC rss is not work  , the other
> is IKEv2 code .  The firt  is most possibility ,  but the first is not
> able to explain the the second test result .
> 
>  I  have reported  the first cause through the Intel $(D"n Premier Support
> site.
> My physical NIC  is 82599.  The VF(SRIOV ) was use by  a VM . The question
> about RSS  support ixgbevf
> 
> root@gmzhang:~/vpn# ethtool -i enp2s13
> driver: ixgbevf
> version: 4.1.0-k
> firmware-version:
> expansion-rom-version:
> bus-info: :02:0d.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: no
> supports-register-dump: yes
> supports-priv-flags: no
> 
> 
> Guangming
> 
> Thanks
> 
> 
> 
> zhangguangm...@baicells.com
> 
> 
> From: Benoit Ganne (bganne) 
> Date: 2021-11-05 01:12
> To: zhangguangm...@baicells.com 
> CC: vpp-dev 
> Subject: RE: Is there a bug in IKEv2 when enable multithread ?
> Hi,
> 
> Why do you receive those packets on different workers? I would
> expect all the IKE packets to use the same source/dest IP and ports hence
> arriving in the same worker. Is it not the case?
> 
> Best
> ben
> 
> > -Original Message-
> > From: zhangguangm...@baicells.com 
> > Sent: mardi 2 novembre 2021 10:15
> > To: Damjan Marion (damarion) ; Filip Tehlar -X
> > (ftehlar - PANTHEON TECH SRO at Cisco) ; nranns
> > ; Benoit Ganne (bganne) 
> > Subject: Is there a bug in IKEv2 when enable multithread ?
> >
> >
> >
> >
> > 
> >
> > zhangguangm...@baicells.com
> >
> >
> > From: zhangguangm...@baicells.com
> > 
> > Date: 2021-11-02 17:01
> > To: vpp-dev 
> > CC: ftehlar 
> > Subject: Is there a bug in IKEv2 when enable multithread ?
> > Hi，
> >
> >  When I test IKEv2,   i found when enable multithread ,  the
> ike
> > sa will be detelte quickly after IKE negotiation complete.
> > The root casue is the inti and auth packet handle by one worker
> > thread ,but the  informational packet was handled by the other
> thread.
> > RSS is enable.
> >
> >
> > The follow is my configuration
> >
> >
> >
> > cpu {
> > ## In the VPP there is one main thread and optionally the user can
> > create worker(s)
> > ## The main thread and worker thread(s) can be pinned to CPU
> core(s)
> > manually or automatically
> >
> >
> > ## Manual pinning of thread(s) to CPU core(s)
> >
> >
> > ## Set logical CPU core where main thread runs, if main core is
> not
> > set
> > ## VPP will use core 1 if available
> > main-core 1
> >
> >
> > ## Set logical CPU core(s) where worker threads are running
> > # corelist-workers 2-3,18-19
> > corelist-workers 2-3,4-5
> >
> >
> > ## Automatic pinning of thread(s) to CPU core(s)
> >
> >
> > ## Sets number of CPU core(s) to be skipped (1 ... N-1)
> > ## Skipped CPU core(s) are not used for pinning main thread and
> > working thread(s).
> > ## The main thread is automatically pinned to the first available
> > CPU core and worker(s)
> > ## are pinned to next free CPU core(s) after core assigned to main
> > thread
> > # skip-cores 4
> >
> >
> > ## Specify a number of workers to be created
> > ## Workers are pinned to N consecutive CPU cores while skipping
> > "skip-cores" CPU core(s)
> > ## and main thread's CPU core
> > #workers 2
> >
> >
> > ## Set scheduling policy and priority of main and 

Re: [vpp-dev] a free_bitmap may expand while pool_put

[Neale Ranns]

Hi Stanislav,

IMHO the ASSERT is a false negative, even though the load-balance has been put 
in the pool, its memory is still valid and can still be safely retrieved from a 
worker. If the load-balance was re-used before all workers were done with it, 
then we’d have problems, but that doesn’t happen given the speed mismatch of 
the workers and the main thread – to guarantee that case a call to 
vlib_worker_wait_one_loop() in the load-balance code would be sufficient.

If you want to stop the asserts firing in a debug image you can #ifdef 
CLIB_DEBUG conditionally hold the lock on pool_put.

/neale

From: vpp-dev@lists.fd.io  on behalf of Florin Coras via 
lists.fd.io 
Date: Thursday, 4 November 2021 at 22:19
To: Stanislav Zaikin 
Cc: Damjan Marion , vpp-dev 
Subject: Re: [vpp-dev] a free_bitmap may expand while pool_put
Hi Stanislav,

Yes, binary api messages are handled by main thread. If the issue is purely 
binary api related, then yes, checking for pool (vectors or bitmap) realloc 
with single writer should work.

Note that the pool’s free_indices vector can also expand (not only the bitmap), 
so that should be checked as well.

Regards,
Florin


On Nov 4, 2021, at 1:58 PM, Stanislav Zaikin 
mailto:zsta...@gmail.com>> wrote:

Hi Damjan,
Hi Florin,

I may have given the wrong example, even though the IP API's marked as mt-safe 
(VL_API_IP_ROUTE_ADD_DEL/VL_API_IP_ROUTE_ADD_DEL_V2), they'd be called only 
from the main thread, right? So, only one pool_put will be called and it looks 
like the patch actually fixes the problem (I still don't like it).

I liked the idea with a vec of freed elements, but we still need to put a 
worker barrier to perform such an operation. I thought about something more 
lightweight, like CAS for a newly allocated bitmap/vector. But I find myself 
extremely incompetent to write any lock-free solutions.


On Thu, 4 Nov 2021 at 20:01, Florin Coras 
mailto:fcoras.li...@gmail.com>> wrote:
Agreed! Since pools are not thread safe, the whole load balance destroy scheme 
should probably be refactored.

Maybe add, with locks, the indices to be freed to a vector and once enough 
accumulate, or if a new element is needed, grab the worker barrier and actually 
free them all.

Regards,
Florin


On Nov 4, 2021, at 11:50 AM, Damjan Marion via lists.fd.io 
mailto:dmarion=me@lists.fd.io>> wrote:


Dear Stanislav,

It doesn’t look to me as a thread safe solution.

i.e imagine 2 threads call pool_put_will expand  on the same time, and there is 
just one free slot. Both will get negative answer, but 2nd put operation will 
actually expand.

—
Damjan


On 04.11.2021., at 18:24, Stanislav Zaikin 
mailto:zsta...@gmail.com>> wrote:

Hello folks,

In a multi-threaded environment (in my case I have 2 workers) I observed a 
crash, and thanks to Neale, it turned out that free_bitmap may expand while 
doing pool_put.
Let's say one thread is doing pool_put, while another thread is calling 
"pool_elt_at_index". I observed different addresses before and after checking 
"ASSERT (! pool_is_free (p, _e))" in that macro.

I prepared a patch [0], but it's kind of ugly. We don't have asserts in release 
mode, so why should we care about it?

On the other hand, 2 different threads can do 2 pool_puts simultaneously and we 
can lose one free element in the pool (and also additionally allocated bitmap).

For me, it's a place where it would be nice to have an mt-safe vec. What do you 
think?

[0] - https://gerrit.fd.io/r/c/vpp/+/34332

--
Best regards
Stanislav Zaikin







--
Best regards
Stanislav Zaikin


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20433): https://lists.fd.io/g/vpp-dev/message/20433
Mute This Topic: https://lists.fd.io/mt/86821639/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] Is there a bug in IKEv2 when enable multithread ?

[Benoit Ganne (bganne) via lists.fd.io]

Here is my take: currently in the ike plugin we expect all related ike packets 
to arrive on the same NIC queue. I expect all ike packets to use the same UDP 
5-tuple, hence I think this assumption is correct.
If you can share a scenario (in the RFC or even better with an existing ike 
implementation) where it is not correct, we should probably reconsider this.
If it is a RSS issue, you should fix it. You can use 'vppctl set interface 
handoff' for software RSS as a workaround.

Best
ben

> -Original Message-
> From: zhangguangm...@baicells.com 
> Sent: vendredi 5 novembre 2021 02:55
> To: Benoit Ganne (bganne) 
> Cc: vpp-dev 
> Subject: Re: RE: Is there a bug in IKEv2 when enable multithread ?
> 
>   Yes, the flow with same source/dest ip and ports was assgin to the
> same nic queue is the expected.  But  the  resust is the init and auth
> packet was assign the same queue, but the informatuon reply (infomation
> request was send by vpp) was
> assigned the other queue.
> 
> I also make another test , cpature all the IKEv2 packets and relpay
> the packets those  dest address is vpp,  all the pakcet was assgined to
> the same queue.
> 
> I think there are two cause ,the one is NIC rss is not work  , the other
> is IKEv2 code .  The firt  is most possibility ,  but the first is not
> able to explain the the second test result .
> 
>  I  have reported  the first cause through the Intel® 禸鑌髈\xF2 綅琹焱\xF4
\xBE 籅罃\xAE
\xBE 瘭 珡迠髃邐 盁\xC3  髬 塕哆妟  纚\xE5 膐崱篅砢 \xA9 蝥\xF3 檷\xE5 醳  \xE1 膘 \xAE 纚\xE5 偊鑣扰焈
\xBE 遧煓\xF4 篪\xD3  幥琹焱\xF4 髺韑鑭\xE6
\xBE 
\xBE 秂煊摭\x8F逧餳淎屩欗琤\xA3 鑨饞焌\xEC 斊 鑕牣窬\xB3
\xBE 鍞髵鑡\xBA 髺韑鑭\xE6
\xBE 蔌秖髤沉 匬侟丰\xEB
\xBE 隟禴蝥祧昈鑡籅焈\xBA
\xBE 鑯玵渼髤毱秂鼙蔌秖髤沉
\xBE 醮窂髠隯\xBA 乁乁嬈僔伻暱
\xBE 幥琹焱羐旹䍃扰幖髃竧 轘\xF3
\xBE 幥琹焱羐旼鑣絰 轘\xF3
\xBE 幥琹焱羐敺鑜秂鼙遬鉝帮\xBA 渢
\xBE 幥琹焱羐旲鐿髬罃䁘鍧\x8F逅\xBA 轘\xF3
\xBE 幥琹焱羐旔禖茝隦邅竧 渢
\xBE 
\xBE 
\xBE 湋邗韯髠\xE7
\xBE 
\xBE 纚邗鵔
\xBE 
\xBE 
\xBE 
\xBE 鉽邗韝舡淎\x8F迚淎摝邋鉝麯窊鉵\xED
\xBE 
\xBE 
\xBE沟焇\xBA 曏渢髲 淩渞\xE5 嶙韐渞鎋 弴邋黕澐醆邗洴摟髬鉵桕焇\xBE
\xBE榷罃\xBA 傺傽捎侞乜 乄嬗\xB2
\xBE缿\xBA 鉽邗韝舡淎\x8F迚淎摝邋鉝麯窊鉵\xED 弴邋黕澐鉽邗韝舡淎\x8F迚淎摝邋鉝麯窊鉵鼿
\xBE柡\xBA 蕑爹錴\xF6 弴邋黕澐蕑爹錴菹麨幖窊隉桼澥
\xBE綅醑鐲絰 箻\xBA 煅 㓁鑡\xE5 \xE1 醮\xE7 髠 炆歘\xB2 螋鑕 鑕遧麘 \x8F逡黕髲饛鐯\xE4 \xBF
\xBE澐\xAC
\xBE 
\xBE茡\xF9 鍗 迊\xF5 祧鉝髵\xE5 㓁煐\xE5 玵鉩鑨\xF3 焈 鍈隖鑡鑕\xF4 蟁禡鑡笇 \xC9 蟁䑶\xE4
\xBE 鑯玿鉻 邐\xEC 㓁\xE5 炆\xC5 玵鉩鑨\xF3 罭 檷\xE5 㓁\xE5 篚\x8F辣 籩艣鉝櫆鑣\xF4 炘 邗\xE4 
琱䅈\xF3 餺涴\xE5
\xBE 邠禖蔫淎 髠 㓁\xE5 篚\x8F辣 蟁禡鑡\xAE 煅 髲 渢\xF4 㓁\xE5 鉑簋\xBF
\xBE 
\xBE曏幖
\xBE醃\xEE
\xBE 
\xBE\xBE 挻挻撑禖韠涫\xEC 瘃帮邅鎕挻挻
\xBE\xBE 沟焇\xBA 鉽邗韝舡淎\x8F迚淎摝邋鉝麯窊鉵\xED 彛餳淎頙邗韯髠靽酹髃鑊黋桕焇\xBE
\xBE\xBE 絗湈\xBA 龢䄅\xE9 \xB2 渢蔌龣祧 傺傽 侷嬗\xB5
\xBE\xBE 缿\xBA 榷\x8F迥邗 痱禖焈 嶲邕邠髤毚 弡邕邠髤泂鉧篰漘鉵鼿\xBB 沅麨\xF0 纑饈邠 擥
\xBE\xBE ὶ罃饈邠 \xAD 礞盬漍砅 縝柷 紓\xCF 邢 桻篰滫 弣罃饈邠摟髬鉵桕焇愌 渲邗渼
\xBE\xBE 弶祊渞嫱鉧篰漘鉵鼿\xBB 曏渢髲 淩渞\xE5 嶙韐渞鎋 弜韐渞鏇鉧篰漘鉵鼿
\xBE\xBE 綅醑鐲絰 煅 㓁鑡\xE5 \xE1 醮\xE7 髠 炆歘\xB2 螋鑕 鑕遧麘 \x8F逡黕髲饛鐯\xE4 \xBF
\xBE\xBE
\xBE\xBE
\xBE\xBE
\xBE\xBE
\xBE\xBE 
\xBE\xBE
\xBE\xBE 鉽邗韝舡淎\x8F迚淎摝邋鉝麯窊鉵\xED
\xBE\xBE
\xBE\xBE
\xBE\xBE 沟焇\xBA 鉽邗韝舡淎\x8F迚淎摝邋鉝麯窊鉵\xED
\xBE\xBE 弴邋黕澐鉽邗韝舡淎\x8F迚淎摝邋鉝麯窊鉵鼿
\xBE\xBE 榷罃\xBA 傺傽捎侞乇 俁嬈\xB1
\xBE\xBE 缿\xBA 蕑爹錴\xF6 弴邋黕澐蕑爹錴菹麨幖窊隉桼澥
\xBE\xBE 柡\xBA 嶲鐽麇\xF2 弴邋黕澐嶲鐽麇砉鉧篰漘鉵鼿
\xBE\xBE 綅醑鐲絰 煅 㓁鑡\xE5 \xE1 醮\xE7 髠 炆歘\xB2 螋鑕 鑕遧麘 \x8F逡黕髲饛鐯\xE4 \xBF
\xBE\xBE 澐，
>   >
>   >  When I test IKEv2,   i found when enable multithread ,  the
> ike
>   > sa will be detelte quickly after IKE negotiation complete.
>   > The root casue is the inti and auth packet handle by one worker
>   > thread ,but the  informational packet was handled by the other
> thread.
>   > RSS is enable.
>   >
>   >
>   > The follow is my configuration
>   >
>   >
>   >
>   > cpu {
>   > ## In the VPP there is one main thread and optionally the user can
>   > create worker(s)
>   > ## The main thread and worker thread(s) can be pinned to CPU
> core(s)
>   > manually or automatically
>   >
>   >
>   > ## Manual pinning of thread(s) to CPU core(s)
>   >
>   >
>   > ## Set logical CPU core where main thread runs, if main core is
> not
>   > set
>   > ## VPP will use core 1 if available
>   > main-core 1
>   >
>   >
>   > ## Set logical CPU core(s) where worker threads are running
>   > # corelist-workers 2-3,18-19
>   > corelist-workers 2-3,4-5
>   >
>   >
>   > ## Automatic pinning of thread(s) to CPU core(s)
>   >
>   >
>   > ## Sets number of CPU core(s) to be skipped (1 ... N-1)
>   > ## Skipped CPU core(s) are not used for pinning main thread and
>   > working thread(s).
>   > ## The main thread is automatically pinned to the first available
>   > CPU core and worker(s)
>   > ## are pinned to next free CPU core(s) after core assigned to main
>   > thread
>   > # skip-cores 4
>   >
>   >
>   > ## Specify a number of workers to be created
>   > ## Workers are pinned to N consecutive CPU 

[vpp-dev] About nat44 translation with multi-tenancy

[samjen]

Hi all,

I’m testing multiple tenants using nat44-plugin.

The app version uses 21.10-release.
```
vpp# sh version
vpp v21-10-release built by root on 912b4c35bcd7 at 2021-10-27T12:54:43
```

I understand that when nat44 is enabled, one inside-vrf and one outside-vrf are 
specified (If not specified, vrf0 is specified).
In the following document:
https://docs.fd.io/vpp/21.10/dd/d6d/clicmd_src_plugins_nat_nat44-ed.html 


Given that only one inside-vrf, outside-vrf can be specified, I think that 1vrf 
+ 1tenant and that nat44 translation can not accommodate multi-tenancy.

Here may be the question:
Is there a way to do nat44 translation in multi-tenancy without specifying 
ports?

Any suggestion would be helpful. Thank you.

—
Kyosuke Hori (@samjen)
VPP Development List Member
mail: kyosuke1117su...@gmail.com
—


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