Re: [vpp-dev] RFC: move the “1”st instance of the community meeting 3 hours earlier to reduce impact for earlier time zone

OK, moving meeting tomorrow (and following 1st monthly meetings) for -3 hrs, new time is 5-6am PT. Wiki updated with: Bi-weekly on the second Tuesday of each month at 5-6am PT and fourth Tuesday of each month at 8-9am PT. — Damjan > On 07.12.2022., at 18:30, Damjan Marion

Re: [vpp-dev] RFC: move the “1”st instance of the community meeting 3 hours earlier to reduce impact for earlier time zone

Can we get a bit more votes on this? It is significant change so would like to confirm that everybody is ok with it…. — Damjan > On 24.11.2022., at 03:52, Marvin Liu wrote: > > +1, looking forward to join community meeting and have more discussions. > > From: vpp-dev@lists.fd.io

[vpp-dev] clang-15 fixes

Guys, I submitted patch which fixes issues reported by clang 15. https://gerrit.fd.io/r/c/vpp/+/37387 Mainly it is about variables which are computed but never used after…. Please take a look if your code is listed in this patch. — Damjan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all

Re: [vpp-dev] zero memcpy interface (alternative to memif) to pass packets from VPP to another trusted DPDK application

> be shared with external trusted applications? No, unfortunately there is no documentation, but there is running code (snort plugin) which does exactly that. If you have any questions, ask here and i will try to help. > > Thank you > > - PK Das > > > > > On Tue

Re: [vpp-dev] zero memcpy interface (alternative to memif) to pass packets from VPP to another trusted DPDK application

VPP is not DPDK application, VPP features doesnt maintain DPDK metadata, in many cases we use native drivers so DPDK is not even loaded so you cannot use rte_ring unless you want to write complete translation layer which will likely be significantly slower that using native way which snort

Re: [vpp-dev] Change how "unix exec" executes cli scripts

— Damjan > On 12.05.2022., at 15:12, Andrew  Yourtchenko wrote: > > Inline > >> On 12 May 2022, at 14:21, Damjan Marion wrote: >> >> Inline.. >> >> — >> Damjan >> >> >> >>> On 12.05.2022., at 09:06, A

Re: [vpp-dev] Change how "unix exec" executes cli scripts

I didn’t say it is urgent, I said that it is better to get it fixed in 22.06 than not having it fixed in 22.06 and I elaborated why. > > --a > >> On 11 May 2022, at 14:29, Damjan Marion via lists.fd.io >> wrote: >> >>  >> I didn’t hear back from anybo

Re: [vpp-dev] Change how "unix exec" executes cli scripts

022., at 13:56, Damjan Marion via lists.fd.io > wrote: > > > Hmm, not sure I understand concern about blast radius. I also replied to your > comment in gerrit. > > — > Damjan > > > >> On 09.05.2022., at 07:31, Andrew  Yourtchenko wrote: >> >>

Re: [vpp-dev] Segmentation fault when dpdk number-rx-queues > 1 in startup.conf

> On 06.05.2022., at 11:33, Xu, Ting wrote: > > Hi, Damjan > > I look into the code. The bad commit is > ce4083ce48958d9d3956e8317445a5552780af1a (“dpdk: offloads cleanup”), and the > previous commit is correct, so I compare these two. Since they use the same > DPDK version, I check the

Re: [vpp-dev] Change how "unix exec" executes cli scripts

s to wait at least until 22.06 RC1 is done. > > --a > >> On 8 May 2022, at 19:39, Damjan Marion via lists.fd.io >> wrote: >> >> Guys, >> >> I just submitted following patch which fixes long standing issue in how cli >> scripts are

Re: [vpp-dev] Change how "unix exec" executes cli scripts

Why do you think so? — Damjan > On 09.05.2022., at 03:43, jiangxiaom...@outlook.com wrote: > > Hi Damjan, > With your patch, most of current clis have to be modified, it may be a large > work. I think the suitable way is changing the meaning of VLIB_CLI_COMMAND > function's second params

[vpp-dev] Change how "unix exec" executes cli scripts

Guys, I just submitted following patch which fixes long standing issue in how cli scripts are executed. https://gerrit.fd.io/r/c/vpp/+/36101 Problem was that there was no way to execute CLIs which have optional arguments. I.e. “show version” and “show version verbose”. CLI parser was passing

Re: 35640 has a crashing regression, was Re: [vpp-dev] vpp-papi stats is broken

