RE: How to rte_epoll_wait for IPC?

> -Original Message- > From: Morten Brørup > Sent: Friday, October 6, 2023 5:04 AM > To: Harman Kalra ; Anatoly Burakov > ; David Hunt > Cc: dev@dpdk.org > Subject: How to rte_epoll_wait for IPC? > > Dear Harman, Anatoly and David, > > I have been looking somewhat into power manageme

RE: [RFC 1/2] eal: add pointer compression functions

> -Original Message- > From: Thomas Monjalon > Sent: Monday, October 9, 2023 10:54 AM > To: Paul Szczepanek > Cc: dev@dpdk.org; Honnappa Nagarahalli ; > Kamalakshitha Aligeri > Subject: Re: [RFC 1/2] eal: add pointer compression functions > > 27/09/

DTS roadmap for 23.11

Hello, Following is the roadmap for DTS for 23.11 release. 1) DTS API document auto generation https://patches.dpdk.org/project/dpdk/cover/20230831100407.59865-1-juraj.lin...@pantheon.tech/ 2) Scatter test suite along with TG packet manipulation and verification https://patches.dpdk.org/p

Minutes of Technical Board Meeting, 2023-August-23

Minutes of Technical Board Meeting, 2023-August-23 Members Attending - -Aaron -Bruce -Hemant -Honnappa (Chair) -Jerin -Kevin -Maxime -Stephen NOTE: The technical board meetings every second Wednesday at https://meet.jit.si/DPDK at 3 pm UTC. Meetings are public, and DPDK communit

Canceled: DTS WG discussions

Honnappa Nagarahalli i s inviting you to a scheduled Zoom meeting.\n\nJoin Zoom Meeting\nhttps:// armltd.zoom.us/j/97503259680?pwd=VVlmWnlnTXJkVGkwR2JOU3R3b3Vndz09&from=add on\n\nMeeting ID: 975 0325 9680\nPasscode: 464615\nOne tap mobile\n+134624 87799\,\,97503259680#\,\,\,\,*464615# US (Housto

RE: Copy-pasted code should be updated

> > > > > > > > Dear Intel PMD maintainers (CC: techboard), > > > > > > I strongly recommend that you update the code you copy-pasted from > > the > > > mempool library to your PMDs, so they reflect the new and improved > > > mempool cache behavior [1]. When choosing to copy-paste code from a > >

RE: TODO - remove dependency on ifconfig

> > On Tue, Jan 10, 2023 at 9:19 PM Stephen Hemminger > wrote: > > > > It would be good if DTS and DPDK docs and test did not use the ifconfig > command. > > Ifconfig is not maintained and is deprecated. Some distros have stopped > shipping it. > > Ifconfig only used ioctl's and was never updat

Issues with MLX NIC perf report

Hello, I am looking at [1]. In Chapter 8, Table 18, 'Test Configuration' mentions using 16 cores. However, in section 8.1, Table 19, 'Command Line' is using 12 cores. Appreciate correcting this. I assume the command line is the correct one. Thanks, Honnappa [1] https://fast.dpdk.org/d

DTS WG roadmap for 23.02

Hello, The following patches have been submitted for 23.02 release. 1) Add docker file for creating DTS dev environment and for CI http://patches.dpdk.org/project/dpdk/patch/20221103134633.446646-1-juraj.lin...@pantheon.tech/ 2) Add code needed to run the HelloWorld testcase http://patche

DTS WG MoM 2023 link

Hello, The DTS WG MoM for 2023 are captured at [1]. Thank you, Honnappa [1] https://docs.google.com/document/d/1Ej1QyqSPH3ae2nPwG4oZ5Bteb26uH61RmrsZSAECXLU/edit?usp=sharing

RE: [RFC v2 7/9] net/gve: support basic stats for DQO

Few comments inline > -Original Message- > From: Junfeng Guo > Sent: Monday, January 30, 2023 12:27 AM > To: qi.z.zh...@intel.com; jingjing...@intel.com; ferruh.yi...@amd.com; > beilei.x...@intel.com > Cc: dev@dpdk.org; xiaoyun...@intel.com; helin.zh...@intel.com; Junfeng Guo > ; Rushil G

RE: [RFC v2 6/9] net/gve: support basic Rx data path for DQO

> -Original Message- > From: Junfeng Guo > Sent: Monday, January 30, 2023 12:27 AM > To: qi.z.zh...@intel.com; jingjing...@intel.com; ferruh.yi...@amd.com; > beilei.x...@intel.com > Cc: dev@dpdk.org; xiaoyun...@intel.com; helin.zh...@intel.com; Junfeng Guo > ; Rushil Gupta ; Jordan > Ki

RE: [PATCH v3 2/2] ring: add ring info telemetry cmd

