Re: [PATCH v9 0/9] add rte flow support for cpfl

[Thomas Monjalon]

28/09/2023 10:44, yuying.zh...@intel.com:
> From: Yuying Zhang 
> 
> This patchset add rte flow support for cpfl driver.
> It depends on the following patch set:
> http://patchwork.dpdk.org/project/dpdk/cover/20230912173039.1612287-1-beilei.x...@intel.com/
> 
> Wenjing Qiao (2):
>   net/cpfl: add json parser for rte flow pattern rules
>   net/cpfl: build action mapping rules from JSON
> 
> Yuying Zhang (7):
>   net/cpfl: set up rte flow skeleton
>   net/cpfl: set up control path
>   net/cpfl: add FXP low level implementation
>   net/cpfl: add fxp rule module
>   net/cpfl: add fxp flow engine
>   net/cpfl: add flow support for representor
>   net/cpfl: add support of to represented port action

You did not update the feature list in doc/guides/nics/features/cpfl.ini

You could have generated it with this command:
devtools/parse-flow-support.sh drivers/net/cpfl

This miss is caught by the script devtools/check-doc-vs-code.sh
Please run it.

Re: [PATCH v9 3/9] net/cpfl: set up rte flow skeleton

[Thomas Monjalon]

28/09/2023 10:44, yuying.zh...@intel.com:
> --- /dev/null
> +++ b/drivers/net/cpfl/cpfl_flow.h
> @@ -0,0 +1,85 @@
> +/* SPDX-Lidpfnse-Identifier: BSD-3-Clause

Are you sure?

This typo has been caught by devtools/check-spdx-tag.sh

Please run the scripts in devtools.

Re:Re: [PATCH v2 0/3] example/l3fwd: relax l3fwd rx RSS/Offload if needed

[taozj888]

Hi David:


Thanks for your notifications. I will check them in the future work.


Trevor Tao








At 2023-10-13 15:07:03, "David Marchand"  wrote:
>Hello,
>
>On Fri, Oct 13, 2023 at 6:28 AM Trevor Tao  wrote:
>>
>> This series tries to relax l3fwd rx RSS/Offload mode requirement if they
>> are not supported by underlying hw or virtual devices, there is an
>> option named relax_rx_mode added to enable this option.
>>
>> Trevor Tao (3):
>>   examples/l3fwd: relax RSS requirement with option
>>   examples/l3fwd: relax the Offload requirement
>>   doc: add a relax rx mode requirement option
>>
>>  doc/guides/rel_notes/release_23_11.rst  | 251 +---
>>  doc/guides/sample_app_ug/l3_forward.rst |   4 +-
>>  examples/l3fwd/l3fwd.h  |  12 +-
>>  examples/l3fwd/l3fwd_em.h   |   2 +-
>>  examples/l3fwd/l3fwd_lpm.h  |   2 +-
>>  examples/l3fwd/main.c   |  30 +++
>>  6 files changed, 272 insertions(+), 29 deletions(-)
>
>Thanks for the patches.
>One comment on the form though.
>
>I see 4 batches of "v2 patches" in patchwork.
>https://patchwork.dpdk.org/project/dpdk/list/?submitter=3044&state=*
>I marked all but the last batch as superseded.
>If there is something wrong with this, please register to patchwork
>with your mail address, you will then be able to update the states
>yourself.
>
>
>It is hard to follow what work has been done between those different
>iterations of patches.
>For future submissions, don't forget to version your patches with a
>new revision (iirc, we should be at version 7 if I count the initial
>standalone v1 patch).
>
>In the cover letter, please provide a changelog of the differences
>between revisions.
>If you think it is better, you may put a more detailed changelog in
>each patch commitlog (as annotations, after ---).
>
>
>Thanks.
>
>-- 
>David Marchand

[PATCH] eal: use abstracted bit count functions

[Tyler Retzlaff]

Use DPDK abstracted bitcount functions in rte_bsf and rte_fls inline
functions.

Signed-off-by: Tyler Retzlaff 
---
 lib/eal/include/rte_bitops.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/eal/include/rte_bitops.h b/lib/eal/include/rte_bitops.h
index d45aa54..6b8ae8d 100644
--- a/lib/eal/include/rte_bitops.h
+++ b/lib/eal/include/rte_bitops.h
@@ -574,7 +574,7 @@
 static inline uint32_t
 rte_bsf32(uint32_t v)
 {
-   return (uint32_t)__builtin_ctz(v);
+   return (uint32_t)rte_ctz32(v);
 }
 
 /**
@@ -615,7 +615,7 @@
 static inline uint32_t
 rte_bsf64(uint64_t v)
 {
-   return (uint32_t)__builtin_ctzll(v);
+   return (uint32_t)rte_ctz64(v);
 }
 
 /**
@@ -656,7 +656,7 @@
 static inline uint32_t
 rte_fls_u32(uint32_t x)
 {
-   return (x == 0) ? 0 : 32 - __builtin_clz(x);
+   return (x == 0) ? 0 : 32 - rte_clz32(x);
 }
 
 /**
@@ -674,7 +674,7 @@
 static inline uint32_t
 rte_fls_u64(uint64_t x)
 {
-   return (x == 0) ? 0 : 64 - __builtin_clzll(x);
+   return (x == 0) ? 0 : 64 - rte_clz64(x);
 }
 
 /*** Macros to work with powers of 2 /
-- 
1.8.3.1

[Bug 1300] iavf: when ovs using tso，setting RTE_MBUF_F_TX_TCP_SEG and RTE_MBUF_F_TX_TCP_CKSUM meantime result in tso fail

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=1300

Bug ID: 1300
   Summary: iavf: when ovs using tso，setting RTE_MBUF_F_TX_TCP_SEG
and RTE_MBUF_F_TX_TCP_CKSUM meantime result in tso
fail
   Product: DPDK
   Version: 22.11
  Hardware: x86
OS: Linux
Status: UNCONFIRMED
  Severity: major
  Priority: Normal
 Component: eventdev
  Assignee: dev@dpdk.org
  Reporter: dexia...@jaguarmicro.com
  Target Milestone: ---

when ovs using tso, setting RTE_MBUF_F_TX_TCP_SEG and RTE_MBUF_F_TX_TCP_CKSUM
meantime result in tso fail.

Please help to confirm that we can't set both at the same time?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[PATCH v2] eal: use abstracted bit count functions

[Tyler Retzlaff]

Use DPDK abstracted bitcount functions instead of gcc __builtin_'s

Signed-off-by: Tyler Retzlaff 
---
 lib/eal/common/malloc_elem.c | 2 +-
 lib/eal/common/rte_service.c | 4 ++--
 lib/eal/include/rte_bitops.h | 8 
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/lib/eal/common/malloc_elem.c b/lib/eal/common/malloc_elem.c
index 619c040..f5d1c8c 100644
--- a/lib/eal/common/malloc_elem.c
+++ b/lib/eal/common/malloc_elem.c
@@ -386,7 +386,7 @@
return 0;
 
/* Find next power of 2 > size. */
-   log2 = sizeof(size) * 8 - __builtin_clzl(size);
+   log2 = sizeof(size) * 8 - rte_clz64(size);
 