counter_index (vm=0x7fffa09fb2c0, e=3416) at > /home/pim/src/vpp/src/vlib/drop.c:77 > 77ASSERT (ci < n->n_errors); > (gdb) list > 72 > 73ni = vlib_error_get_node (>node_main, e); > 74n = vlib_get_node (vm, ni); > 75 > 76ci = vlib_erro

Re: 35640 has a crashing regression, was Re: [vpp-dev] vpp-papi stats is broken

This seems to be day one issue, and my patch just exposed it. Current interface deletion code is not removing node stats entries. So if you delete interface and then create one with the same name, stats entry is already there, and creation of new entry fails. Hope this helps:

[vpp-dev] vector allocator rework

Guys, As discussed on the last call, I did a rework of the VPP vector (and pool) allocator. https://gerrit.fd.io/r/c/vpp/+/35718 Here is the list of changes: - support of in-place growth of vectors (if there is available space next to existing alloc) - drops the need for

Re: [vpp-dev] Segmentation fault when dpdk number-rx-queues > 1 in startup.conf

#30 0x7fffc9f0 in ?? () > #31 0x76ecfdfe in vlib_unix_main (argc=59, argv=0x446500) at > /root/networking.dataplane.fdio.vpp/src/vlib/unix/main.c:751 > #32 0x00406b23 in main (argc=59, argv=0x446500) at > /root/networking.dataplane.fdio.vpp/src/vpp/vnet/main.c:3

Re: [vpp-dev] VxLAN set MTU

vxlan code is missing max_frame_size callback which is now mandatory if you want to be able to do the change. If vxlan code doesn’t care about that change, it can be as simple as: vxlan_set_max_frame_size (vnet_main_t *vnm, vnet_hw_interface_t *hw, u32 frame_size) { return 0; } and:

[vpp-dev] Community call today

Just a reminder, today we have community call, as we agreed to move to bi-weekly format. I created .ics file so people can put it in the calendar. Please let me know if you have any topics to discuss… — Damjan BEGIN:VCALENDAR VERSION:2.0 CALSCALE:GREGORIAN BEGIN:VTIMEZONE

Re: [vpp-dev] Bihash is considered thread-safe but probably shouldn't

Let me resurrect this discussion as my patch is still in gerrit. Nick, any chance you can submit your proposal as discussed bellow? Thanks, — Damjan > On 04.11.2021., at 19:35, Damjan Marion via lists.fd.io > wrote: > > > Dear Nick, > > Will be great if you can

Re: [vpp-dev] Risc-V Compilation Error

This may help you: https://gerrit.fd.io/r/c/vpp/+/34972 — Damjan > On 19.01.2022., at 11:15, Hrishikesh Karanjikar > wrote: > > Hi, > > I am trying to compile vpp on the SiFive HiFive Unmatched board. > Following is my build environment > >

Re: [vpp-dev]question on memif configuration

I am not able ro help with your libmemif related qurstions, but can answer 1st one. What you see is OK. Slave is always ring producer. In s2m direction slave is enqueueing packets to the ring and in m2s direction slave is enqueueing empty buffers. So from your output it is clear that s2m is

[vpp-dev] Topics for Tuesday Call

