RE: [External] RE: [PATCH] net/cksum: compute raw cksum for several segments

> -Original Message- > From: Su Sai > Sent: Thursday 31 July 2025 12:32 > To: Marat Khalili ; jasvinder.si...@intel.com > Cc: dev@dpdk.org > Subject: Re: [External] RE: [PATCH] net/cksum: compute raw cksum for several > segments > > Hi Marat Khalili, > >

Re: [External] RE: [PATCH] net/cksum: compute raw cksum for several segments

Hi Marat Khalili, Thanks for your comments. We found small TCP checksum errors pkts online, then were traced to issues within the rte_raw_cksum_mbuf function. This error can be reproduced as follows: 1. In the client ECS with an MTU of 1500, initiate traffic using the command "iperf3 -c {dst ip}

RE: [EXTERNAL] Re: [PATCH v0 1/1] doc: announce inter-device DMA capability support in dmadev

Gentle reminder to share your feedback. >Hi Bruce, Vladimir, Anatoly > >Regarding inter-device or inter-domain DMA capability, could please clarify if >Intel idxd driver will support this feature. >I believe the changes Feng has suggested here are in line with the earlier >"[PATCH v1 0/3] Add supp

RE: [EXTERNAL] Re: [PATCH v2 1/2] ethdev: remove unnecessary type conversion

Hi Stephen, I will take care of it and resubmit. Thanks Sunil Kumar Kori From: Stephen Hemminger Sent: Tuesday, July 29, 2025 9:59 AM To: Sunil Kumar Kori Cc: Shepard Siegel ; Ed Czeck ; John Miller ; Igor Russkikh ; Ajit Khaparde ; Somnath Kotur ; Nithin Kumar Dabilpuram ; Kiran Kumar Kok

RE: [EXTERNAL] Re: [PATCH v0 1/1] doc: announce inter-device DMA capability support in dmadev

Hi Bruce, Vladimir, Anatoly Regarding inter-device or inter-domain DMA capability, could please clarify if Intel idxd driver will support this feature. I believe the changes Feng has suggested here are in line with the earlier "[PATCH v1 0/3] Add support for inter-domain DMA operations" proposal

RE: [EXTERNAL] Re: [PATCH v0 1/1] doc: announce inter-device DMA capability support in dmadev

> >ZjQcmQRYFpfptBannerEnd >On 2025/7/16 18:59, Vamsi Krishna Attunuru wrote: >> >>> >>> Thanks for the explanation. >>> >>> Let me tell you what I understand: >>> 1\ Two dmadev (must belong to the same DMA controller?) each >>> passthrough to diffent domain (VM or container) 2\ The kernel DMA >>> c

Re: [EXTERNAL] Re: [PATCH v0 1/1] doc: announce inter-device DMA capability support in dmadev

On 2025/7/16 18:59, Vamsi Krishna Attunuru wrote: > >> >> Thanks for the explanation. >> >> Let me tell you what I understand: >> 1\ Two dmadev (must belong to the same DMA controller?) each passthrough >> to diffent domain (VM or container) 2\ The kernel DMA controller driver could >> config acce

RE: [EXTERNAL] Re: [PATCH v0 1/1] doc: announce inter-device DMA capability support in dmadev

> >Thanks for the explanation. > >Let me tell you what I understand: >1\ Two dmadev (must belong to the same DMA controller?) each passthrough >to diffent domain (VM or container) 2\ The kernel DMA controller driver could >config access groups --- there is a secure mechanism (like Intel IDPTE) >

RE: [EXTERNAL] Re: [PATCH v4] doc: announce changes to dma device structures

>ZjQcmQRYFpfptBannerEnd >On Wed, Jul 31, 2024 at 06:06:33PM +0200, Thomas Monjalon wrote: >> 31/07/2024 13:01, Thomas Monjalon: >> > 30/07/2024 19:27, Jerin Jacob: >> > > On Tue, Jul 30, 2024 at 8:25 PM Amit Prakash Shukla >> > > wrote: >> > > > >> > > > A new flag RTE_DMA_CAPA_QOS will be introdu

Re: [EXTERNAL] Re: [PATCH v0 1/1] doc: announce inter-device DMA capability support in dmadev

Hi Vamsi, Thanks for the explanation. Let me tell you what I understand: 1\ Two dmadev (must belong to the same DMA controller?) each passthrough to diffent domain (VM or container) 2\ The kernel DMA controller driver could config access groups --- there is a secure mechanism (like Intel IDPTE)

RE: [EXTERNAL] Re: [PATCH v0 1/1] doc: announce inter-device DMA capability support in dmadev

Hi Feng, Thanks for depicting the feature use case. From the application’s perspective, inter VM/process communication is required to exchange the src & dst buffer details, however the specifics of this communication mechanism are outside the scope in this context. Regarding the address transl

RE: [EXTERNAL] Re: [PATCH v0 1/1] doc: announce inter-device DMA capability support in dmadev

Hi Vladimir, Currently, mem-to-mem dma transfers happen within a single process address space. This feature aims to extend support for transfers across multiple process address spaces to meet the requirements of inter-process or inter-VM networking. In environments where share memory is not fea

RE: [EXTERNAL] Re: [PATCH v2 1/1] ethdev: add support to provide link type

> On Fri, 6 Jun 2025 11:54:52 +0200 > Morten Brørup wrote: > > > > From: sk...@marvell.com [mailto:sk...@marvell.com] > > > Sent: Friday, 6 June 2025 11.28 > > > > > > From: Sunil Kumar Kori > > > > > > Adding link type parameter to provide the type of port like twisted > > > pair, fibre etc. >

RE: [EXTERNAL] Re: [PATCH v2 1/1] ethdev: add support to provide link type