Few minor nits. Otherwise, Reviewed-by: Honnappa Nagarahalli > -Original Message- > From: Jie Hai > Sent: Monday, January 30, 2023 8:29 PM > To: Honnappa Nagarahalli ; > konstantin.v.anan...@yandex.ru; dev@dpdk.org > Cc: liudongdo...@huawei.com; haij...@huawei.com &g

RE: [PATCH v3 1/2] ring: add ring list telemetry cmd

Few minor comments inline. Otherwise, Reviewed-by: Honnappa Nagarahalli > -Original Message- > From: Jie Hai > Sent: Monday, January 30, 2023 8:29 PM > To: Honnappa Nagarahalli ; > konstantin.v.anan...@yandex.ru; dev@dpdk.org > Cc: liudongdo...@huawei.com; haij...@hu

RE: [PATCH] eal: introduce atomics abstraction

> -Original Message- > From: Thomas Monjalon > Sent: Tuesday, January 31, 2023 4:42 PM > To: Honnappa Nagarahalli > Cc: dev@dpdk.org; bruce.richard...@intel.com; m...@smartsharesystems.com; > Tyler Retzlaff ; david.march...@redhat.com; > jer...@marvell

RE: no printf in drivers code

> -Original Message- > From: Thomas Monjalon > Sent: Friday, February 3, 2023 7:57 AM > To: Nicolas Chautru ; hemant.agra...@nxp.com; > Sachin Saxena ; Gagandeep Singh > ; Sunil Uttarwar ; > Bruce Richardson ; Conor Walsh > ; Chaoyong He ; Niklas > Soderlund ; Rasesh Mody > ; Devendra S

RE: no printf in drivers code

> Subject: Re: no printf in drivers code > > On Fri, Feb 3, 2023 at 5:40 PM Thomas Monjalon > wrote: > > > > 03/02/2023 17:18, Honnappa Nagarahalli: > > > From: Thomas Monjalon > > > > > > > > We have too many drivers using printf

RE: [RFC] lib/st_ring: add single thread ring

> -Original Message- > From: Konstantin Ananyev > Sent: Monday, September 4, 2023 5:13 AM > To: Honnappa Nagarahalli ; > jack...@nvidia.com; konstantin.v.anan...@yandex.ru > Cc: dev@dpdk.org; Ruifeng Wang ; Aditya > Ambadipudi ; Wathsala Wathawana Vithanage > ;

RE: quick thread in DLB2

> -Original Message- > From: Mattias Rönnblom > Sent: Wednesday, September 13, 2023 10:48 AM > To: Sevincer, Abdullah ; Stephen Hemminger > ; tho...@monjalon.net > Cc: dev@dpdk.org; Tyler Retzlaff > Subject: Re: quick thread in DLB2 > > On 2023-09-11 16:28, Sevincer, Abdullah wrote: >

RE: Process for adding a new driver?

> -Original Message- > From: Morten Brørup > Sent: Monday, September 18, 2023 2:08 AM > To: techbo...@dpdk.org; maxime.coque...@redhat.com > Cc: dev@dpdk.org; Ferruh Yigit ; > andrew.rybche...@oktetlabs.ru; Christian Koue Muf ; > Renyong Wan > Subject: Process for adding a new driver?

Re: [dpdk-dev] [PATCH v3 2/2] lib/mempool: distinguish debug counters from cache and pool

> >> diff --git a/lib/librte_mempool/rte_mempool.h > >> b/lib/librte_mempool/rte_mempool.h > >> index 848a19226149..0959f8a3f367 100644 > >> --- a/lib/librte_mempool/rte_mempool.h > >> +++ b/lib/librte_mempool/rte_mempool.h > >> @@ -66,12 +66,20 @@ extern "C" { > >> * A structure that stores the

Re: [dpdk-dev] L3fwd mode in testpmd

> > > > > > > > On Thu, Mar 11, 2021 at 12:01 AM Honnappa Nagarahalli > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > >

Re: [dpdk-dev] L3fwd mode in testpmd

> > > > > > > > > > On Thu, Mar 11, 2021 at 12:01 AM Honnappa Nagarahalli > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hello, > > >

Re: [dpdk-dev] L3fwd mode in testpmd

> > > > > > > > > > > > > > On Thu, Mar 11, 2021 at 12:01 AM Honnappa > > > > > > > > > > > Nagarahalli wrote: > > > > > > > > > > > > > > > > > > >

Re: [dpdk-dev] L3fwd mode in testpmd

> > On Tue, 27 Apr 2021 10:50:20 +0100 > Ferruh Yigit wrote: > > > Agree that it may help testing to have l3fwd support on the testpmd. > > > > Two concerns, > > 1) Testpmd already too complex. > > 2) Code duplication. > > > > For 1), if the l3fwd can be implemented in testpmd as new, independ