Hello and Happy New Year! I have 3 topics for Tuesday call[1]: - DPDK plugin rework - default MTU on Ethernet interfaces (change default to 1500 to avoid need for no-multi-seg in startup.conf) - change in CPU pinning defaults (we don’t use DPDK to launch threads anymore so we have more

[vpp-dev] vlib_frame_t aux data

I just submitted patch which cleans vlib_frame_t allocation code and adds support for aux data. https://gerrit.fd.io/r/c/vpp/+/34798 Example use case is when node passes array of sw_if_index to next node, so next node doesn’t need to do expensive parsing of buffer metadata. It is as simple

Re: Recommended NICs and drivers (was Re: [vpp-dev] About Risc-V Porting)

re, please share wiki link, > > > Thanks for details > //MJ > > > > > Best > ben > > > -Original Message- > > From: vpp-dev@lists.fd.io On Behalf Of Ben McKeegan > > Sent: mardi 9 novembre 2021 11:38 > > To: vpp-dev@lists.fd.io

Re: [vpp-dev] About Risc-V Porting

=== > Libatomic is present on my machine. > > Can you give me some pointers to resolve the same? > > Thanks, > Hrishikesh > > On Mon, Nov 8, 2021 at 8:19 PM Hrishikesh Karanjikar > mailto:hrishikesh.karanji...@gmail.com>> > wr

[vpp-dev] Dave Wallace to be VPP project represetative at TSC

Guys, According to the new fd.io Technical Community Doc: --- A Core Projects PTL may choose to appoint another committer from that Core Project to represent the core project in their stead. --- As Dave is already attending TSC meetings for a long period of time and he is very active I

Re: [vpp-dev] About Risc-V Porting

> On 08.11.2021., at 20:21, Mrityunjay Kumar wrote: > > Thank you for the clarification. > > Inline please, > > > > > On Tue, 9 Nov, 2021, 12:45 am Damjan Marion, wrote: > > > > > > > > > > > > > > On

Re: [vpp-dev] About Risc-V Porting

> > > > > > > > > On Mon, 8 Nov, 2021, 10:18 pm Damjan Marion via lists.fd.io, > > wrote: > > > > No, I didn’t bother… Not using DPDK for a long time... > > We know that, Who are “We”? > not required to say, but many of us follow

Re: [vpp-dev] About Risc-V Porting

e. > > I am only users of both open source. Knowledge exchange are appreciated. > > > > /MJ > > > > > On Mon, 8 Nov, 2021, 10:18 pm Damjan Marion via lists.fd.io, > wrote: > > No, I didn’t bother… Not using DPDK for a long time... > > — &

Re: [vpp-dev] About Risc-V Porting

had to compile without rdma-core. > > > > Thanks, > Hrishikesh > > On Mon, Nov 8, 2021 at 8:19 PM Hrishikesh Karanjikar > mailto:hrishikesh.karanji...@gmail.com>> > wrote: > Hi, > > This is great. > Thanks a lot. > Let me try that. > > Hri

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

02:58, haiyan...@ilinkall.cn wrote: > > I'm using vpp 20.01, is there any way that I can enable it manually ? > > haiyan...@ilinkall.cn > > From: Damjan Marion via lists.fd.io > Date: 2021-11-05 22:25 > To: haiyan.li > CC: vpp-dev > Subject: Re: [vpp-dev] how to enable avx

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

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

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

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

Re: [vpp-dev] Bihash is considered thread-safe but probably shouldn't

t;>> Agreed it’s unlikely so maybe just use the 2 bits left for the epoch >>> counter as a middle ground? The new approach should be better either way :-) >>> >>> Florin >>> >>> >>> On Nov 3, 2021, at 11:55 AM, Damjan Marion wrote: >>>

Re: [vpp-dev] Bihash is considered thread-safe but probably shouldn't

What about the following, we shift offset by 6, as all buckets are aligned to 64, anyway, and that gives us 6 more bits so we can have 8 bit epoch counter…. ? — Damjan > On 03.11.2021., at 19:45, Damjan Marion wrote: > >  > > yes, i am aware of that, it is extremelly un

Re: [vpp-dev] Bihash is considered thread-safe but probably shouldn't

the change bit might not be enough, unless I’m > misunderstanding. For instance, two consecutive updates to a bucket before > reader grabs b1 will hide the change. > > Florin > >> On Nov 3, 2021, at 9:36 AM, Damjan Marion via lists.fd.io >> wrote: >>

Re: [vpp-dev] Please include Fixes: tag for regression fix

We should probably extend checkstyle to reject patch if there is “Type: fix” and there is no “Fixes: *”. We can have special case “Fixes: unknown” to willingly bypass this check…. — Damjan > On 02.11.2021., at 18:17, steven luong via lists.fd.io > wrote: > > Folks, > > In case you

Re: [vpp-dev] About Risc-V Porting

Vector > Extension yet. > Also Qemu is ready for RiscV. Ubuntu images are available for RIscV. > > Thanks, > Hrishikesh > > > On Mon, Oct 25, 2021 at 9:56 PM Damjan Marion <mailto:dmar...@me.com>> wrote: > > > > > On 14.10.2021., at

Re: [vpp-dev] Linking DPDK libs to plugins

: vpp-dev@lists.fd.io On Behalf Of bjeremy32 via >> lists.fd.io >> Sent: Monday, October 25, 2021 2:18 PM >> To: 'Damjan Marion' >> Cc: vpp-dev@lists.fd.io >> Subject: Re: [vpp-dev] Linking DPDK libs to plugins >> >> I believe it was just ring that they

Re: [vpp-dev] Linking DPDK libs to plugins

k vs VPP metadata. Do we have all fields needed by vpp features in rte_mbuf? > > > I am sure, we can get significant performance count as well. > > What is your input. I doubt that will happen for many reasons, one of them is that it will require all features to be rewritten.