> From: Sunil Kumar Kori [mailto:sk...@marvell.com] > Sent: Tuesday, 10 June 2025 07.02 > > > On Fri, 6 Jun 2025 11:54:52 +0200 > > Morten Brørup wrote: > > > > > > From: sk...@marvell.com [mailto:sk...@marvell.com] > > > > Sent: Friday, 6 June 2025 11.28 > > > > > > > > From: Sunil Kumar Kori >

Re: [EXTERNAL] Re: [25.11 PATCH v3 0/5] Introduce DMA enqueue/dequeue operations

Hi Bruce, >On Sat, May 24, 2025 at 02:43:10PM +0530, pbhagavat...@marvell.com wrote: >> From: Pavan Nikhilesh >> >> Introduce DMA enqueue/dequeue operations to the DMA device library. >> >> Add configuration flags to rte_dma_config instead of boolean for >> individual features. >> >> The enqueue

Re: [EXTERNAL] Re: |FAILURE| pw153190 [PATCH V3] Add new tracepoint function for type time_t

Sent: Thursday, May 8, 2025 7:24 PM To: Changqing Li; David Marchand ; Sunil Kumar Kori; tho...@monjalon.net; Stephen Hemminger Cc:dev@dpdk.org Subject: RE: [EXTERNAL] Re: |FAILURE| pw153190 [PATCH V3] Add new tracepoint function for type time_t I'm new to this project, and ha

RE: [EXTERNAL] Re: |FAILURE| pw153190 [PATCH V3] Add new tracepoint function for type time_t

mminger > Cc: dev@dpdk.org > Subject: RE: [EXTERNAL] Re: |FAILURE| pw153190 [PATCH V3] Add new tracepoint > function for type time_t > > > I'm new to this project, and have no clue about the failure, > > could > > experts at this project provide >

RE: [EXTERNAL] Re: [PATCH v5 1/1] examples/l2fwd-jobstats: fix lock availability

2024 12:43 PM > To: Stephen Hemminger > Cc: ferruh.yi...@amd.com; andrew.rybche...@oktetlabs.ru; > or...@nvidia.com; tho...@monjalon.net; dev@dpdk.org; Jerin Jacob > ; Nithin Kumar Dabilpuram > ; sta...@dpdk.org > Subject: RE: [EXTERNAL] Re: [PATCH v5 1/1] examples/l2fw

RE: [EXTERNAL] Re: [PATCH 2/5] net/qede: fix bad sanity check on Rx queue release

> -Original Message- > From: Stephen Hemminger > Sent: Wednesday, April 23, 2025 9: 01 PM > To: edwin. brossette@ 6wind. com > Cc: dev@ dpdk. org; olivier. matz@ 6wind. com; didier. pallard@ 6wind. com; ZjQcmQRYFpfptBannerStart Prioritize security for external em

RE: [EXTERNAL] Re: [v5,1/9] crypto/zsda: add skeleton

> Hi akhil: > > There is a critical warning, maybe can called error, that the patches can't be > applied. > > Because I formatted some files in patch "[v1] compress/zsda: code formatting", > whose link is > https://patches.dpdk.org/project/dpdk/patch/20250522062351.2266776-1- > li.hanx...@zte.com

RE: [EXTERNAL] Re: [PATCH v2 1/2] net: fix offset calculation for GENEVE packet