Re: [dpdk-dev] L3fwd mode in testpmd

> > > > > > > On Tue, 27 Apr 2021 10:50:20 +0100 > > > Ferruh Yigit wrote: > > > > > > > Agree that it may help testing to have l3fwd support on the testpmd. > > > > > > > > Two concerns, > > > > 1) Testpmd already too complex. > > > > 2) Code duplication. > > > > > > > > For 1), if the l3fwd c

Re: [dpdk-dev] L3fwd mode in testpmd

> > >>>>>>>>>>>> On Thu, Mar 11, 2021 at 12:01 AM Honnappa Nagarahalli > > >>>>>>>>>>>> wrote: > > >>>>>>>>>>>>> > > >>>>>>>>>&g

Re: [dpdk-dev] L3fwd mode in testpmd

> > > > > This discussion has ended up as a stats discussion. But, we also need > to be able to change the configurable parameters easily. > > > > > If we implement the stats and ability to change the configurable > > > > > parameters, then it is essentially bringing in some of the > > > > > capa

Re: [dpdk-dev] [PATCH] config/arm: restore support for Qualcomm servers

> Subject: Re: [PATCH] config/arm: restore support for Qualcomm servers > > 28/04/2021 18:08, Thierry Herbelot: > > Like for other Arm chips, the 'soc' entry is also needed. > > > > Fixes: fddbe822c3eb ("config/arm: add Qualcomm") > > > > Signed-off-by: Thierry Herbelot > > Is there any testin

Re: [dpdk-dev] L3fwd mode in testpmd

On Wed, Apr 28, 2021 at 12:48 PM Bruce Richardson mailto:bruce.richard...@intel.com>> wrote: > I do not suggest pulling all these in. In our case, I see that the ask is > only on LPM. I am open to hearing what others see as the requirement. > I think fib is the planned long-term replacement fo

Re: [dpdk-dev] L3fwd mode in testpmd