Re: [vpp-dev] About Risc-V Porting

> On 14.10.2021., at 15:43, Hrishikesh Karanjikar > wrote: > > > Hi, > > Is VPP ported for the Risc-V processor? > Is there any project going for the same? > I was looking at that a year ago but I was not able to find any suitable dev board. Is there anything new on the market? —

Re: [vpp-dev] Linking DPDK libs to plugins

ross our multiple plugins > 3. We want to be able to include rte_mempool data structures from our > multiple header files (.h files ) > 4. We want to be able to make calls to rte_mempool apis from our source code > ( .c files ) > > -Original Message- > From: Da

Re: [vpp-dev] Linking DPDK libs to plugins

> On 25.10.2021., at 01:13, bjerem...@gmail.com wrote: > > Greetings, > > Let me preface this by saying that I really do not know much about the CMake > utility. But I am trying to see if there is a way to make the DPDK libs > accessible to other plugins (aside from the dpdk plugin) that

Re: [vpp-dev] Does memif zero-copy work ?

ility and high cost of mandatory use of EAL. — Damjan > > > > >> On Sun, 24 Oct, 2021, 4:28 pm Damjan Marion, wrote: >> >> And what is the benefit of doing that? >> >> — >> Damjan >> >> >> >>> On 24.10.2021., a

Re: [vpp-dev] Does memif zero-copy work ?

in dpdk plugin to inject EAL in rte_eal_init. > > > > > On Sun, 24 Oct, 2021, 5:16 am Damjan Marion, <mailto:dmar...@me.com>> wrote: > What is your suggestion? Which part of the plugin is wrongly written? > > — > Damjan > >> On 24.10.2

Re: [vpp-dev] Does memif zero-copy work ?

ly VPP memif plugin is wrongly/misleadingly written and it also > misguiding to VPP users. > > When I look this code long back, it also misleading me. > > > >> On Sat, 23 Oct, 2021, 11:52 pm Damjan Marion via lists.fd.io, >> wrote: >> >> Please note that

Re: [vpp-dev] Does memif zero-copy work ?

Please note that “zero copy memif” doesn’t exist. Long time ago I possibly wrongly/misleadingly added VPP feature with name “zero-copy slave”. It is vpp internal feature which avoids 2nd memcopy by exposing VPP (slave only) buffers directly to master. In such scenario still one memcpy

Re: [vpp-dev] Are INPUT and PROCESS nodes considered for CPU util calculations?

Dear Satya, If you are in polling mode CPU is always 100% utilised. Not sure what do you mean by "CPU utilisation” here... — Damjan > On 18.10.2021., at 16:16, Satya Murthy wrote: > > Hi VPP Experts, > > We have an issue at hand, where we are seeing non-uniform CPU utilizations >

Re: [vpp-dev] AVF interface creation fails on VFs with configured VLAN with newer i40e drivers

Cisco Systems Limited From: Damjan Marion (damarion) mailto:damar...@cisco.com>> Sent: Thursday, October 7, 2021 14:02 To: Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) Cc: Juraj Linkeš; vpp-dev; Lijian Zhang Subject: Re: [vpp-dev] AVF interf

Re: [vpp-dev] AVF interface creation fails on VFs with configured VLAN with newer i40e drivers

simple as to: = disable_vlan_stripping() if error: vlan_cannot_stripped_flag == 1 # ignore the error. Thoughts? [0] https://downloadmirror.intel.com/24693/eng/readme_4.2.7.txt Peter Mikus Engineer – Software Cisco Systems Limited From: Damjan Marion (da

Re: [vpp-dev] AVF interface creation fails on VFs with configured VLAN with newer i40e drivers

t; Subject: Re: [vpp-dev] AVF interface creation fails on VFs with configured >> VLAN >> with newer i40e drivers >> >> >> >>> -Original Message- >>> From: vpp-dev@lists.fd.io On Behalf Of Damjan >>> Marion via lists.fd.io >>

Re: [vpp-dev] No rdma plugin in el/8 rpm package 21.06 repository, it obsolete?

— Damjan > On 23.09.2021., at 15:00, Юрий Иванов wrote: > > Hi, > > I see there is no rdma plugin in prebuilded packages 21.06 version > [suser@RockyVPP-1 ~]$ dnf repoquery -l vpp* | grep rdma | grep -P ".so$" | > grep plugi > Last metadata expiration check: 0:00:05 ago on Thu 23 Sep 2021

Re: [vpp-dev] config 1G hugepage