/* Compute freelist index, based on log2(size). */
index = (log2 - MALLOC_MINSIZE_LOG2 + MALLOC_LOG2_INCREMENT - 1) /
diff --git a/lib/eal/common/rte_service.c b/lib/eal/common/rte_service.c
index 9e2aa4a..098a821 100644
--- a/lib/eal/common/rte_service.c
+++ b/lib/eal/common/rte_service.c
@@ -505,8 +505,8 @@ struct core_state {
if (service_mask == 0)
continue;
 
-   start_id = __builtin_ctzl(service_mask);
-   end_id = 64 - __builtin_clzl(service_mask);
+   start_id = rte_ctz64(service_mask);
+   end_id = 64 - rte_clz64(service_mask);
 
for (i = start_id; i < end_id; i++) {
/* return value ignored as no change to code flow */
diff --git a/lib/eal/include/rte_bitops.h b/lib/eal/include/rte_bitops.h
index d45aa54..6b8ae8d 100644
--- a/lib/eal/include/rte_bitops.h
+++ b/lib/eal/include/rte_bitops.h
@@ -574,7 +574,7 @@
 static inline uint32_t
 rte_bsf32(uint32_t v)
 {
-   return (uint32_t)__builtin_ctz(v);
+   return (uint32_t)rte_ctz32(v);
 }
 
 /**
@@ -615,7 +615,7 @@
 static inline uint32_t
 rte_bsf64(uint64_t v)
 {
-   return (uint32_t)__builtin_ctzll(v);
+   return (uint32_t)rte_ctz64(v);
 }
 
 /**
@@ -656,7 +656,7 @@
 static inline uint32_t
 rte_fls_u32(uint32_t x)
 {
-   return (x == 0) ? 0 : 32 - __builtin_clz(x);
+   return (x == 0) ? 0 : 32 - rte_clz32(x);
 }
 
 /**
@@ -674,7 +674,7 @@
 static inline uint32_t
 rte_fls_u64(uint64_t x)
 {
-   return (x == 0) ? 0 : 64 - __builtin_clzll(x);
+   return (x == 0) ? 0 : 64 - rte_clz64(x);
 }
 
 /*** Macros to work with powers of 2 /
-- 
1.8.3.1

RE: [PATCH v9 3/9] net/cpfl: set up rte flow skeleton

[Zhang, Qi Z]

> -Original Message-
> From: Thomas Monjalon 
> Sent: Sunday, October 15, 2023 9:02 PM
> To: Zhang, Qi Z 
> Cc: Zhang, Yuying ; dev@dpdk.org; Wu, Jingjing
> ; Xing, Beilei ; Zhang, Yuying
> ; david.march...@redhat.com
> Subject: Re: [PATCH v9 3/9] net/cpfl: set up rte flow skeleton
> 
> 28/09/2023 10:44, yuying.zh...@intel.com:
> > --- /dev/null
> > +++ b/drivers/net/cpfl/cpfl_flow.h
> > @@ -0,0 +1,85 @@
> > +/* SPDX-Lidpfnse-Identifier: BSD-3-Clause
> 
> Are you sure?
> 
> This typo has been caught by devtools/check-spdx-tag.sh
> 
> Please run the scripts in devtools.

OK, added in my check list.

> 

RE: [PATCH] net/cpfl: reset devargs during the first probe

[Zhang, Qi Z]

> -Original Message-
> From: Xing, Beilei 
> Sent: Thursday, October 12, 2023 3:42 PM
> To: Wu, Jingjing 
> Cc: dev@dpdk.org
> Subject: RE: [PATCH] net/cpfl: reset devargs during the first probe
> 
> 
> 
> > -Original Message-
> > From: Wu, Jingjing 
> > Sent: Thursday, October 12, 2023 2:54 PM
> > To: Xing, Beilei 
> > Cc: dev@dpdk.org
> > Subject: RE: [PATCH] net/cpfl: reset devargs during the first probe
> >
> >
> >
> > > -Original Message-
> > > From: Xing, Beilei 
> > > Sent: Thursday, October 12, 2023 12:47 AM
> > > To: Wu, Jingjing 
> > > Cc: dev@dpdk.org; Xing, Beilei 
> > > Subject: [PATCH] net/cpfl: reset devargs during the first probe
> > >
> > > From: Beilei Xing 
> >
> > > Reset devargs during the first probe. Otherwise, probe again will be
> > > affected.
> > >
> > > Fixes: a607312291b3 ("net/cpfl: support probe again")
> > >
> > > Signed-off-by: Beilei Xing 
> > > ---
> > >  drivers/net/cpfl/cpfl_ethdev.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/net/cpfl/cpfl_ethdev.c
> > > b/drivers/net/cpfl/cpfl_ethdev.c index 762fbddfe6..890a027a1d 100644
> > > --- a/drivers/net/cpfl/cpfl_ethdev.c
> > > +++ b/drivers/net/cpfl/cpfl_ethdev.c
> > > @@ -1611,11 +1611,12 @@ cpfl_parse_devargs(struct rte_pci_device
> > > *pci_dev, struct cpfl_adapter_ext *adap
> > >   struct rte_kvargs *kvlist;
> > >   int ret;
> > >
> > > - cpfl_args->req_vport_nb = 0;
> > > -
> > >   if (devargs == NULL)
> > >   return 0;
> > >
> > > + if (first)
> > > + memset(cpfl_args, 0, sizeof(struct cpfl_devargs));
> > > +
> > adapter is allocated by rte_zmalloc. It should be zero already.
> > If I understand correctly, memset to 0 should be happened when first
> > probe is done or before probe again but not at the beginning when first 
> > probe.
> 
> But 'struct cpfl_devargs devargs' is the member of adapter, if 'memset to 0'
> happens before probe again, adapter->devargs will only save the last devargs.

Reverted from dpdk-next-net-intel.

RE: [PATCH] config/x86: config support for AMD EPYC processors

[Tummala, Sivaprasad]

[AMD Official Use Only - General]

> -Original Message-
> From: David Marchand 
> Sent: Friday, October 6, 2023 1:21 PM
> To: Tummala, Sivaprasad 
> Cc: bruce.richard...@intel.com; konstantin.v.anan...@yandex.ru; dev@dpdk.org;
> dpdk-techboard ; Thomas Monjalon
> 
> Subject: Re: [PATCH] config/x86: config support for AMD EPYC processors
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Mon, Sep 25, 2023 at 5:11 PM Sivaprasad Tummala
>  wrote:
> >
> > From: Sivaprasad Tummala 
> >
> > By default, max lcores are limited to 128 for x86 platforms.
> > On AMD EPYC processors, this limit needs to be increased to leverage
> > all the cores.
> >
> > The patch adjusts the limit specifically for native compilation on AMD
> > EPYC CPUs.
> >
> > Signed-off-by: Sivaprasad Tummala 
>
> This patch is a revamp of
> http://inbox.dpdk.org/dev/BY5PR12MB3681C3FC6676BC03F0B42CCC96789@BY5PR
> 12MB3681.namprd12.prod.outlook.com/
> for which a discussion at techboard is supposed to have taken place.
> But I didn't find a trace of it.
>
> One option that had been discussed in the previous thread was to increase the
> max number of cores for x86.
> I am unclear if this option has been properly evaluated/debatted.
>
> Can the topic be brought again at techboard?

Hi David,

The patch is intended to detect AMD platforms and enable all CPU cores by
default on native builds.

As an optimization for memory footprint, users can override this by specifying
"-Dmax_lcores" option based on DPDK lcores required for their usecases.

Sure, will request to add this topic for discussion at techboard.
>
> Thanks.
>
> --
> David Marchand

RE: [PATCH] config/x86: config support for AMD EPYC processors

[Tummala, Sivaprasad]

[AMD Official Use Only - General]

Hi DPDK Techboard,

Request to add this topic for discussion in the next techboard meeting.

Thanks & Regards,
Sivaprasad

> -Original Message-
> From: Tummala, Sivaprasad 
> Sent: Monday, October 16, 2023 10:44 AM
> To: David Marchand 
> Cc: bruce.richard...@intel.com; konstantin.v.anan...@yandex.ru; dev@dpdk.org;
> dpdk-techboard ; Thomas Monjalon
> 
> Subject: RE: [PATCH] config/x86: config support for AMD EPYC processors
>
> [AMD Official Use Only - General]
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> [AMD Official Use Only - General]
>
> > -Original Message-
> > From: David Marchand 
> > Sent: Friday, October 6, 2023 1:21 PM
> > To: Tummala, Sivaprasad 
> > Cc: bruce.richard...@intel.com; konstantin.v.anan...@yandex.ru;
> > dev@dpdk.org; dpdk-techboard ; Thomas Monjalon
> > 
> > Subject: Re: [PATCH] config/x86: config support for AMD EPYC
> > processors
> >
> > Caution: This message originated from an External Source. Use proper
> > caution when opening attachments, clicking links, or responding.
> >
> >
> > On Mon, Sep 25, 2023 at 5:11 PM Sivaprasad Tummala
> >  wrote:
> > >
> > > From: Sivaprasad Tummala 
> > >
> > > By default, max lcores are limited to 128 for x86 platforms.
> > > On AMD EPYC processors, this limit needs to be increased to leverage
> > > all the cores.
> > >
> > > The patch adjusts the limit specifically for native compilation on
> > > AMD EPYC CPUs.
> > >
> > > Signed-off-by: Sivaprasad Tummala 
> >
> > This patch is a revamp of
> >
> http://inbox.dpdk.org/dev/BY5PR12MB3681C3FC6676BC03F0B42CCC96789@BY5PR
> > 12MB3681.namprd12.prod.outlook.com/
> > for which a discussion at techboard is supposed to have taken place.
> > But I didn't find a trace of it.
> >
> > One option that had been discussed in the previous thread was to
> > increase the max number of cores for x86.
> > I am unclear if this option has been properly evaluated/debatted.
> >
> > Can the topic be brought again at techboard?
>
> Hi David,
>
> The patch is intended to detect AMD platforms and enable all CPU cores by 
> default
> on native builds.
>
> As an optimization for memory footprint, users can override this by 
> specifying "-
> Dmax_lcores" option based on DPDK lcores required for their usecases.
>
> Sure, will request to add this topic for discussion at techboard.
> >
> > Thanks.
> >
> > --
> > David Marchand

[PATCH] net/cnxk: fix separate callback for Rx flush on CN10k

[Rahul Bhansali]

In case of dev stop, Rx packet flush will be called which
uses LMT lines to bulk free of the pending meta buffers.
And LMT line is not valid for non EAL cores. As a fix,
a separate callback for Rx packets flush is added, which
will use NPA aura free API on individual meta packets.

Fixes: 4382a7ccf781 ("net/cnxk: support Rx security offload on cn10k")

Signed-off-by: Rahul Bhansali 
---
 drivers/net/cnxk/cn10k_rx.h| 93 ++
 drivers/net/cnxk/cn10k_rx_select.c | 10 +++-
 2 files changed, 101 insertions(+), 2 deletions(-)

diff --git a/drivers/net/cnxk/cn10k_rx.h b/drivers/net/cnxk/cn10k_rx.h
index f5e935d383..7bb4c86d75 100644
--- a/drivers/net/cnxk/cn10k_rx.h
+++ b/drivers/net/cnxk/cn10k_rx.h
@@ -1098,6 +1098,99 @@ cn10k_nix_recv_pkts(void *rx_queue, struct rte_mbuf 
**rx_pkts, uint16_t pkts,
return nb_pkts;
 }
 
+static __rte_always_inline uint16_t
+cn10k_nix_flush_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t 
pkts,
+ const uint16_t flags)
+{
+   struct cn10k_eth_rxq *rxq = rx_queue;
+   const uint64_t mbuf_init = rxq->mbuf_initializer;
+   const void *lookup_mem = rxq->lookup_mem;
+   const uint64_t data_off = rxq->data_off;
+   struct rte_mempool *meta_pool = NULL;
+   const uint64_t wdata = rxq->wdata;
+   const uint32_t qmask = rxq->qmask;
+   const uintptr_t desc = rxq->desc;
+   uint64_t lbase = rxq->lmt_base;
+   uint16_t packets = 0, nb_pkts;
+   uint16_t lmt_id __rte_unused;
+   uint32_t head = rxq->head;
+   struct nix_cqe_hdr_s *cq;
+   struct rte_mbuf *mbuf;
+   uint64_t sa_base = 0;
+   uintptr_t cpth = 0;
+   uint8_t loff = 0;
+   uint64_t laddr;
+
+   nb_pkts = nix_rx_nb_pkts(rxq, wdata, pkts, qmask);
+
+   if (flags & NIX_RX_OFFLOAD_SECURITY_F) {
+   sa_base = rxq->sa_base;
+   sa_base &= ~(ROC_NIX_INL_SA_BASE_ALIGN - 1);
+   ROC_LMT_BASE_ID_GET(lbase, lmt_id);
+   laddr = lbase;
+   laddr += 8;
+   if (flags & NIX_RX_REAS_F)
+   meta_pool = (struct rte_mempool *)rxq->meta_pool;
+   }
+
+   while (packets < nb_pkts) {
+   /* Prefetch N desc ahead */
+   rte_prefetch_non_temporal((void *)(desc + (CQE_SZ((head + 2) & 
qmask;
+   cq = (struct nix_cqe_hdr_s *)(desc + CQE_SZ(head));
+
+   mbuf = nix_get_mbuf_from_cqe(cq, data_off);
+
+   /* Mark mempool obj as "get" as it is alloc'ed by NIX */
+   RTE_MEMPOOL_CHECK_COOKIES(mbuf->pool, (void **)&mbuf, 1, 1);
+
+   /* Translate meta to mbuf */
+   if (flags & NIX_RX_OFFLOAD_SECURITY_F) {
+   const uint64_t cq_w1 = *((const uint64_t *)cq + 1);
+   const uint64_t cq_w5 = *((const uint64_t *)cq + 5);
+   struct rte_mbuf *meta_buf = mbuf;
+
+   cpth = ((uintptr_t)meta_buf + (uint16_t)data_off);
+
+   /* Update mempool pointer for full mode pkt */
+   if ((flags & NIX_RX_REAS_F) && (cq_w1 & BIT(11)) &&
+   !((*(uint64_t *)cpth) & BIT(15)))
+   meta_buf->pool = meta_pool;
+
+   mbuf = nix_sec_meta_to_mbuf_sc(cq_w1, cq_w5, sa_base, 
laddr, &loff,
+  meta_buf, data_off, 
flags, mbuf_init);
+   /* Free Meta mbuf, not use LMT line for flush as this 
will be called
+* from non-datapath i.e. dev_stop case.
+*/
+   if (loff) {
+   roc_npa_aura_op_free(meta_buf->pool->pool_id, 0,
+(uint64_t)meta_buf);
+   loff = 0;
+   }
+   }
+
+   cn10k_nix_cqe_to_mbuf(cq, cq->tag, mbuf, lookup_mem, mbuf_init,
+ cpth, sa_base, flags);
+   cn10k_nix_mbuf_to_tstamp(mbuf, rxq->tstamp,
+   (flags & NIX_RX_OFFLOAD_TSTAMP_F),
+   (uint64_t *)((uint8_t *)mbuf + 
data_off));
+   rx_pkts[packets++] = mbuf;
+   roc_prefetch_store_keep(mbuf);
+   head++;
+   head &= qmask;
+   }
+
+   rxq->head = head;
+   rxq->available -= nb_pkts;
+
+   /* Free all the CQs that we've processed */
+   plt_write64((wdata | nb_pkts), rxq->cq_door);
+
+   if (flags & NIX_RX_OFFLOAD_SECURITY_F)
+   rte_io_wmb();
+
+   return nb_pkts;
+}
+
 #if defined(RTE_ARCH_ARM64)
 
 static __rte_always_inline uint64_t
diff --git a/drivers/net/cnxk/cn10k_rx_select.c 
b/drivers/net/cnxk/cn10k_rx_select.c
index 1d44f2924e..6a5c34287e 100644
--- a/drivers/net/cnxk/cn10k_rx_select.c
+++ b

Re: [PATCH v4 1/2] doc: increase python max line length to 100

[Juraj Linkeš]

On Fri, Oct 13, 2023 at 6:09 PM Stephen Hemminger
 wrote:
>
> On Fri, 13 Oct 2023 09:58:04 +0200
> Juraj Linkeš  wrote:
>
> > Unify with C recommendations which allow line length of up to 100
> > characters.
> >
> > Signed-off-by: Juraj Linkeš 
> > Acked-by: Bruce Richardson 
> > ---
> >  .editorconfig| 2 +-
> >  doc/doc_build/meson-private/meson.lock   | 0
> >  doc/guides/contributing/coding_style.rst | 1 +
> >  dts/pyproject.toml   | 4 ++--
> >  4 files changed, 4 insertions(+), 3 deletions(-)
> >  create mode 100644 doc/doc_build/meson-private/meson.loc
>
> Look like meson.lock snuck into this patchset.
> Assume that was a mistake.

My bad, let me send a fix.

[PATCH v5 1/2] doc: increase python max line length to 100

[Juraj Linkeš]

Unify with C recommendations which allow line length of up to 100
characters.

Signed-off-by: Juraj Linkeš 
Acked-by: Bruce Richardson 
---
 .editorconfig| 2 +-
 doc/guides/contributing/coding_style.rst | 1 +
 dts/pyproject.toml   | 4 ++--
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/.editorconfig b/.editorconfig
index ab41c95085..1e7d74213f 100644
--- a/.editorconfig
+++ b/.editorconfig
@@ -16,7 +16,7 @@ max_line_length = 100
 [*.py]
 indent_style = space
 indent_size = 4
-max_line_length = 79
+max_line_length = 100
 
 [meson.build]
 indent_style = space
diff --git a/doc/guides/contributing/coding_style.rst 
b/doc/guides/contributing/coding_style.rst
index 648849899d..1ebc79ca3c 100644
--- a/doc/guides/contributing/coding_style.rst
+++ b/doc/guides/contributing/coding_style.rst
@@ -880,6 +880,7 @@ All Python code should be compliant with
 `PEP8 (Style Guide for Python Code) 
`_.
 
 The ``pep8`` tool can be used for testing compliance with the guidelines.
+Note that line lengths are acceptable up to 100 characters, which is in line 
with C recommendations.
 
 Integrating with the Build System
 -
diff --git a/dts/pyproject.toml b/dts/pyproject.toml
index 6762edfa6b..980ac3c7db 100644
--- a/dts/pyproject.toml
+++ b/dts/pyproject.toml
@@ -41,7 +41,7 @@ build-backend = "poetry.core.masonry.api"
 [tool.pylama]
 linters = "mccabe,pycodestyle,pyflakes"
 format = "pylint"
-max_line_length = 88 # 
https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#line-length
+max_line_length = 100
 
 [tool.mypy]
 python_version = "3.10"
@@ -55,4 +55,4 @@ profile = "black"
 [tool.black]
 target-version = ['py310']
 include = '\.pyi?$'
-line-length = 88 # 
https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#line-length
+line-length = 100
-- 
2.34.1

[PATCH v5 2/2] dts: reformat to 100 line length

[Juraj Linkeš]

Reformat to 100 from the previous 88 to unify with C recommendations.

Signed-off-by: Juraj Linkeš 
Acked-by: Jeremy Spewock 
---
 dts/framework/config/__init__.py  | 20 ++-
 dts/framework/dts.py  | 15 ++---
 dts/framework/exception.py|  5 +-
 dts/framework/remote_session/__init__.py  |  4 +-
 dts/framework/remote_session/linux_session.py | 39 -
 dts/framework/remote_session/posix_session.py | 30 +++---
 .../remote/interactive_remote_session.py  |  7 +--
 .../remote/interactive_shell.py   |  4 +-
 .../remote_session/remote/remote_session.py   |  8 +--
 .../remote_session/remote/ssh_session.py  | 16 ++
 .../remote_session/remote/testpmd_shell.py|  8 +--
 dts/framework/settings.py | 15 ++---
 dts/framework/test_result.py  | 16 ++
 dts/framework/test_suite.py   | 57 +--
 .../capturing_traffic_generator.py|  7 +--
 dts/framework/testbed_model/hw/cpu.py | 20 ++-
 dts/framework/testbed_model/node.py   |  8 +--
 dts/framework/testbed_model/scapy.py  | 19 ++-
 dts/framework/testbed_model/sut_node.py   | 40 -
 dts/framework/testbed_model/tg_node.py|  7 +--
 dts/framework/utils.py| 20 ++-
 dts/tests/TestSuite_hello_world.py|  4 +-
 dts/tests/TestSuite_smoke_tests.py| 11 +---
 23 files changed, 99 insertions(+), 281 deletions(-)

diff --git a/dts/framework/config/__init__.py b/dts/framework/config/__init__.py
index cb7e00ba34..9b32cf0532 100644
--- a/dts/framework/config/__init__.py
+++ b/dts/framework/config/__init__.py
@@ -140,9 +140,7 @@ def from_dict(d: dict) -> Union["SutNodeConfiguration", 
"TGNodeConfiguration"]:
 
 if "traffic_generator" in d:
 return TGNodeConfiguration(
-traffic_generator=TrafficGeneratorConfig.from_dict(
-d["traffic_generator"]
-),
+
traffic_generator=TrafficGeneratorConfig.from_dict(d["traffic_generator"]),
 **common_config,
 )
 else:
@@ -249,9 +247,7 @@ def from_dict(
 build_targets: list[BuildTargetConfiguration] = list(
 map(BuildTargetConfiguration.from_dict, d["build_targets"])
 )
-test_suites: list[TestSuiteConfig] = list(
-map(TestSuiteConfig.from_dict, d["test_suites"])
-)
+test_suites: list[TestSuiteConfig] = 
list(map(TestSuiteConfig.from_dict, d["test_suites"]))
 sut_name = d["system_under_test_node"]["node_name"]
 skip_smoke_tests = d.get("skip_smoke_tests", False)
 assert sut_name in node_map, f"Unknown SUT {sut_name} in execution {d}"
@@ -268,9 +264,7 @@ def from_dict(
 ), f"Invalid TG configuration {traffic_generator_node}"
 
 vdevs = (
-d["system_under_test_node"]["vdevs"]
-if "vdevs" in d["system_under_test_node"]
-else []
+d["system_under_test_node"]["vdevs"] if "vdevs" in 
d["system_under_test_node"] else []
 )
 return ExecutionConfiguration(
 build_targets=build_targets,
@@ -299,9 +293,7 @@ def from_dict(d: dict) -> "Configuration":
 assert len(nodes) == len(node_map), "Duplicate node names are not 
allowed"
 
 executions: list[ExecutionConfiguration] = list(
-map(
-ExecutionConfiguration.from_dict, d["executions"], [node_map 
for _ in d]
-)
+map(ExecutionConfiguration.from_dict, d["executions"], [node_map 
for _ in d])
 )
 
 return Configuration(executions=executions)
@@ -315,9 +307,7 @@ def load_config() -> Configuration:
 with open(SETTINGS.config_file_path, "r") as f:
 config_data = yaml.safe_load(f)
 
-schema_path = os.path.join(
-pathlib.Path(__file__).parent.resolve(), "conf_yaml_schema.json"
-)
+schema_path = os.path.join(pathlib.Path(__file__).parent.resolve(), 
"conf_yaml_schema.json")
 
 with open(schema_path, "r") as f:
 schema = json.load(f)
diff --git a/dts/framework/dts.py b/dts/framework/dts.py
index f773f0c38d..25d6942d81 100644
--- a/dts/framework/dts.py
+++ b/dts/framework/dts.py
@@ -92,9 +92,7 @@ def _run_execution(
 Run the given execution. This involves running the execution setup as well 
as
 running all build targets in the given execution.
 """
-dts_logger.info(
-f"Running execution with SUT 
'{execution.system_under_test_node.name}'."
-)
+dts_logger.info(f"Running execution with SUT 
'{execution.system_under_test_node.name}'.")
 execution_result = result.add_execution(sut_node.config)
 execution_result.add_sut_info(sut_node.node_info)
 
@@ -107,9 +105,7 @@ def _run_execution(
 
 else:
 for build_target in execution.build_targets:
-_run_build_target(
-

[Bug 1301] [dpdk-23.11] meson_tests/driver: core dumped occurred after link_bonding_autotest test

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=1301

Bug ID: 1301
   Summary: [dpdk-23.11] meson_tests/driver: core dumped occurred
after link_bonding_autotest test
   Product: DPDK
   Version: 23.11
  Hardware: x86
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: meson
  Assignee: dev@dpdk.org
  Reporter: songx.ji...@intel.com
  Target Milestone: ---

[Environment]
DPDK version: 
dpdk-23.11：77f913752a55c0262bfda99a1b69ca0bd804c6c7
Other software versions: name/version for QEMU, OVS, etc. Repeat as required.
OS: Ubuntu 22.04.3 LTS/5.15.0-82-generic
Compiler: gcc version 11.4.0
Hardware platform: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
NIC hardware:
Intel Corporation Ethernet Controller E810-C for SFP [8086:1593] (rev 02)
NIC firmware: 
driver: ice
version: 5.15.0-82-generic
firmware-version: 4.40 0x8001af8b 1.3444.0

[Test Setup]
1. compile dpdk
rm -rf x86_64-native-linuxapp-gcc
CC=gcc meson -Denable_kmods=False -Dlibdir=lib --default-library=static
x86_64-native-linuxapp-gcc
ninja -C x86_64-native-linuxapp-gcc -j 72 
2. blind port to vfio-pci
./usertools/dpdk-devbind.py -b vfio-pci 05:00.0 08:00.0
3. start test
DPDK_TEST=link_bonding_autotest MALLOC_PERTURB_=94
/root/dpdk/x86_64-native-linuxapp-gcc/app/dpdk-test -c 0xff -a :05:00.0 -a
:08:00.0

[Show the output from the previous commands.]
 + TestCase [62] : test_broadcast_verify_member_link_status_change_behaviour
succeeded
 + TestCase [63] : test_reconfigure_bonding_device succeeded
 + TestCase [64] : test_close_bonding_device succeeded
Invalid port_id=8
EAL: Test assert remove_members_and_stop_bonding_device line 658 failed: Failed
to stop bonding port 8
 + --- +
 + Test Suite Summary : Link Bonding Unit Test Suite
 + --- +
 + Tests Total :   65
 + Tests Skipped :  0
 + Tests Executed :65
 + Tests Unsupported:   0
 + Tests Passed :  65
 + Tests Failed :   0
 + --- +
Test OK
RTE>>Segmentation fault (core dumped)

[Expected Result]
no core dumped.
 + TestCase [62] : test_broadcast_verify_member_link_status_change_behaviour
succeeded
 + TestCase [63] : test_reconfigure_bonding_device succeeded
 + TestCase [64] : test_close_bonding_device succeeded
Invalid port_id=8
EAL: Test assert remove_members_and_stop_bonding_device line 658 failed: Failed
to stop bonding port 8
 + --- +
 + Test Suite Summary : Link Bonding Unit Test Suite
 + --- +
 + Tests Total :   65
 + Tests Skipped :  0
 + Tests Executed :65
 + Tests Unsupported:   0
 + Tests Passed :  65
 + Tests Failed :   0
 + --- +
Test OK
RTE>>

[Regression]
Is this issue a regression: (Y/N)Y

commit 36c46e738120c381cf663c96692454c5aa75e203
Author: David Marchand 
Date:   Wed Sep 27 13:45:15 2023 +0200

ethdev: cleanup shared data with the last port

If no port is allocated and no port owner is still registered,
ethdev from a primary process may release the memzone used to store
port data.
This makes it possible for the DPDK memory allocator to release
associated resources back to the OS.

Signed-off-by: David Marchand 
Acked-by: Morten Brørup 

 lib/ethdev/ethdev_driver.c  |  6 ++
 lib/ethdev/ethdev_private.c | 21 -
 lib/ethdev/ethdev_private.h |  4 
 lib/ethdev/rte_ethdev.c |  3 +++
 4 files changed, 33 insertions, 1 deletion

-- 
You are receiving this mail because:
You are the assignee for the bug.