> > diff --git a/lib/net/rte_net.c b/lib/net/rte_net.c index > > be24690fdf..1264f33d61 100644 > > --- a/lib/net/rte_net.c > > +++ b/lib/net/rte_net.c > > @@ -251,7 +251,8 @@ ptype_tunnel_with_udp(uint16_t *proto, const struct > rte_mbuf *m, > > if (unlikely(gnh == NULL)) > >

RE: [EXTERNAL] Re: [dpdk-dev v1] app/test-crypto-perf: remove decrypt test case from perf

> On 02-May-25 11:12 AM, Kai Ji wrote: > > > Remove all decrypt test cases in aesni-mb throughput perf as the > decrypt throughput testing only support OOP by dpdk-test-crypto-perf > > Signed-off-by: Kai Ji > --- > > Acked-by: Radu Nicolau App

RE: [EXTERNAL] Re: [PATCH v6 1/2] ethdev: support RSS based on RoCEv2 header

From: Stephen Hemminger Sent: Tuesday, May 20, 2025 8:47 PM To: Kiran Kumar Kokkilagadda Cc: Aman Singh ; Thomas Monjalon ; Ferruh Yigit ; Andrew Rybchenko ; dev@dpdk.org Subject: [EXTERNAL] Re: [PATCH v6 1/2] ethdev: support RSS based on RoCEv2 header On Mon, 5 May 2025 11: 27: 15 +0530 w

RE: [EXTERNAL] Re: [PATCH 2/2] app/testpmd: clear stale internal len information

> On Mon, 19 May 2025 21:36:56 +0530 > wrote: > > > From: Sunil Kumar Kori > > > > hdr_lens is used to maintain header lengths after parsing packets. > > When port receives different type of packets (say first is VXLAN > > packet and second is GRE packet). > > > > For first packet, L2/L3/L4 leng

RE: [EXTERNAL] Re: [PATCH 1/2] net: fix offset calculation for GENEVE packet

> -Original Message- > From: Stephen Hemminger > Sent: Wednesday, May 21, 2025 2:52 AM > To: Sunil Kumar Kori > Cc: Jie Hai ; dev@dpdk.org > Subject: [EXTERNAL] Re: [PATCH 1/2] net: fix offset calculation for GENEVE > packet > > On Mon, 19 May 2025 21: 36: 55 +0530 wrote: > From: > Sun

Re: [External] Re: [PATCH] mlx5: fix race at mlx5_dev_close

It's 1ms, not 1 second.  It's a workaround, just to provide a fast and dirty fix for someone who needs this. From: "Stephen Hemminger" > Date:  Tue, Oct 8, 2024, 01:54 > Subject:  [External] Re: [PATCH] mlx5: fix race at mlx5_dev_close > To: "hepeng" > Cc: > On Thu, 11 Apr 2024 14:17:40 +0800 

RE: [EXTERNAL] Re: |FAILURE| pw153190 [PATCH V3] Add new tracepoint function for type time_t

> I'm new to this project, and have no clue about the failure, > could experts at this project provide > > some help about the following failure? > > + sudo babeltrace > /home/runner/work/dpdk/dpdk/build/app/test/suites/rte-2025-04-30-AM-02- > 25-21 > >

RE: [EXTERNAL] Re: [25.11 PATCH 1/3] dmadev: add enqueue dequeue operations

Hi Fengchengwen, > Hi Pavan, > > On 2025/4/16 18:09, pbhagavat...@marvell.com wrote: > > From: Pavan Nikhilesh > > > > Add enqueue/dequeue operations that use struct rte_dma_op > > to communicate with the dma device. > > These operations need to be enabled at dma device configuration > > time b

RE: [EXTERNAL] Re: [PATCH v1 04/12] node: add process callback for IP4 FIB

Hi Vladimir, >Hi Ankur, > >пт, 18 апр. 2025 г. в 15:45, Ankur Dwivedi >: > > > > Hi Vladimir, > >> diff --git a/lib/node/ip4_lookup_fib.c b/lib/node/ip4_lookup_fib.c > >> index e87864e672..c535b191f8 100644 > >> --- a/lib/node/ip4_lookup_fib.

Re: [EXTERNAL] Re: [PATCH v1 04/12] node: add process callback for IP4 FIB

Hi Ankur, пт, 18 апр. 2025 г. в 15:45, Ankur Dwivedi : > > Hi Vladimir, > >> diff --git a/lib/node/ip4_lookup_fib.c b/lib/node/ip4_lookup_fib.c > >> index e87864e672..c535b191f8 100644 > >> --- a/lib/node/ip4_lookup_fib.c > >> +++ b/lib/node/ip4_lookup_fib.c > >> @@ -40,6 +40,169 @@ static struct

RE: [EXTERNAL] Re: [PATCH v1 04/12] node: add process callback for IP4 FIB

Hi Vladimir, >> diff --git a/lib/node/ip4_lookup_fib.c b/lib/node/ip4_lookup_fib.c >> index e87864e672..c535b191f8 100644 >> --- a/lib/node/ip4_lookup_fib.c >> +++ b/lib/node/ip4_lookup_fib.c >> @@ -40,6 +40,169 @@ static struct ip4_lookup_fib_node_main >ip4_lookup_fib_nm; >> #define IP4_LOOKUP_

RE: [EXTERNAL] Re: [Patch v3 6/6] bus/vmbus: set event for channel without monitoring support

> Subject: RE: [EXTERNAL] Re: [Patch v3 6/6] bus/vmbus: set event for channel > without monitoring support > > > Subject: [EXTERNAL] Re: [Patch v3 6/6] bus/vmbus: set event for > > channel without monitoring support > > > > On Fri, 4 Apr 2025 17:35:38 -0700 &

RE: [EXTERNAL] Re: [PATCH v1 02/12] node: add IP4 lookup FIB node

Hi Nitin, >> lib/node/ip4_lookup_fib.c | 127 >++ >> lib/node/meson.build | 3 +- >> 2 files changed, 129 insertions(+), 1 deletion(-) create mode 100644 >> lib/node/ip4_lookup_fib.c >> >> diff --git a/lib/node/ip4_lookup_fib.c b/lib/node/ip4_lookup_fib.

RE: [EXTERNAL] Re: [PATCH v1 02/12] node: add IP4 lookup FIB node

Hi Vladimir, >On 15/04/2025 13:10, Ankur Dwivedi wrote: >> Adds a lookup FIB node for IP4. >> >> Signed-off-by: Ankur Dwivedi >> --- >> lib/node/ip4_lookup_fib.c | 127 >++ >> lib/node/meson.build | 3 +- >> 2 files changed, 129 insertions(+), 1 delet

RE: [EXTERNAL] Re: [Patch v3 6/6] bus/vmbus: set event for channel without monitoring support

> Subject: [EXTERNAL] Re: [Patch v3 6/6] bus/vmbus: set event for channel > without > monitoring support > > On Fri, 4 Apr 2025 17:35:38 -0700 > lon...@linuxonhyperv.com wrote: > > > diff --git a/drivers/bus/vmbus/vmbus_channel.c > > b/drivers/bus/vmbus/vmbus_channel.c > > index bccef168d3..81e

RE: [EXTERNAL] Re: [patch v4 6/6] bus/vmbus: set event for channel without monitoring support

> Subject: [EXTERNAL] Re: [patch v4 6/6] bus/vmbus: set event for channel > without > monitoring support > > On Mon, 7 Apr 2025 15:45:04 -0700 > lon...@linuxonhyperv.com wrote: > > > From: Long Li > > > > For vmbus channels without monitoring support, use kernel UIO > > interface to indicate p

RE: [EXTERNAL] Re: [Patch v3 6/6] bus/vmbus: set event for channel without monitoring support

> Subject: [EXTERNAL] Re: [Patch v3 6/6] bus/vmbus: set event for channel > without > monitoring support > > On Fri, 4 Apr 2025 17:35:38 -0700 > lon...@linuxonhyperv.com wrote: > > > diff --git a/drivers/bus/vmbus/vmbus_channel.c > > b/drivers/bus/vmbus/vmbus_channel.c > > index bccef168d3..81e

Re: [EXTERNAL] Re: [PATCH 1/2] node: add global node mbuf dynfield

Hi Stephen, Thanks, Nitin On Fri, Apr 4, 2025 at 8:51 PM Stephen Hemminger wrote: > > On Fri, 4 Apr 2025 08:11:07 + > Pavan Nikhilesh Bhagavatula wrote: > > > > Hi Stephen, > > > > > > Thanks for commenting. See response inline. > > > > > > Regards, > > > Nitin > > > > > > On Tue, Apr 1, 20

Re: [External] Re: [PATCH] eal: prevent socket closure before MP sync

On 2025/3/27 17:28, Yang Ming wrote: On 2025/3/17 21:56, Stephen Hemminger wrote: Caution: This is an external email. Please be very careful when clicking links or opening attachments. See http://nok.it/nsb for additional information. On Fri, 14 Mar 2025 18:36:38 +0800 Yang Ming wrote:

Re: [EXTERNAL] Re: [PATCH 1/2] node: add global node mbuf dynfield

On Fri, 4 Apr 2025 08:11:07 + Pavan Nikhilesh Bhagavatula wrote: > > Hi Stephen, > > > > Thanks for commenting. See response inline. > > > > Regards, > > Nitin > > > > On Tue, Apr 1, 2025 at 7:45 PM Stephen Hemminger > > wrote: > > > > > > On Tue, 1 Apr 2025 09:50:46 +0530 > > > Nitin S

RE: [EXTERNAL] Re: [PATCH 1/2] node: add global node mbuf dynfield

> Hi Stephen, > > Thanks for commenting. See response inline. > > Regards, > Nitin > > On Tue, Apr 1, 2025 at 7:45 PM Stephen Hemminger > wrote: > > > > On Tue, 1 Apr 2025 09:50:46 +0530 > > Nitin Saxena wrote: > > > > > +int rte_node_mbuf_dynfield_register(void) > > > +{ > > > + struct no

Re: [External] Re: [PATCH v2] eal/linux: improve ASLR check

On 2025/3/27 16:14, David Marchand wrote: Caution: This is an external email. Please be very careful when clicking links or opening attachments. See http://nok.it/nsb for additional information. Hello, On Thu, Mar 27, 2025 at 9:02 AM Yang Ming wrote: On 2025/3/13 23:37, Stephen Hemminger w

Re: [External] Re: [PATCH v2] eal/linux: improve ASLR check

On 2025/3/13 23:37, Stephen Hemminger wrote: Caution: This is an external email. Please be very careful when clicking links or opening attachments. See http://nok.it/nsb for additional information. On Thu, 13 Mar 2025 14:19:03 +0800 Yang Ming wrote: This change ensures that the current pro

Re: [External] Re: [PATCH] eal: prevent socket closure before MP sync

On 2025/3/17 21:56, Stephen Hemminger wrote: Caution: This is an external email. Please be very careful when clicking links or opening attachments. See http://nok.it/nsb for additional information. On Fri, 14 Mar 2025 18:36:38 +0800 Yang Ming wrote: The secordary process should not close s

Re: [External] Re: [PATCH v2] eal/linux: improve ASLR check

Hello, On Thu, Mar 27, 2025 at 9:02 AM Yang Ming wrote: > On 2025/3/13 23:37, Stephen Hemminger wrote: > > On Thu, 13 Mar 2025 14:19:03 +0800 > > Yang Ming wrote: > > > >> This change ensures that the current process is checked for > >> being run with 'setarch' before verifying the value of > >>

Re: [EXTERNAL] Re: [RFC 2/2] eventdev: add default software vector adapter

On Wed, 26 Mar 2025 17:25:32 + Pavan Nikhilesh Bhagavatula wrote: > > On Wed, 26 Mar 2025 18:44:36 +0530 > > wrote: > > > > > +struct sw_vector_adapter_service_data { > > > + uint32_t service_id; > > > + RTE_ATOMIC(rte_mcslock_t *) lock; > > > + RTE_TAILQ_HEAD(, sw_vector_adapter_data) ad

RE: [EXTERNAL] Re: [patch v2 0/6] Support VMBUS channels without monitoring enabled

> Subject: Re: [EXTERNAL] Re: [patch v2 0/6] Support VMBUS channels without > monitoring enabled > > On Wed, 12 Mar 2025 00:33:52 + > Long Li wrote: > > > > Subject: [EXTERNAL] Re: [patch v2 0/6] Support VMBUS channels > > > without monitoring enabled &

RE: [EXTERNAL] Re: [RFC 2/2] eventdev: add default software vector adapter

> On Wed, 26 Mar 2025 18:44:36 +0530 > wrote: > > > +struct sw_vector_adapter_service_data { > > + uint32_t service_id; > > + RTE_ATOMIC(rte_mcslock_t *) lock; > > + RTE_TAILQ_HEAD(, sw_vector_adapter_data) adapter_list; > > +}; > > Why the indirect pointer to the lock? rather than embeddi

Re: [External] Re: [PATCH 2/2] net/mlx5: improve log file path

rom: Yang Ming >> Sent: Wednesday, March 12, 2025 10:33 AM >> To: Stephen Hemminger ; Bing Zhao >> >> Cc: Dariusz Sosnowski ; Slava Ovsiienko >> ; Ori Kam ; Suanming Mou >> ; Matan Azrad ; dev@dpdk.org >> Subject: Re: [External] Re: [PATCH 2/2] net/ml

RE: [EXTERNAL] Re: [Patch v2] doc: announce bus/vmbus API changes

> -Original Message- > From: David Marchand > Sent: Monday, March 17, 2025 2:47 AM > To: lon...@linuxonhyperv.com > Cc: Stephen Hemminger ; Wei Hu > ; Thomas Monjalon ; > dev@dpdk.org; Long Li > Subject: [EXTERNAL] Re: [Patch v2] doc: announce bus/vmbus API changes > > On Sat, Mar 15,

RE: [External] Re: [PATCH 2/2] net/mlx5: improve log file path

Hi Ming & Stephen, > -Original Message- > From: Yang Ming > Sent: Wednesday, March 12, 2025 10:33 AM > To: Stephen Hemminger ; Bing Zhao > > Cc: Dariusz Sosnowski ; Slava Ovsiienko > ; Ori Kam ; Suanming Mou > ; Matan Azrad ; dev@dpdk.org > Subject: Re:

RE: [EXTERNAL] Re: [PATCH] doc: announce bus/vmbus API changes

> Subject: [EXTERNAL] Re: [PATCH] doc: announce bus/vmbus API changes > > 12/03/2025 22:43, lon...@linuxonhyperv.com: > > From: Long Li > > > > All vmbus APIs are used internally by DPDK core and net/netvsc PMD. > > It's not feasible or practical to use those APIs by the application. > > Those AP

Re: [External] Re: [PATCH] eal/linux: enhance ASLR verification

On 2025/3/13 00:29, Stephen Hemminger wrote: Caution: This is an external email. Please be very careful when clicking links or opening attachments. See http://nok.it/nsb for additional information. On Wed, 12 Mar 2025 11:13:27 +0800 Yang Ming wrote: On 2025/3/11 05:43, Stephen Hemminger wr

RE: [EXTERNAL] Re: [patch v2 0/6] Support VMBUS channels without monitoring enabled

> Can't take it as is, here are some options: > > 1. Version the API even though should only be used internally. Use API > versioning >as transistion until 25.11. > 2. Wait for 25.11 and just fix it now, and do deprecation notice now. > > 3. Mark the API's as internal (in 25.11) and do depre

Re: [EXTERNAL] Re: [patch v2 0/6] Support VMBUS channels without monitoring enabled

On Wed, 12 Mar 2025 00:33:52 + Long Li wrote: > > Subject: [EXTERNAL] Re: [patch v2 0/6] Support VMBUS channels without > > monitoring enabled > > > > On Mon, 10 Mar 2025 14:42:51 -0700 > > lon...@linuxonhyperv.com wrote: > > > > > From: Long Li > > > > > > Hyperv may expose VMBUS channe

Re: [External] Re: [PATCH 2/2] net/mlx5: improve log file path

On 2025/3/10 22:59, Stephen Hemminger wrote: Caution: This is an external email. Please be very careful when clicking links or opening attachments. See http://nok.it/nsb for additional information. On Tue, 4 Mar 2025 06:23:06 + Bing Zhao wrote: Hi Ming, -Original Message- Fro

RE: [EXTERNAL] Re: [patch v2 0/6] Support VMBUS channels without monitoring enabled

> Subject: [EXTERNAL] Re: [patch v2 0/6] Support VMBUS channels without > monitoring enabled > > On Mon, 10 Mar 2025 14:42:51 -0700 > lon...@linuxonhyperv.com wrote: > > > From: Long Li > > > > Hyperv may expose VMBUS channels without monitoring enabled. In this > > case, it programs almost all

RE: [EXTERNAL] Re: [PATCH 6/6] bus/vmbus: set event for channel without monitoring support

> Subject: [EXTERNAL] Re: [PATCH 6/6] bus/vmbus: set event for channel > without monitoring support > > On Thu, 27 Feb 2025 17:09:01 -0800 > lon...@linuxonhyperv.com wrote: > > > From: Long Li > > > > For vmbus channels without monitoring support, use kernel UIO > > interface to indicate packet

RE: [EXTERNAL] Re: [PATCH] devtools: fix regex of cnxk skip files

> 06/03/2025 16:25, pbhagavat...@marvell.com: > > From: Pavan Nikhilesh > > > > SKIP_FILES should include the path of the file. > > Update the regex to match the path. > > Can you please also check this one: > -v SKIP_FILES='osdep.h$' > Is it really working without the full path? > Sure,

RE: [EXTERNAL] Re: [PATCH] devtools: fix regex of cnxk skip files

> 06/03/2025 16:25, pbhagavat...@marvell.com: > > From: Pavan Nikhilesh > > > > SKIP_FILES should include the path of the file. > > Update the regex to match the path. > > > > Fixes: dd88f51a5725 ("devtools: forbid DPDK API in cnxk base driver") > > > > Signed-off-by: Pavan Nikhilesh > > --- > >

Re: [EXTERNAL] Re: [PATCH v2] net/virtio: add virtio hash report feature

On 2/27/25 10:44 AM, Shiva Shankar Kommula wrote: -Original Message- From: Maxime Coquelin Sent: Tuesday, February 25, 2025 9:39 PM To: Shiva Shankar Kommula ; dev@dpdk.org; chen...@nvidia.com Cc: david.march...@redhat.com; Jerin Jacob ; Nithin Kumar Dabilpuram ; Srujana Challa Subje

Re: [EXTERNAL] Re: [PATCH v2] net/virtio: add virtio hash report feature

On 3/3/25 11:25 AM, Maxime Coquelin wrote: On 2/27/25 10:44 AM, Shiva Shankar Kommula wrote: -Original Message- From: Maxime Coquelin Sent: Tuesday, February 25, 2025 9:39 PM To: Shiva Shankar Kommula ; dev@dpdk.org; chen...@nvidia.com Cc: david.march...@redhat.com; Jerin Jacob ; N

Re: [EXTERNAL] Re: [PATCH v2] net/virtio: add virtio hash report feature

On 2/27/25 10:44 AM, Shiva Shankar Kommula wrote: -Original Message- From: Maxime Coquelin Sent: Tuesday, February 25, 2025 9:39 PM To: Shiva Shankar Kommula ; dev@dpdk.org; chen...@nvidia.com Cc: david.march...@redhat.com; Jerin Jacob ; Nithin Kumar Dabilpuram ; Srujana Challa Subje

Re: [EXTERNAL] Re: [v6 1/5] vhost: skip crypto op fetch before vring init

Hi Gowri, On 2/28/25 2:59 PM, Gowrishankar Muthukrishnan wrote: Hi Maxime, Before your series arrived, we were wondering if we should not deprecate Vhost crypto as it was not really maintained and we had no identified user. Since it seems you are going to use it, which is great, would you co

RE: [EXTERNAL] Re: [v6 1/5] vhost: skip crypto op fetch before vring init

Hi David, > > > > It is due to local vc_req that is passed to func that requires iotlb > > lock In vc_req->vq. Even though vc_req->vq is locked vq, GCC does not allow > > it, > as I understand. > > *cough* clang. > > > > > vc_req = &data_req; > > vc_req->desc_idx = desc_idx; > >

RE: [EXTERNAL] Re: [v6 1/5] vhost: skip crypto op fetch before vring init

Hi Maxime, > > Before your series arrived, we were wondering if we should not deprecate Vhost > crypto as it was not really maintained and we had no identified user. > > Since it seems you are going to use it, which is great, would you commit to > make > the necessary changes to make it reliabl

Re: [EXTERNAL] Re: [v6 1/5] vhost: skip crypto op fetch before vring init

Hi Gowri, On 2/28/25 9:48 AM, David Marchand wrote: On Thu, Feb 27, 2025 at 7:07 PM Gowrishankar Muthukrishnan wrote: Ha, and also you should be able to remove: __rte_no_thread_safety_analysis /* FIXME: requires iotlb_lock? */ in vhost_crypto_process_one_req() once implemented. Removing it

Re: [EXTERNAL] Re: [v6 1/5] vhost: skip crypto op fetch before vring init

On Thu, Feb 27, 2025 at 7:07 PM Gowrishankar Muthukrishnan wrote: > > > Ha, and also you should be able to remove: > > > __rte_no_thread_safety_analysis /* FIXME: requires iotlb_lock? */ in > > > vhost_crypto_process_one_req() once implemented. > > > > > > Removing it would break compilation for t

RE: [EXTERNAL] Re: [v6 1/5] vhost: skip crypto op fetch before vring init

> > > > Ha, and also you should be able to remove: > > __rte_no_thread_safety_analysis /* FIXME: requires iotlb_lock? */ in > > vhost_crypto_process_one_req() once implemented. > > > Removing it would break compilation for thread safety flag. http://mails.dpdk.org/archives/test-report/2025-Februar

RE: [EXTERNAL] Re: [v6 1/5] vhost: skip crypto op fetch before vring init

Hi Maxime, > > > > You should only unlock at the end of the function, otherwise there is > > not much protection. > > Ha, and also you should be able to remove: > __rte_no_thread_safety_analysis /* FIXME: requires iotlb_lock? */ in > vhost_crypto_process_one_req() once implemented. > Ack. Thank

RE: [EXTERNAL] Re: [PATCH v2] net/virtio: add virtio hash report feature

> -Original Message- > From: Maxime Coquelin > Sent: Tuesday, February 25, 2025 9:39 PM > To: Shiva Shankar Kommula ; dev@dpdk.org; > chen...@nvidia.com > Cc: david.march...@redhat.com; Jerin Jacob ; Nithin > Kumar Dabilpuram ; Srujana Challa > > Subject: [EXTERNAL] Re: [PATCH v2] net/vir

RE: [EXTERNAL] Re: [v5 1/5] vhost: skip crypto op fetch before vring init

Hi Maxime, > > > > + if (unlikely(vq == NULL)) { > > + VC_LOG_ERR("Invalid virtqueue %u", qid); > > + return 0; > > + } > > + > > + if (unlikely(vq->avail == NULL)) { > > + VC_LOG_DBG("Virtqueue ring not yet initialized %u", qid); > > + return 0; > > +

RE: [EXTERNAL] Re: [Patch v3] net/mana: use mana_local_data for tracking usage data for primary process

> Subject: [EXTERNAL] Re: [Patch v3] net/mana: use mana_local_data for tracking > usage data for primary process > > On Thu, 20 Feb 2025 15:32:02 -0800 > lon...@linuxonhyperv.com wrote: > > > From: Long Li > > > > The driver uses mana_shared_data for tracking usage count for primary > > process.

RE: [EXTERNAL] Re: [PATCH v6 7/8] app: reduce app dependencies

> On Wed, Feb 19, 2025 at 11:18:46AM +0100, Morten Brørup wrote: > > > From: Akhil Goyal [mailto:gak...@marvell.com] > > > Sent: Wednesday, 19 February 2025 09.16 > > > > > > Hi David, > > > > Hello, > > > > > > > > Cc: Akhil. > > > > > > > > On Tue, Feb 18, 2025 at 12:16 PM Anatoly Burakov > > > >

Re: [EXTERNAL] Re: [PATCH v6 7/8] app: reduce app dependencies

On Wed, Feb 19, 2025 at 11:18:46AM +0100, Morten Brørup wrote: > > From: Akhil Goyal [mailto:gak...@marvell.com] > > Sent: Wednesday, 19 February 2025 09.16 > > > > Hi David, > > > Hello, > > > > > > Cc: Akhil. > > > > > > On Tue, Feb 18, 2025 at 12:16 PM Anatoly Burakov > > > wrote: > > > > diff

RE: [EXTERNAL] Re: [PATCH v6 7/8] app: reduce app dependencies

> From: Akhil Goyal [mailto:gak...@marvell.com] > Sent: Wednesday, 19 February 2025 09.16 > > Hi David, > > Hello, > > > > Cc: Akhil. > > > > On Tue, Feb 18, 2025 at 12:16 PM Anatoly Burakov > > wrote: > > > diff --git a/app/test-crypto-perf/meson.build b/app/test-crypto- > > perf/meson.build > >

RE: [EXTERNAL] Re: [PATCH v6 7/8] app: reduce app dependencies

Hi David, > Hello, > > Cc: Akhil. > > On Tue, Feb 18, 2025 at 12:16 PM Anatoly Burakov > wrote: > > diff --git a/app/test-crypto-perf/meson.build b/app/test-crypto- > perf/meson.build > > index fb48d9ec29..f056431bf4 100644 > > --- a/app/test-crypto-perf/meson.build > > +++ b/app/test-crypto-per

Re: [EXTERNAL] Re: [PATCH v2 3/3] trace: fix undefined behavior in register

On Mon, Feb 10, 2025 at 10:02 AM Sunil Kumar Kori wrote: > > Hi David, > > I tried validating series to see the trace results but babeltrace throws > error while reading metadata file and traces can’t be generated. > > Can you please have a look into this ? Ok, I see what is wrong, in the dma tr

RE: [EXTERNAL] Re: [PATCH v2 3/3] trace: fix undefined behavior in register

: dev@dpdk.org; Chengwen Feng ; Kevin Laatz ; Bruce Richardson ; Tyler Retzlaff ; Andre Muezerie ; Thomas Monjalon ; Stephen Hemminger Subject: RE: [EXTERNAL] Re: [PATCH v2 3/3] trace: fix undefined behavior in register Hi David, I will look into this at earliest and provide feedback. Thanks

RE: [EXTERNAL] Re: [PATCH] net/mana: use mana_local_data for tracking usage data for primary process

> On Fri, 7 Feb 2025 15:21:45 -0800 > lon...@linuxonhyperv.com wrote: > > > + /* At least one eth_dev is probed, init shared data */ > > + if (rte_eal_process_type() == RTE_PROC_PRIMARY) { > > + rte_spinlock_lock(&mana_shared_data_lock); > > + mana_local_data.primary_cnt++

RE: [EXTERNAL] Re: [PATCH v2 3/3] trace: fix undefined behavior in register

Hi David, I will look into this at earliest and provide feedback. Thanks From: David Marchand Sent: Friday, February 7, 2025 2:20 PM To: Jerin Jacob ; Sunil Kumar Kori Cc: dev@dpdk.org; Chengwen Feng ; Kevin Laatz ; Bruce Richardson ; Tyler Retzlaff ; Andre Muezerie ; Thomas Monjalon ; Step

RE: [EXTERNAL] Re: [v2 1/4] common/virtio: move vDPA to common directory

Hi Maxime, > On 1/7/25 7:44 PM, Gowrishankar Muthukrishnan wrote: > > Move vhost-vdpa backend implementation into common folder. > > If we decided to have a common base for Virtio devices, which I think is a > good > idea to avoid needless duplication, we should do a deeper refactoring by > shar

RE: [EXTERNAL] Re: [PATCH 4/4] net/netvsc: cache device parameters for hot plug events

> From: Stephen Hemminger > Sent: Wednesday, January 29, 2025 7:59 PM > To: Long Li > Cc: lon...@linuxonhyperv.com; Ferruh Yigit ; Andrew > Rybchenko ; Wei Hu ; > dev@dpdk.org > Subject: Re: [EXTERNAL] Re: [PATCH 4/4] net/netvsc: cache device parameters > for hot plug ev

Re: [EXTERNAL] Re: [PATCH 1/2] lib/dmadev: eliminate undefined behavior

On Fri, Jan 24, 2025 at 12:13 PM David Marchand wrote: > > On Tue, Dec 10, 2024 at 1:58 AM fengchengwen wrote: > > > + @Chengwen Feng > > > > > > This kind of patten is not used other places like ethdev traces, Why we > > > need this kind of pattern in dmadev? > > > Looks like, it can be fixed b

RE: [EXTERNAL] Re: [v2 2/2] examples/vhost_crypto: add asymmetric support

Hi Maxime, > > static const struct rte_vhost_device_ops virtio_crypto_device_ops = { > > - .new_device = new_device, > > - .destroy_device = destroy_device, > > + .new_connection = new_device, > > + .destroy_connection = destroy_device, > It may be worth explaining in the commit messag

Re: [EXTERNAL] Re: [PATCH 4/4] net/netvsc: cache device parameters for hot plug events

On Wed, 29 Jan 2025 00:10:12 + Long Li wrote: > Another approach is to modify EAL to never delete driver arguments when a > device is removed. i.e., It doesn't call rte_devargs_remove() on device > removal, instead keep those devargs for the lifetime of the process. Do you > think this is

RE: [EXTERNAL] Re: [PATCH 4/4] net/netvsc: cache device parameters for hot plug events

> -Original Message- > From: Stephen Hemminger > Sent: Tuesday, January 28, 2025 4:32 PM > To: Long Li > Cc: lon...@linuxonhyperv.com; Ferruh Yigit ; Andrew > Rybchenko ; Wei Hu ; > dev@dpdk.org > Subject: Re: [EXTERNAL] Re: [PATCH 4/4] net/netvsc: cache dev

Re: [EXTERNAL] Re: [PATCH 4/4] net/netvsc: cache device parameters for hot plug events

On Wed, 29 Jan 2025 00:10:12 + Long Li wrote: > > Subject: [EXTERNAL] Re: [PATCH 4/4] net/netvsc: cache device parameters for > > hot plug events > > > > On Mon, 27 Jan 2025 17:35:06 -0800 > > lon...@linuxonhyperv.com wrote: > > > > > @@ -1409,9 +1424,6 @@ eth_hn_dev_uninit(struct rte_eth

RE: [EXTERNAL] Re: [PATCH 4/4] net/netvsc: cache device parameters for hot plug events

> Subject: [EXTERNAL] Re: [PATCH 4/4] net/netvsc: cache device parameters for > hot plug events > > On Mon, 27 Jan 2025 17:35:06 -0800 > lon...@linuxonhyperv.com wrote: > > > @@ -1409,9 +1424,6 @@ eth_hn_dev_uninit(struct rte_eth_dev *eth_dev) > > ret_stop = hn_dev_stop(eth_dev); > > hn_d

Re: [EXTERNAL] Re: [PATCH 1/2] lib/dmadev: eliminate undefined behavior

On Tue, Dec 10, 2024 at 1:58 AM fengchengwen wrote: > > + @Chengwen Feng > > > > This kind of patten is not used other places like ethdev traces, Why we > > need this kind of pattern in dmadev? > > Looks like, it can be fixed by caller of this function by initializing > > struct rte_dma_info. So

RE: [EXTERNAL] Re: [v25,13/13] compress/zsda: add zsda compressdev capabilities

> Hi, Akhil: > > There are warning and some errors in the patches. > > > The warning is > > >_coding style issues_ > > > > > >__rte_packed_begin and __rte_packed_end should always be used in pairs. > > And the context in the patch is： > > > struct __rte_packed_begin zsda_admin_req { > > u

RE: [EXTERNAL] Re: [PATCH] lib/eventdev: use correct format string for data type on log call

> -Original Message- > From: Stephen Hemminger > Sent: Friday, December 27, 2024 11:30 PM > To: Andre Muezerie > Cc: Amit Prakash Shukla ; Jerin Jacob > ; dev@dpdk.org > Subject: [EXTERNAL] Re: [PATCH] lib/eventdev: use correct format string for > data type on log call > > On Fri, 27

Re: [EXTERNAL] Re: [PATCH] net/tap: fix compilation issues if HAVE_TCA_FLOWER is missing

On Thu, 9 Jan 2025 07:31:32 + Tomasz Duszynski wrote: > >> From: Tomasz Duszynski > >> To: , Stephen Hemminger , > >"Pascal Mazon" > >> CC: , Tomasz Duszynski > >> Subject: [PATCH] net/tap: fix compilation issues if HAVE_TCA_FLOWER is > >> missing > >> Date: Wed, 8 Jan 2025 13:10:11 +

RE: [EXTERNAL] Re: [PATCH] net/tap: fix compilation issues if HAVE_TCA_FLOWER is missing

>> From: Tomasz Duszynski >> To: , Stephen Hemminger , >"Pascal Mazon" >> CC: , Tomasz Duszynski >> Subject: [PATCH] net/tap: fix compilation issues if HAVE_TCA_FLOWER is >> missing >> Date: Wed, 8 Jan 2025 13:10:11 +0100 >> X-Mailer: git-send-email 2.34.1 >> >> If HAVE_TCA_FLOWER is undefined

RE: [EXTERNAL] Re: [PATCH v2] cryptodev: fix C++ include

> On 2024-12-19 14:30, Thomas Monjalon wrote: > > Some cryptodev functions were not included in an extern "C" block. > > > > There are 2 blocks, the second one being fast path inline functions, > > preceded with an include of the required rte_cryptodev_core.h file. > > > > Fixes: 719834a6849e ("use

RE: [EXTERNAL] Re: [PATCH v16 4/4] eal: add PMU support to tracing library

>> + >> +/* events are matched against occurrences of e=ev1[,ev2,..] pattern */ >> +ret = regcomp(®, "e=([_[:alnum:]-],?)+", REG_EXTENDED); >> +if (ret) { >> +PMU_LOG(ERR, "Failed to compile event matching regexp"); >> +return -EINVAL; >> +} >> + >> +for

RE: [EXTERNAL] Re: [v1 12/16] common/virtio: common virtio log

Hi David, > Hello Gowri, > > On Tue, Dec 24, 2024 at 8:39 AM Gowrishankar Muthukrishnan > wrote: > > > > Common virtio log include file. > > That's really a short commitlog.. > What are you trying to achieve? As part of sharing vDPA backend ops implementation between net and crypto (in patch

RE: [EXTERNAL] Re: [PATCH v16 0/4] add support for self monitoring

>> This series adds self monitoring support i.e allows to configure and >> read performance measurement unit (PMU) counters in runtime without >> using perf utility. This has certain advantages when application runs >> on isolated cores running dedicated tasks. >> >> Events can be read directly usi

RE: [EXTERNAL] Re: [PATCH v16 1/4] lib: add generic support for reading PMU events

>> +Performance counter based profiling >> +--- >> + >> +Majority of architectures support some performance monitoring unit >(PMU). >> +Such unit provides programmable counters that monitor specific events. > >Sentence wording is awkward, maybe combine the two senten

Re: [EXTERNAL] Re: [PATCH 1/2] lib/dmadev: eliminate undefined behavior

On 2024/12/10 7:21, Jerin Jacob wrote: > > >> -Original Message- >> From: Bruce Richardson >> Sent: Monday, December 9, 2024 4:58 AM >> To: Andre Muezerie ; Jerin Jacob >> >> Cc: Chengwen Feng ; Kevin Laatz >> ; dev@dpdk.org >> Subject: [EXTERNAL] Re: [PATCH 1/2] lib/dmadev: eliminate u

  1   2   3   4   >