With running VPP you can do: $ grep huge /proc/$(pgrep vpp)/numa_maps 10 default file=/memfd:buffers-numa-0\040(deleted) huge dirty=19 N0=19 kernelpagesize_kB=2048 100260 default file=/memfd:buffers-numa-1\040(deleted) huge dirty=19 N1=19 kernelpagesize_kB=2048 1004c0 default

Re: [vpp-dev] Enable DPDK tx offload flag mbuf-fast-free on VPP vector mode

— Damjan > On 22.09.2021., at 11:50, Jieqiang Wang wrote: > > Hi Ben, > > Thanks for your quick feedback. A few comments inline. > > Best Regards, > Jieqiang Wang > > -Original Message- > From: Benoit Ganne (bganne) > Sent: Friday, September 17, 2021 3:34 PM > To: Jieqiang Wang

Re: [vpp-dev] AVF interface creation fails on VFs with configured VLAN with newer i40e drivers

> On 10.09.2021., at 08:53, Juraj Linkeš wrote: > > > > From: vpp-dev@lists.fd.io On Behalf Of Damjan Marion > via lists.fd.io > Sent: Thursday, September 9, 2021 12:01 PM > To: Juraj Linkeš > Cc: vpp-dev ; Lijian Zhang > Subject: Re: [vpp-dev] AVF i

[vpp-dev] getting a rid of vpe.api

Guys, Can we get a rid of vpp/api/vpe.api and vpp/api/vpe_types.api by moving content to more appropriate places. I.e. some basic types and control_ping may be good candidate for vlibapi/. It is quite weird that we have dozens of plugins depending on header files autogenerated from the main

Re: [vpp-dev] AVF interface creation fails on VFs with configured VLAN with newer i40e drivers

On 09.09.2021., at 09:14, Juraj Linkeš mailto:juraj.lin...@pantheon.tech>> wrote: Hi Damjan, vpp devs, Upgrading to 2.15.9 i40e driver in CI (from Ubuntu's 2.8.20-k) makes AVF interface creation on VFs with configured VLANs fail: 2021/08/30 09:15:27:343 debug avf :91:04.1: request_queues:

Re: [vpp-dev] Regarding assert in vlib_buffer_advance

feedback. > Out of curiosity, what is the motivation of this contract about > minimal length of chained buffer data -- surely, my case being in > point, the chaining framework should not make any assumptions about > how the user would use it. > > Regards > -Prashant > &g

Re: [vpp-dev] Regarding assert in vlib_buffer_advance

— Damjan > On 06.09.2021., at 15:27, Prashant Upadhyaya wrote: > > Hi, > > I am using VPP21.06 > In vlib_buffer_advance there is the following assert -- > ASSERT ((b->flags & VLIB_BUFFER_NEXT_PRESENT) == 0 || > b->current_length >= VLIB_BUFFER_MIN_CHAIN_SEG_SIZE); > > The above

Re: [vpp-dev] TX Queue Placement

> On 03.09.2021., at 20:10, Mrityunjay Kumar wrote: > > Please find the comment inline below. > Regards, > Mrityunjay Kumar. > Mobile: +91 - 9731528504 > > > > On Fri, Sep 3, 2021 at 9:52 PM Damjan Marion <mailto:dmar...@me.com>> wrote: > >

[vpp-dev] vpp-plugin-devtools

Hello, We have more and more plugins which are intended to be developer tools, and not really useful in production installs. Good examples are: unittest, bufmon, perfmon, dispatch-trace, tracedump. I think we should move them to separate .deb package called vpp-plugin-devtools. Thoughts? —

Re: [vpp-dev] master branch build failed #vpp-dev

But it is good news for pretty much everybody else involved :) Simply too old, too many missing dependencies, etc….. — Damjan > On 26.08.2021., at 14:29, jiangxiaom...@outlook.com wrote: > > it's not a good news for me > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to

Re: [vpp-dev] master branch build failed #vpp-dev

t? > commit a5167edc66c639e139ffb5de4336c54bb3d8a871 > Author: Damjan Marion > Date: Fri Jul 2 16:04:26 2021 +0200 > > build: remove unused files and sections > > Type: make > Change-Id: Ia1d8c53c5fb02f7e5c86efab6e6ccd0fdb16bc96 > Signed-off-by: Damjan Marion > > diff --git a

Re: [vpp-dev] master branch build failed #vpp-dev