> > > > > > > > > In fact, l3fwd is also quite big and complex: > > > $ wc -l examples/l3fwd/*.[h,c] |grep total > > > 6969 total > > > > > > Plus it will introduce extra dependencies (fib, lpm, hash, might-be > > > acl?) I am not sure it is a good idea to pull all these complexities into > >

Re: [dpdk-dev] [PATCH v1] test/ticketlock: use C11 atomic builtins for lcores sync

cc atomic builtins aren't 'C11' Sorry, I did not understand this, can you elaborate? I am referring to [1]. [1] https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html > > > > > Signed-off-by: Joyce Kong > > Reviewed-by: Honnappa Nagarahalli >

Re: [dpdk-dev] [PATCH v1] test/ticketlock: use C11 atomic builtins for lcores sync

> > > > > Subject: Re: [dpdk-dev] [PATCH v1] test/ticketlock: use C11 atomic > > > builtins for lcores sync > > > > > > On Wed, Apr 21, 2021 at 02:17:33AM -0500, Joyce Kong wrote: > > > > Convert rte_atomic usages to C11 atomic builtins for lcores sync > > > > in ticketlock testcases. > > > > > >

Re: [dpdk-dev] Use WFE for spinlock and ring

> > > > > > > > > > > > > > The rte_wait_until_equal_xxx APIs abstract the functionality > > > > > > > of 'polling for a memory location to become equal to a given > value'[1]. > > > > > > > > > > > > > > Use the API for the rte spinlock and ring implementations. > > > > > > > With the wait until

Re: [dpdk-dev] How to disable SVE auto vectorization while using GCC

> > On Fri, Apr 30, 2021 at 5:27 PM fengchengwen > wrote: > > > > Hi, ALL > > We have a question for your help: > > 1. We have two platforms, both of which are ARM64, one of which > supports > > both NEON and SVE, the other only support NEON. > > 2. We want to run on both platforms wit

Re: [dpdk-dev] [PATCH v1] test/ticketlock: use C11 atomic builtins for lcores sync

> > > > > > your subject line indicates the use of C11 which is a standard [1]. > > > > > > the patch itself uses gcc atomics builtins which are not part of C11 > > > standard so the subject line is incorrect and misleading. > > Ok, understood. How about the following? > > "use gcc's C11 atomic

Re: [dpdk-dev] [dpdk-stable] [PATCH] rte_ring: fix racy dequeue/enqueue in ppc64

> > Hi, everyone > > This patch can be closed with the following reasons. > > > -邮件原件----- > > 发件人: dev 代表 Honnappa Nagarahalli > > 发送时间: 2021年3月28日 9:00 > > 收件人: tho...@monjalon.net; Takeshi Yoshimura > > > > 抄送: sta...@dpdk.

Re: [dpdk-dev] [RFC PATCH] dmadev: introduce DMA device library

> > On Wed, Jun 16, 2021 at 02:14:54PM +0200, David Marchand wrote: > > On Tue, Jun 15, 2021 at 3:25 PM Chengwen Feng > wrote: > > > + > > > +#define RTE_DMADEV_NAME_MAX_LEN(64) > > > +/**< @internal Max length of name of DMA PMD */ > > > + > > > +/** @internal > > > + * The data struct

Re: [dpdk-dev] [PATCH v1] net/i40e: remove the SMP barrier in HW scanning func

> > > > > > > > > > > > > > > > > > > Add the logic to determine how many DD bits have been set > > > > > > > for contiguous packets, for removing the SMP barrier while reading > descs. > > > > > > > > > > > > I didn't understand this. > > > > > > The current logic already guarantee the read out

Re: [dpdk-dev] [PATCH v2 0/8] use GCC's C11 atomic builtins for test

> > On Tue, Jun 15, 2021 at 09:54:51PM -0500, Joyce Kong wrote: > > Since C11 memory model is adopted in DPDK now[1], use GCC's atomic > > builtins in test cases. > > as previously discussed these atomics are not "C11" they are direct use of gcc > builtins. please don't incorporate C11 into the

Re: [dpdk-dev] [PATCH v8 1/2] config/arm: select most suitable -march for kunpeng soc

> > 24/05/2021 15:23, Chengwen Feng: > > Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve', > > but some compiler doesn't recognize the march because it doesn't > > support sve. > > > > To solve this bug we use the following scheme: > > 1. Define 'march_base' tuple which defin

[dpdk-dev] Canceled: DTS improvement WG - Debate/triag inputs - Extending for next 5 weeks

Cancelling this week as Lincoln and I are on vacation. Thanks, Honnappa Hello, We will continuing debating/triaging the inputs from [1]. As discussed, I am blocking the calendar for next 4 weeks. Thank you, Honnappa [1] https://docs.google.com/document/d/1c5S0_mZzFv

Re: [dpdk-dev] [PATCH v2 0/8] use GCC's C11 atomic builtins for test

> > 18/06/2021 01:26, Honnappa Nagarahalli: > > > On Tue, Jun 15, 2021 at 09:54:51PM -0500, Joyce Kong wrote: > > > > Since C11 memory model is adopted in DPDK now[1], use GCC's atomic > > > > builtins in test cases. > > > > > > as pr

Re: [dpdk-dev] [PATCH v2] net/i40e: add logic of processing continuous DD bits for Arm

> > For Arm platforms, reading descs can get re-ordered, then the status of DD > bits will be discontinuous, so add the logic to only process continuous descs > by checking DD bits. > > Fixes: 4861cde46116 ("i40e: new poll mode driver") > Cc: sta...@dpdk.org > > Signed-off-by: Joyce Kong > Rev

Re: [dpdk-dev] [PATCH v2 0/8] use GCC's C11 atomic builtins for test

> > > > > > 18/06/2021 01:26, Honnappa Nagarahalli: > > > > > On Tue, Jun 15, 2021 at 09:54:51PM -0500, Joyce Kong wrote: > > > > > > Since C11 memory model is adopted in DPDK now[1], use GCC's > > > > > > atomic builtin

Re: [dpdk-dev] [PATCH v2 0/8] use GCC's C11 atomic builtins for test

> > > > As I mentioned earlier in this thread, GCC supports 2 types of > > atomics. "Use GCC atomic builtins" does not help distinguish between > > them. In "GCC's C11 atomic builtins" - "C11" indicates which atomics > > we are using, "atomic builtins" indicates that we are NOT using APIs > > fro

Re: [dpdk-dev] [PATCH v2 0/8] use GCC's C11 atomic builtins for test

> > > > > > > > > > As I mentioned earlier in this thread, GCC supports 2 types of > > > > atomics. "Use GCC atomic builtins" does not help distinguish > > > > between them. In "GCC's C11 atomic builtins" - "C11" indicates > > > > which atomics we are using, "atomic builtins" indicates that we >

Re: [dpdk-dev] [PATCH] net/mlx5: remove unwanted barrier

(rte_smp_rmb()) which is less costly than the outer sharable domain (rte_io_rmb()). I will re-spin this patch. Thanks, Honnappa > -Original Message- > From: Slava Ovsiienko > Sent: Thursday, July 1, 2021 7:53 AM > To: Honnappa Nagarahalli ; > dev@dpdk.org; Matan Azrad

Re: [dpdk-dev] DTS improvement WG - Debate/triag inputs - Extending for next 5 weeks

Hi Lijuan, Sorry to hear that. Please take care, I will cancel the meeting for this week. Thanks, Honnappa From: Tu, Lijuan Sent: Sunday, July 4, 2021 11:59 PM To: Honnappa Nagarahalli ; Chen, Zhaoyan ; Buckley, Daniel M ; juraj.lin...@pantheon.tech; jer...@marvell.com

[dpdk-dev] Canceled: DTS improvement WG - Debate/triag inputs - Extending for next 5 weeks

Hello, We will continuing debating/triaging the inputs from [1]. As discussed, I am blocking the calendar for next 4 weeks. Thank you, Honnappa [1] https://docs.google.com/document/d/1c5S0_mZzFvzZfYkqyORLT2-qNvUb-fBdjA6DGusy4yM/edit#

Re: [dpdk-dev] atomic operations

> > In the deprecation notices of DPDK 21.05, we can still read this: > " > * rte_atomicNN_xxx: These APIs do not take memory order parameter. This > does > not allow for writing optimized code for all the CPU architectures supported > in DPDK. DPDK will adopt C11 atomic operations semantics

Re: [PATCH v3 4/4] eal: describe Arm CPU features including WFXT

n be simpler. “Add descriptive comments to each Arm feature listed in rte_cpu_flag_t" > > Signed-off-by: Wathsala Vithanage > Reviewed-by: Dhruv Tripathi Otherwise, looks good. Reviewed-by: Honnappa Nagarahalli > --- > lib/eal/arm/include/rte_cpuflags_64.h | 48 ++

Re: [PATCH v3 2/4] config/arm: adds Arm Neoverse N3 SoC

> On Jul 15, 2024, at 5:53 PM, Wathsala Vithanage > wrote: > > Add Arm Neoverse N3 part number to build configuration. > > Signed-off-by: Wathsala Vithanage > --- > config/arm/meson.build | 22 +- > 1 file changed, 21 insertions(+), 1 deletion(-) > > diff --git a/config/a

Re: [RFC v2] ethdev: an API for cache stashing hints

> On Jul 16, 2024, at 9:27 PM, Stephen Hemminger > wrote: > > On Mon, 15 Jul 2024 22:11:41 + > Wathsala Vithanage wrote: > >> An application provides cache stashing hints to the ethernet devices to >> improve memory access latencies from the CPU and the NIC. This patch >> introduces thre

Re: DTS WG Meeting Minutes - August 1, 2024

> On Aug 2, 2024, at 8:34 AM, Thomas Monjalon wrote: > > 01/08/2024 21:39, Patrick Robb: >> * Do we want to add DTS items to release notes? >> * What is the process for building the release notes? Should the >> people working on DTS aggregate the updates and submit them? Patrick >> Robbshould

RE: [PATCH v6] eal: allow worker lcore stacks to be allocated from hugepage memory

> > 21/06/2022 16:52, Don Wallwork: > > On 6/21/2022 10:42 AM, Thomas Monjalon wrote: > > > 21/06/2022 14:31, Don Wallwork: > > >> On 6/21/2022 6:37 AM, Thomas Monjalon wrote: > > >>> 20/06/2022 10:35, David Marchand: > > On Tue, May 24, 2022 at 9:52 PM Don Wallwork > wrote: > > > Add s

RE: [RFC PATCH v1] net/i40e: put mempool cache out of API

t; Performance Test with l3fwd neon path: > > with this patch > > n1sdp: no perforamnce change > > amper-altra:+4.0% > > > > Suggested-by: Konstantin Ananyev > > Suggested-by: Honnappa Nagarahalli > > Signed-off-by: Feif

RE: Service core statistics MT safety

> > > From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com] > > Sent: Monday, 27 June 2022 13.06 > > > > Hi. > > > > Is it safe to enable stats on MT safe services? > > > > https://github.com/DPDK/dpdk/blob/main/lib/eal/common/rte_service.c#L3 > > 6 > > 6 > > > > It seems to me this would

RE: Service core statistics MT safety

> >> > >>> From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com] > >>> Sent: Monday, 27 June 2022 13.06 > >>> > >>> Hi. > >>> > >>> Is it safe to enable stats on MT safe services? > >>> > >>> https://github.com/DPDK/dpdk/blob/main/lib/eal/common/rte_service.c# > >>> L3 > >>> 6 > >>> 6 > >>

RE: Service core statistics MT safety

> > > From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com] > > Sent: Monday, 27 June 2022 13.06 > > > > Hi. > > > > Is it safe to enable stats on MT safe services? > > > > https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af- > 4 > > 54

RE: Service core statistics MT safety

> >> > >>> From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com] > >>> Sent: Monday, 27 June 2022 13.06 > >>> > >>> Hi. > >>> > >>> Is it safe to enable stats on MT safe services? > >>> > >>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122- > 31

RE: Service core statistics MT safety

> > > From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com] > > Sent: Monday, 27 June 2022 13.06 > > > > Hi. > > > > Is it safe to enable stats on MT safe services? > > > > https://protect2.fireeye.com/v1/url?k=313233

RE: Service core statistics MT safety

> >> > >>> From: Mattias Rönnblom > >>> [mailto:mattias.ronnb...@ericsson.com] > >>> Sent: Monday, 27 June 2022 13.06 > >>> > >>> Hi. > >>> > >>> Is it safe to enable stats on MT safe services? > >>> > >>> https://prot

RE: Optimizations are not features

> > 04/06/2022 13:51, Andrew Rybchenko пишет: > > On 6/4/22 15:19, Morten Brørup wrote: > >>> From: Jerin Jacob [mailto:jerinjac...@gmail.com] > >>> Sent: Saturday, 4 June 2022 13.10 > >>> > >>> On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko > >>> wrote: > > On 6/4/22 12:33, Jerin Ja

RE: [PATCH v1 5/5] examples/l3fwd: enable direct rearm mode

(apologies for being late on replying, catching up after vacation) > >> > >> 25/05/2022 01:24, Honnappa Nagarahalli пишет: > >>> From: Konstantin Ananyev > >>> > >>> 20/04/2022 09:16, Feifei Wang пишет: > >>>>

RE: [PATCH v1 0/5] Direct re-arming of buffers on receive side

> > >>> > > > > [konstantin.v.anan...@yandex.ru appears similar to someone who > > previously sent you email, but may not be that person. Learn why > > this > > could be a risk at > > https://aka.ms/LearnAboutSenderIdentification.] > > > > 16/05/2022 07:10, Feif

RE: Service core statistics MT safety

> > > > > > At the time of the read operation (in the global counter solution), > > > there may well be cycles consumed or calls having been made, but not > > > yet posted. The window between call having been made, and global > > > counter having been incremented (and thus made globally visible

RE: [PATCH v1 0/5] Direct re-arming of buffers on receive side

> > > > > > > > 16/05/2022 07:10, Feifei Wang пишет: > > > > > > > > > >>> Currently, the transmit side frees the buffers into the > > lcore > > > > >>> cache and the receive side allocates buffers from the > > > > >>> lcore > > > > cache. > > > > >>> The transmit si

DTS WG discussions

the meeting for another quarter.\n\n\n\nHello\,\n\ nThis is the timeslot for the DTS WG meetings. Please feel free to join.\n\n\n\nThank you\,\n\nHonnappa\n\n\n Honnappa Nagarahalli i s inviting you to a scheduled Zoom meeting.\n\nJoin Zoom Meeting\nhttps:// armltd.zoom.us/j

RE: Service core statistics MT safety

> > > > > In my mind, any LTS/backports get the simplest/highest-confidence > > > bugfix: using > > > > atomics. > > > > The atomics are behind the "service stats" feature enable, so > > > > impact > > > is only > > > > when those are enabled. > > > > > > > > If there is still a performance hit,

RE: [PATCH 2/2] service: fix potential stats race-condition on MT services

s when not required. > > This patch causes a 1.25x increase in cycle-cost for polling a MT safe service > when statistics are enabled. No change was seen for MT unsafe services, or > when statistics are disabled. > > Reported-by: Mattias Rönnblom > Suggested-by: Honnappa Na

RE: [PATCH 2/2] service: fix potential stats race-condition on MT services

> > > > > > > > diff --git a/lib/eal/common/rte_service.c > > > > b/lib/eal/common/rte_service.c index ef31b1f63c..f045e74ef3 100644 > > > > --- a/lib/eal/common/rte_service.c > > > > +++ b/lib/eal/common/rte_service.c > > > > @@ -363,9 +363,15 @@ service_runner_do_callback(struct > > > > rte_serv

RE: [PATCH 2/2] service: fix potential stats race-condition on MT services

service > > > when statistics are enabled. No change was seen for MT unsafe > > services, or > > > when statistics are disabled. > > > > > > Reported-by: Mattias Rönnblom > > > Suggested-by: Honnappa Nagarahalli > > > Suggested-by: Mort

RE: [PATCH 2/2] service: fix potential stats race-condition on MT services

is used to avoid > > executing > > > > atomic > > > > > add instructions when not required. > > > > > > > > > > This patch causes a 1.25x increase in cycle-cost for polling a > > > > > MT > > > &g

RE: clarification on RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF flag

> On Wed, 6 Jul 2022 19:07:54 +0530 > venkatesh bs wrote: > > > Hi All, > > > > In multithreaded/Multicore environment can we use > > RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF > > independently, This flag is about reader-writer concurrency (not writer-writer concurrency). Reader-writer concurren

RE: [RFC] rwlock: prevent readers from starving writers

> > The original reader/writer lock in DPDK can cause a stream of readers to > starve writers. > > The new version uses an additional bit to indicate that a writer is waiting > and > which keeps readers from starving the writer. This addition makes sense. I am wondering if we should create a ne

RE: [RFC PATCH v1] net/i40e: put mempool cache out of API

> > > > Refer to "i40e_tx_free_bufs_avx512", this patch puts mempool cache out > > of API to free buffers directly. There are two changes different with > > previous version: > > 1. change txep from "i40e_entry" to "i40e_vec_entry" > > 2. put cache out of "mempool_bulk" API to copy buffers into

[dpdk-dev] Minutes of Technical Board Meeting, 2021-03-10

Minutes of Technical Board Meeting, 2021-03-10 Members Attending: - Aaron Conole - Bruce Richardson - Ferruh Yigit - Hemant Agrawal - Honnappa Nagarahalli (Chair) - Jerin Jacob - Kevin Traynor - Konstantin Ananyev - Maxime Coquelin - Olivier Matz - Stephen

Re: [dpdk-dev] [PATCH v4] pflock: add phase-fair reader writer locks

Few minor comments, overall looks good. Tested on few Arm platforms. > > This is a new type of reader-writer lock that provides better fairness > guarantees which better suited for typical DPDK applications. > A pflock has two ticket pools, one for readers and one for writers. > > Phase fair r

Re: [dpdk-dev] L3fwd mode in testpmd

> > > > > > > > > > > > On Thu, Mar 11, 2021 at 12:01 AM Honnappa Nagarahalli > > > > > > wrote: > > > > > > > > > > > > > > Hello, > > > > > > > Performance of L3fwd

Re: [dpdk-dev] [PATCH] config/arm: add support for Marvell CN10K

> Subject: Re: [dpdk-dev] [PATCH] config/arm: add support for Marvell CN10K > > On Wed, Mar 31, 2021 at 10:53 PM Nithin Dabilpuram > wrote: > > > > From: Pavan Nikhilesh > > > > Add config support to cross compile for Marvell CN10K SoC. > > Marvell CN10K SoC is based on ARM Neoverse N2 cores.

Re: [dpdk-dev] [PATCH] config/arm: add support for Marvell CN10K

> > > > Subject: Re: [dpdk-dev] [PATCH] config/arm: add support for > > > > Marvell CN10K > > > > > > > > On Wed, Mar 31, 2021 at 10:53 PM Nithin Dabilpuram > > > > wrote: > > > > > > > > > > From: Pavan Nikhilesh > > > > > > > > > > Add config support to cross compile for Marvell CN10K SoC. >

Re: [dpdk-dev] [PATCH v2] eal: fix race in ctrl thread creation

> > As reported by Luc, there is a race where the barrier is destroyed by one > thread, while the other thread did not yet leave pthread_barrier_wait. Please correct me if I am wrong. We are using the pthread_barrier to 1) know when to free 'params'. 2) set the thread affinity before the thread

Re: [dpdk-dev] [Linuxarm] [PATCH V2 0/4] add Hisilicon kunpeng CPU support

> > 在 2021/3/25 22:40, Thomas Monjalon 写道: > > 25/03/2021 14:26, oulijun: > >> 在 2021/3/25 20:19, Thomas Monjalon 写道: > >>> 25/03/2021 12:17, oulijun: > Ruifeng has reviewed-by. Does anyone else have any comments? Is it > necessary to send the V2? > >>> > >>> v2 for what? There is a ch

Re: [dpdk-dev] [PATCH v3] eal: fix race in ctrl thread creation

> > The creation of control threads used a pthread barrier for synchronization. > This patch fixes a race condition where the pthread barrier could get > destroyed while one of the threads has not yet returned from the > pthread_barrier_wait function, which could result in undefined behaviour. >

Re: [dpdk-dev] [PATCH v5] pflock: implementation of phase-fair reader writer locks

s09b.pdf > > Signed-off-by: Stephen Hemminger Looks good. Acked-by: Honnappa Nagarahalli One question below > --- > v5 - cleanup typos in the lock code comments > minor revision to unit test. > Note: the unit test is intentionally the same as other locking

Re: [dpdk-dev] [PATCH v5] pflock: implementation of phase-fair reader writer locks

> Subject: Re: [PATCH v5] pflock: implementation of phase-fair reader writer > locks > > On Tue, 6 Apr 2021 21:56:05 +0000 > Honnappa Nagarahalli wrote: > > > How does the autotest script does this? > > This was copy-paste from original. Think the original w

Re: [dpdk-dev] Minutes of Technical Board Meeting, 2021-03-10

> > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Tom Barbette > > Sent: Wednesday, March 31, 2021 10:53 AM > > > > Le 31-03-21 à 02:44, Honnappa Nagarahalli a écrit : > > > - Ability to tune the values of #defines > > > * Few prominen

Re: [dpdk-dev] [Linuxarm] [PATCH V2 0/4] add Hisilicon kunpeng CPU support

> >> > >> 在 2021/3/25 22:40, Thomas Monjalon 写道: > >>> 25/03/2021 14:26, oulijun: > 在 2021/3/25 20:19, Thomas Monjalon 写道: > > 25/03/2021 12:17, oulijun: > >> Ruifeng has reviewed-by. Does anyone else have any comments? Is > >> it necessary to send the V2? > > > > v2 for

Re: [dpdk-dev] [PATCH v5] eal: fix race in ctrl thread creation

> > Hi Luc, > > On Wed, Apr 07, 2021 at 08:53:23AM -0400, Luc Pelletier wrote: > > The creation of control threads uses a pthread barrier for > > synchronization. This patch fixes a race condition where the pthread > > barrier could get destroyed while one of the threads has not yet > > returne

Re: [dpdk-dev] [PATCH v7] eal: fix race in ctrl thread creation

> Subject: [PATCH v7] eal: fix race in ctrl thread creation > > The creation of control threads uses a pthread barrier for synchronization. > This patch fixes a race condition where the pthread barrier could get > destroyed while one of the threads has not yet returned from the > pthread_barrier

Re: [dpdk-dev] [PATCH 1/2] eal: fix race in ctrl thread creation

fined behaviour. > > Fixes: 3a0d465 ("eal: fix use-after-free on control thread creation") > Cc: jianfeng@intel.com > Cc: sta...@dpdk.org > > Signed-off-by: Luc Pelletier Looks good. Reviewed-by: Honnappa Nagarahalli

Re: [dpdk-dev] [PATCH 2/2] eal: fix hang in ctrl thread creation error logic

nd.com > Cc: sta...@dpdk.org > > Signed-off-by: Luc Pelletier Looks good. Reviewed-by: Honnappa Nagarahalli > --- >

Re: [dpdk-dev] [PATCH v19 0/3] Arm build options rework

> > > It seems that our SoC configuration patches are block by this series： > https://patchwork.dpdk.org/project/dpdk/list/?series=15918 Thank you and appreciate your help. Appreciate updating your patch according to this series. > > I reworked our configuration based on this series and then t

[dpdk-dev] DTS improvement workgroup

Hello, I am trying to setup a workgroup to improve DTS. The intention is make it easy for the development community to add test cases while developing new features. There are already few ideas captured in [1]. Few of us (in the CC list) are meeting on 13th April, 8AM to 9AM CST (1:00PM t

Re: [dpdk-dev] DTS improvement workgroup

Ok, will send out a meeting notice. I missed the reference in the earlier mail. Here is the reference. [1] https://docs.google.com/document/d/1c5S0_mZzFvzZfYkqyORLT2-qNvUb-fBdjA6DGusy4yM/edit# From: Jerin Jacob Kollanukkaran Sent: Monday, April 12, 2021 12:34 PM To: Honnappa Nagarahalli ; dev

[dpdk-dev] DTS improvement workgroup meeting

Hello, I am trying to setup a workgroup to improve DTS. The intention is make it easy for the development community to add test cases while developing new features. Suggestion for the agenda items: 1) Agree upon the goal for the working group 2) Discuss timelines 3) Next steps (any recur

Re: [dpdk-dev] [PATCH 1/4] examples/l3fwd: tune prefetch for better performance

er status and > > reduce cache maintenance overhead. > > The code does read the cache line too. Right? > > > > > With this change, 12.9% performance uplift was measured on N1SDP > > platform with MLX5 NIC. > > > > Suggested-by: Honnappa Nagarahalli

[dpdk-dev] DTS improvement working group - MoM

Hello, Thanks to many of you for attending the meeting today. Following are the MoM. Attendees: Aaron Conole Ajit Khaparde Ali Alnubani Bruce Richardson David Liu Honnappa Nagarahalli Jerin Jacob Kollanukkaran John McNamara Juraj Linkes Konstantin Ananyev Lijuan Tu Lincoln Lavoie Owen

[dpdk-dev] DTS improvement WG - Debate/triag inputs

Hello, As agreed in the meeting, this is the meeting for debating/triaging the inputs from [1]. It would be helpful if everyone can review and come prepared for the meeting. Thank you, Honnappa [1] https://docs.google.com/document/d/1c5S0_mZzFvzZfYkqyORLT2-qNvUb-fBdjA6DGusy4yM/edit#

  1   2   3   4   5   6   7   8   9   10   >