Your C compiler is too old…. You should use gcc 8+ or clang 7+ — Damjan > On 26.08.2021., at 03:31, jiangxiaom...@outlook.com wrote: > > Hi all, > Vpp master branch build failed, anyone have the save issue > > @@@ Configuring vpp in >

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

Re: [vpp-dev] compilation error in vpp 20.05

> On 16.07.2021., at 16:58, ashish.sax...@hsc.com wrote: > > Hi Devs, > I am trying to compile VPP 20.05 on centos 8.2 machine. Using the following > steps for compilation: > > make wipe-release > make install-dep > make install-ext-deps > make build-release > make pkg-rpm > > > > I am

Re: [vpp-dev] HQOS in latest VPP

> On 15.07.2021., at 18:16, satish amara wrote: > > Hi, >It looks like Hierarchical Queuing support is not supported in the latest > VPP release. The last release I see is 20.01. Any plans to support it > again in the future VPP? I don't see the config commands or nor hqos code in >

Re: [vpp-dev] Buffer chains and pre-data area

> On 15.07.2021., at 18:53, jerome.bay...@student.uliege.be wrote: > > Dear vpp-dev, > > I'm trying to do some IPv6 in IPv6 encapsulation with no tunnel configuration. > > The objective is to encapsulate the received packet in an other IPv6 packet > that will also "contain" a Hop-by-hop

Re: [vpp-dev] VPP on different Linux Platforms

> On 15.07.2021., at 16:51, satish amara wrote: > > [Edited Message Follows] > > Thanks, I am trying to understand the dependencies of VPP are based on the OS > kernel/Linux flavors (Centos, Redhat, Ubuntu). What version of Linux kernel > it can run. On pretty much any OS kernel/Linux

Re: [vpp-dev] Prefetches improvement for VPP Arm generic image

I spent a bit of time to look at this and come up with some reasonable solution. First, 128-byte cacheline is not dead, recently announced Marvell Octeon 10 have 128 byte cacheline. In current code cacheline size defines both amount of data prefetch instruction prefetches and alignment of

Re: [EXTERNAL] [vpp-dev] Multi-threading locks and synchronization

> On 13.07.2021., at 18:41, satish amara wrote: > > Sync is needed. It's a question about the design of packet flow in VPP. > Locks can be avoided if the packets in a flow are processed by the same > thread. You can use the handoff to make sure all packets belonging to specific flow or

Re: [vpp-dev] VPP on different Linux Platforms

> On 13.07.2021., at 19:40, satish amara wrote: > > Hi, > Currently, the VPP code can be compiled only on RedHat, CentOS, and Ubuntu. > Can I compile the VPP code on other OS Linux flavors, I see it's hardcoded in > the makefile. I am trying to understand by changing the Makefile VPP code

Re: [vpp-dev] Multi-threading locks and synchronization

> On 11.07.2021., at 17:10, satish amara > wrote: > > [Edited Message Follows] > > Hi, >I have a few questions about how synchronization is being done when there > are multiple workers/threads accessing the same data structure. > For example, IPsec headers

Re: [vpp-dev] Multi-threading locks and synchronization

> On 11.07.2021., at 17:10, satish amara > wrote: > > [Edited Message Follows] > > Hi, >I have a few questions about how synchronization is being done when there > are multiple workers/threads accessing the same data structure. > For example, IPsec headers

Re: [vpp-dev] Prefetches improvement for VPP Arm generic image

Hi Lijian, It will be good to know if 128 byte cacheline is something ARM platforms will be using in the future or it is just historical. Cacheline size problem is not just about prefetching, even bigger issue is false sharing, so we need to address both. Probably best solution is to have 2

Re: [vpp-dev] heap sizes

> On 01.07.2021., at 16:12, Matthew Smith wrote: > > > > On Thu, Jul 1, 2021 at 6:36 AM Damjan Marion wrote: > > > > On 01.07.2021., at 11:12, Benoit Ganne (bganne) via lists.fd.io > > wrote: > > > >> Yes, allowing dynamic heap growth so

Re: [vpp-dev] VPP on a Bluefield-2 smartNIC

> On 01.07.2021., at 07:35, Pierre Louis Aublin > wrote: > > diff --git a/build/external/packages/ipsec-mb.mk > b/build/external/packages/ipsec-mb.mk > index d0bd2af19..119eb5219 100644 > --- a/build/external/packages/ipsec-mb.mk > +++ b/build/external/packages/ipsec-mb.mk > @@ -34,7 +34,7

Re: [vpp-dev] VPP on a Bluefield-2 smartNIC

Might be worth trying our native driver (rdma) instead of using dpdk….. — Damjan > On 01.07.2021., at 11:07, Pierre Louis Aublin > wrote: > > The"Unsupported PCI device 0x15b3:0xa2d6 found at PCI address :03:00.0" > message disappears; however the network interface still doesn't show

Re: [vpp-dev] heap sizes

> On 01.07.2021., at 11:12, Benoit Ganne (bganne) via lists.fd.io > wrote: > >> Yes, allowing dynamic heap growth sounds like it could be better. >> Alternatively... if memory allocations could fail and something more >> graceful than VPP exiting could occur, that may also be better. E.g. if

Re: [vpp-dev] vpp in a non-previleged mode

> Now we were looking at below link for examples, but no luck... they > non-previleged running vpp + dpdk had some problems. > https://github.com/cncf/cnf-testbed/issues/291 > > Hence i am trying to check in the community. > > Thanks, > Regards, > Venu > > >>

Re: [vpp-dev] vpp in a non-previleged mode

Why do you need dpdk? — Damjan > On 18.06.2021., at 06:47, Venumadhav Josyula wrote: > >  > Hi Christian, > > Can you please share the exact steps please ? > > Thanks, > Regards, > Venu > >> On Thu, 17 Jun 2021 at 21:25, Christian Hopps wrote: >> >> "Venumadhav Josyula" writes: >>

Re: [vpp-dev] clib_mask_compare_u16_x64 has asan issue

yes, for performance reason it is written as it is, you can ask asan to ignore it — Damjan > On 17.06.2021., at 11:28, jiangxiaom...@outlook.com wrote: > > Hi Damjan Marion, > > vector function: clib_mask_compare_u16_x64 has ASAN Issue, > > clib_mask_compar

Re: [vpp-dev] Proposed removal of Centos-8 jobs from master

> On 07.06.2021., at 17:24, Dave Wallace wrote: > > Folks, > > The RPM builds have been unmaintained for a couple years now and the CentOS-8 > jobs have become the long pole in the CI verification cycle as well as > costing time to maintain the builds due to changes upstream. > > I am

Re: [vpp-dev] What are the available atomic operations in VPP #vpp-dev #vpp #counters

VPP is just a C app. So you can use standard C atomics… Have you tried to do something like “git grep atomic” in the vpp repo ? — Damjan > On 05.06.2021., at 19:39, Mohanty, Chandan (Nokia - IN/Bangalore) > wrote: > > VPP experts, > Any pointers on this will be much appreciated and help

Re: [vpp-dev] unformat_vnet_uri not implemented following RFC 3986

Same RFC defines that for IPv6, square brackets should be used to distinguish between addr and port: A host identified by an Internet Protocol literal address, version 6 [RFC3513] or later, is distinguished by enclosing the IP literal within square brackets ("[" and "]"). This is the

Re: [vpp-dev] IPv6 in IPv6 Encapsulation

> On 21.05.2021., at 17:14, Neale Ranns wrote: > > Right, there’s only so much space available. You’ll need to recompile VPP to > get more space. > Change the PRE_DATA_SIZE value in src/vlib/CMakeLists.txt. Changing makefiles is bad. cmake allows specifying custom values with -D or

Re: [vpp-dev] Run VPP as non root user

> On 20.05.2021., at 12:26, ashish.sax...@hsc.com wrote: > > Hi All, > We are using VPP version 21.01 on our setup. We are able to run vpp as root > user , but getting the following error while running VPP as non root user: > $ vppctl > clib_socket_init: connect (fd 3, '/run/vpp/cli.sock'):

Re: [vpp-dev] Fail to build vpp locally

Yes, you need intel ipsecmb library version 1.0. We should better deal with this kind of situations, display warning and turn off feature instead of compile failures. do “make install-ext-dep”…. — Damjan > On 20.05.2021., at 11:46, liuyacan wrote: > > Hi, All > >I checked out

Re: [vpp-dev] [DPDK] AF_XDP PMD

ote: > > So shouldn't this hack for also using the vpp buffer manager be generally > usable with all PMDs? > From: Damjan Marion > Sent: Tuesday, May 18, 2021 1:17 > To: Catalin Vasile > Cc: vpp-dev@lists.fd.io > Subject: Re: [vpp-dev] [DPDK] AF_XDP PMD > > > No,

Re: [vpp-dev] [DPDK] AF_XDP PMD

No, dpdk PMDs are also using vpp buffer manager, we are cheating a bit by registering fake mempool. — Damjan > On 17.05.2021., at 23:40, Catalin Vasile wrote: > > �쏜㷃�쏜㷃�쏜㋢鹋ᢢ燨꽹ꥥ駫ⱪެ뇩譡諈⮢觬㽅죩瞵皆�돿쭬緘ꣾ࿯ꚗ庿咽닆ꁻﵽ�貺힓蘫Ꭲ颜蛛榳￥請汽�﹫翳漷㛿껹蚮让㬉�響痫ﺣ৞깘겶쟝誅➲犸魺᭭ꛏﾖ⬭뇷抣뺚嵺￮黋魶暫誉쨦�쏜㷃�쏜㷃�쏜

Re: [vpp-dev] [DPDK] AF_XDP PMD

Probably nobody tried, and knowing that vpp doesn’t use dpdk buffer manager, i would be very surprised if it works. What is wrong with using VPP native AF_XDP? — Damjan > On 15.05.2021., at 01:26, Catalin Vasile wrote: > >  > Hi, > > I know VPP has an AF_XDP plugin, but I'm trying to use

Re: [vpp-dev] vlib_buffer_clone behavior when trying to send to two interfaces

> On 14.04.2021., at 17:44, David Gohberg wrote: > > using DPDK with Mellanox MT27800 [ConnectX-5] (100G) might be worth trying to use native rdma diver. > show buffers indeed shows a leak: > > Pool NameIndex NUMA Size Data Size Total Avail Cached Used > >

Re: [vpp-dev] vlib_buffer_clone behavior when trying to send to two interfaces

> On 14.04.2021., at 17:15, David Gohberg wrote: > > When testing Damjan's version under traffic (using trex with a few thousand > pps) > after about 5 minutes into the test vlib_buffer_clone fails to create 2 > copies and vpp crashes due to double-free error. > looks like the buffer pool

Re: [vpp-dev] TX Queue Placement

d what value fits better to my environment, do have > any thoughts about it? > > Best Regards > De: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> <mailto:vpp-dev@lists.fd.io>> Em nome de Damjan Marion via lists.fd.io > <http://lists.fd.io/> > Envia

Re: [vpp-dev] TX Queue Placement

> On 14.04.2021., at 13:21, Marcos - Mgiga wrote: > > Hello, > > I increased VPP rx/tx queues in order to enable RSS on VPP instance. Since > VPP is running on a NUMA system with two threads with 8 cores each, I would > like to pin TX / RX queue to proper NUMA nodes. > > Using set

Re: [vpp-dev] How to enable Mellanox compilation in VPP 21.01

> On 14.04.2021., at 10:07, chetan bhasin wrote: > > Hi, > > I have to do the following to enable Mellanox compilation under VPP21.01 with > dpdk 20.11. > > If I dont comment rdma-core dependencies , it will lead to undefined symbols > . > > Can anybody please correct , is this the right

Re: [vpp-dev] vlib_buffer_clone behavior when trying to send to two interfaces

> On 12.04.2021., at 12:50, David Gohberg wrote: > > Damjan, > > After looking at the vlib_buffer_clone_256 function I realize that it > modifies the original buffer pointer, like you said. > my packets are coming in down a custom node path (originating from an asic > data plane), so they

Re: [vpp-dev] vlib_buffer_clone behavior when trying to send to two interfaces

> On 12.04.2021., at 10:34, David Gohberg wrote: > > [Edited Message Follows] > > moving the buffer backwards by 14 looks correct for small packets, but for > 1500 byte packets I get `truncated-ip - 14 bytes missing` error from tcpdump. > After the clone I'm restoring the original offset: >

Re: [vpp-dev] Creating qemu VMs using memif instead of vhostuser #vpp-memif #vpp #dpdk #vhost

> On 10.04.2021., at 09:14, abhinav.mishra via lists.fd.io > wrote: > > Hi everyone, > > I am wondering if we can create VMs using memifs instead of normal vhostuser > interfaces. > Normal qemu command for creating virtio ifs in VM looks like : > > create vhost-user socket

Re: [vpp-dev] vlib_buffer_clone behavior when trying to send to two interfaces

OK, what about something like this: vnet_hw_interface_t * host_intf = vnet_get_sup_hw_interface (vnm, sw_if_index); vlib_frame_t *to_frame = vlib_get_frame_to_node (vm, node_index); vlib_frame_t *host_if_frame = vlib_get_frame_to_node(vm, host_intf->tx_node_index); u32 *to_next =

  1   2   3   4   5   6   7   8   9   >