Dear community,
There are no Tech Board meetings in August.
Next meeting is September 3rd.
Kind regards,
-Morten Brørup
> From: fengchengwen [mailto:fengcheng...@huawei.com]
> Sent: Tuesday, 5 August 2025 04.10
>
> On 8/4/2025 3:42 AM, Morten Brørup wrote:
> > When an ethdev port is configured for fast mbuf release, the driver can
> > use a TX burst function relying on the fast mbuf release
> From: fengchengwen [mailto:fengcheng...@huawei.com]
> Sent: Tuesday, 5 August 2025 02.59
>
> On 8/4/2025 3:42 AM, Morten Brørup wrote:
> > Enabling some offload by default may conflict with a manually
> configured
> > offload.
> > Specifically, the mbuf fast re
The descriptions of the RX and TX offloads have been improved, to
reflect that they are not only for device capability reporting, but
also for device and queue configuration purposes.
Signed-off-by: Morten Brørup
Acked-by: Bruce Richardson
Acked-by: Andrew Rybchenko
Acked-by: Konstantin
) is not enabled by default anymore.
Signed-off-by: Morten Brørup
---
app/test-pmd/testpmd.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index bb88555328..f00eae3992 100644
--- a/app/test-pmd/testpmd.c
+++ b/app
been added to the ethdev
library, so the drivers don't have to implement them.
Signed-off-by: Morten Brørup
Acked-by: Bruce Richardson
Acked-by: Andrew Rybchenko
Acked-by: Konstantin Ananyev
---
v3:
* Shorten the added log messages. (Stephen Hemminger, Ivan Malov)
---
lib/ethdev/rte_eth
> From: Ivan Malov [mailto:ivan.ma...@arknetworks.am]
> Sent: Saturday, 2 August 2025 23.34
>
> Hi,
>
> On Sat, 2 Aug 2025, Stephen Hemminger wrote:
>
> > On Thu, 31 Jul 2025 09:07:31 +
> > Morten Brørup wrote:
> >
> >> + RTE_ETHDEV
been added to the ethdev
library, so the drivers don't have to implement them.
Signed-off-by: Morten Brørup
Acked-by: Bruce Richardson
Acked-by: Andrew Rybchenko
Acked-by: Konstantin Ananyev
---
lib/ethdev/rte_ethdev.c | 38 ++
1 file changed, 38 inser
The descriptions of the RX and TX offloads have been improved, to
reflect that they are not only for device capability reporting, but
also for device and queue configuration purposes.
Signed-off-by: Morten Brørup
Acked-by: Bruce Richardson
Acked-by: Andrew Rybchenko
Acked-by: Konstantin
) is not enabled by default anymore.
Signed-off-by: Morten Brørup
---
app/test-pmd/testpmd.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index bb88555328..f00eae3992 100644
--- a/app/test-pmd/testpmd.c
+++ b/app
> From: Ivan Malov [mailto:ivan.ma...@arknetworks.am]
> Sent: Thursday, 31 July 2025 11.28
>
> Hi Morten,
>
> On Thu, 31 Jul 2025, Morten Brørup wrote:
>
> > + RTE_ETHDEV_LOG_LINE(ERR,
> > + "Ethdev port_id=%d Tx offload
been added to the ethdev
library, so the drivers don't have to implement them.
Also, the descriptions of the RX and TX offloads have been improved, to
reflect that they are not only for device capability reporting, but also
for device and queue configuration purposes.
Signed-off-by: Morten B
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Wednesday, 30 July 2025 19.29
>
> On Mon, Jul 28, 2025 at 07:48:53PM +0200, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > > Sent: Monday, 28 July 2025 17
Added fast mbuf release, re-using the existing mbuf pool pointer
in the queue structure.
Signed-off-by: Morten Brørup
---
v4:
* Force the generic function called by the separate tx_pkt_burst callbacks
to be inlined.
v3:
* Use separate tx_pkt_burst callbacks depending on per-device TX offload
Added fast mbuf release, re-using the existing mbuf pool pointer
in the queue structure.
Signed-off-by: Morten Brørup
---
v3:
* Use separate tx_pkt_burst callbacks depending on per-device TX offload
configuration. (Ivan Malov, Konstantin Ananyev)
* Check TX offload configuration for mutually
Thanks for cleaning up.
Series-acked-by: Morten Brørup
Ethdev driver maintainers (CC: Ethdev API maintainers),
Your ethdev drivers support RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE, and probably
call rte_mempool_put_bulk() in the mempool lib when FAST_FREE'ing mbufs,
thereby bypassing the mbuf lib.
The appropriate mbuf lib function is rte_mbuf_raw_free_bulk
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Monday, 28 July 2025 17.11
>
> On Mon, Jul 28, 2025 at 04:51:30PM +0200, Morten Brørup wrote:
> > > From: Dean Marx [mailto:dm...@iol.unh.edu]
> > > Sent: Friday, 18 July 2025 15.18
> > >
> From: Konstantin Ananyev [mailto:konstantin.anan...@huawei.com]
> Sent: Monday, 28 July 2025 17.42
>
> > > Hi Morten,
> > >
> > > Good patch. Please see below.
> > >
> > > On Sat, 26 Jul 2025, Morten Brørup wrote:
> > >
> >
> From: Dean Marx [mailto:dm...@iol.unh.edu]
> Sent: Friday, 18 July 2025 15.18
>
> On Fri, Jul 18, 2025 at 4:23 AM Bruce Richardson
> wrote:
> >
> > On Thu, Jul 17, 2025 at 05:03:13PM -0400, Dean Marx wrote:
> > > I've created a v1 of a QinQ test suite around the set of test cases
> > > discusse
> From: Ivan Malov [mailto:ivan.ma...@arknetworks.am]
> Sent: Saturday, 26 July 2025 08.15
>
> Hi Morten,
>
> Good patch. Please see below.
>
> On Sat, 26 Jul 2025, Morten Brørup wrote:
>
> > Added fast mbuf release, re-using the existing mbuf pool p
Added fast mbuf release, re-using the existing mbuf pool pointer
in the queue structure.
Signed-off-by: Morten Brørup
---
v2:
* Also announce the offload as a per-queue capability.
* Added missing test of per-device offload configuration when configuring
the queue.
---
drivers/net/null
capability for FAST_FREE, but ignores device-level
FAST_FREE configuration, and uses queue-level FAST_FREE configuration instead.
Due to this bug, your testing probably shows the performance of the
non-FAST_FREE code path.
The added comparison for FAST_FREE (code path not taken) might explain t
> From: Dengdui Huang [mailto:huangdeng...@huawei.com]
> Sent: Thursday, 24 July 2025 13.26
>
> The worker_id may come from user input. So it is necessary to verify it.
>
> In addition, only the lcore whose role is ROLE_RTE or ROLE_SERVICE can
> be
> launched. This patch adds the lcore role check
l/include/rte_bitops.h
> > @@ -1320,7 +1320,7 @@ rte_is_power_of_2(uint32_t n)
> > * The integer value to align
> > *
> > * @return
> > - * Input parameter aligned to the next power of 2
> > + * The smallest power of 2 which is greater than or equal to @c x.
> > */
>
> Much clearer, thanks.
>
> Acked-by: Bruce Richardson
Acked-by: Morten Brørup
le(uint16_t port_id)
> if (dev->dev_ops->allmulticast_enable == NULL)
> return -ENOTSUP;
> diag = dev->dev_ops->allmulticast_enable(dev);
> - dev->data->all_multicast = (diag == 0) ? 1 : 0;
> + if (diag == 0)
> + dev->data->all_multicast = 1;
>
> diag = eth_err(port_id, diag);
>
> --
> 2.19.0.rc0.windows.1
Acked-by: Morten Brørup
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Monday, 21 July 2025 12.46
>
> 21/07/2025 12:24, Tomasz Duszynski:
> > > On Fri, Jun 27, 2025 at 5:41 PM Tomasz Duszynski
> wrote:
> > > >
> > > > In order to profile app, one needs to store significant amount of
> samples
> > > > somew
directly into a given mempool by a PMD when using
RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE.
The macro __rte_mbuf_raw_sanity_check() has been kept for backwards API
compatibility.
It simply calls __rte_mbuf_raw_sanity_check_mp() without specifying a
mempool.
Signed-off-by: Morten Brørup
---
v3:
* Remov
ntal - function rte_mbuf_raw_sanity_check() is
called when RTE_LIBRTE_MBUF_DEBUG is defined, RTE_LIBRTE_MBUF_DEBUG now
requires ALLOW_EXPERIMENTAL_API until the function's experimental status
is removed.
Signed-off-by: Morten Brørup
---
v2:
* Added explicit build check for ALLOW_EXPERIMENTAL_AP
> From: Ivan Malov [mailto:ivan.ma...@arknetworks.am]
> Sent: Sunday, 20 July 2025 00.30
>
> Hi Morten,
>
> On Sat, 19 Jul 2025, Morten Brørup wrote:
>
> >> From: Morten Brørup [mailto:m...@smartsharesystems.com]
> >> Sent: Saturday, 19 July 2025 12.23
&g
> From: Morten Brørup [mailto:m...@smartsharesystems.com]
> Sent: Monday, 7 July 2025 14.11
>
> > From: Shani Peretz [mailto:shper...@nvidia.com]
> > Sent: Monday, 7 July 2025 07.45
> >
> > > From: Stephen Hemminger
> > > Sent: Monday, 16 June 2025 1
> From: Morten Brørup [mailto:m...@smartsharesystems.com]
> Sent: Saturday, 19 July 2025 12.23
>
> Sanity checking a reinitialized mbuf (a.k.a. raw mbuf) has been
> refactored
> to follow the same design pattern as sanity checking a normal mbuf, and
> now depends on RTE_LIBR
directly into a given mempool by a PMD when using
RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE.
The macro __rte_mbuf_raw_sanity_check() has been kept for backwards API
compatibility.
It simply calls __rte_mbuf_raw_sanity_check_mp() without specifying a
mempool.
Signed-off-by: Morten Brørup
---
lib/mbuf/r
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Wednesday, 16 July 2025 21.47
>
> On Wed, Jul 16, 2025 at 03:24:55PM -0400, Dean Marx wrote:
> > I've created a list of test cases which I'm planning on implementing
> > in future QinQ testing. After talking with Bruce about some
FYI:
Last time I looked, it seemed like the VLAN/QINQ "tag present" mbuf RX flags
were only set along with the RX _STRIPPED flags, i.e. not set when stripping
was not enabled.
Although setting the "tag present" flags (and the vlan_tci/vlan_tci_outer
fields) without stripping would be nice to hav
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Monday, 14 July 2025 15.30
>
> The behaviour of VLAN tag stripping Rx offloads is unclear in DPDK, and
> not very well documented. Even the documentation that does exist appears
> contradictory.
>
> For example, the doxygen docs
For TX mbuf fast release offload, the mbuf mempool pointer will be added
to the ethdev tx queue configuration structure, so the ethdev TX burst
operation doesn't need to fetch it from the first mbuf of each burst being
fast free'd to the mempool.
Signed-off-by: Morten Brørup
---
I assume there is no fine grained control over which features various secondary
processes can access.
Med venlig hilsen / Kind regards,
-Morten Brørup
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Wednesday, 9 July 2025 17.28
>
> On Wed, Jul 09, 2025 at 04:59:51PM +0200, Morten Brørup wrote:
> > Looking at the i40e driver source code, I think it doesn't conform to
> the API when requesting small
Looking at the i40e driver source code, I think it doesn't conform to the API
when requesting small bursts.
Let's say the hardware has received 31 packets.
rte_eth_rx_burst(...,16) will return 16 packets and leave 15 in the driver's
staging buffer (which has capacity for 32 packets).
Time passe
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Wednesday, 9 July 2025 13.44
>
> On Tue, Jul 08, 2025 at 04:15:36PM +0100, Bruce Richardson wrote:
> > On Tue, Jul 08, 2025 at 05:07:05PM +0200, Morten Brørup wrote:
> > > > From: Bruce Ri
truct rte_mp_msg``.
> +
> * lib: will fix extending some enum/define breaking the ABI. There are
> multiple
>samples in DPDK that enum/define terminated with a ``.*MAX.*`` value
> which is
> used by iterators, and arrays holding these values are sized with
> this
> --
> 2.50.0
Yes, please.
Acked-by: Morten Brørup
> From: David Marchand [mailto:david.march...@redhat.com]
> Sent: Tuesday, 8 July 2025 14.28
>
> Fixes: 3340202f5954 ("stack: add lock-free implementation")
> Cc: sta...@dpdk.org
>
> Signed-off-by: David Marchand
> Acked-by: Bruce Richardson
> ---
> - struct rte_stack_lf_head old_head;
> +
hand
> Acked-by: Andrew Rybchenko
> Reviewed-by: Marat Khalili
> ---
Acked-by: Morten Brørup
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Tuesday, 8 July 2025 12.16
>
> On Tue, Jul 08, 2025 at 12:00:42AM +0200, Morten Brørup wrote:
> >From: Vladimir Medvedkin [mailto:medvedk...@gmail.com]
> >Sent: Monday, 7 July 2025 22.10
>
From: Vladimir Medvedkin [mailto:medvedk...@gmail.com]
Sent: Monday, 7 July 2025 22.10
Hi Morten, all,
пн, 7 июл. 2025 г. в 19:09, Morten Brørup :
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Friday, 4 July 2025 13.32
&g
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Friday, 4 July 2025 13.32
> Hi all,
>
> this email discussion comes at a bit of a fortunate time for me, as I'm
> currently looking at our vlan tag/qinq stripping behaviour in our Intel
> NIC
> drivers, and there is some discuss
> From: Mario Kuka [mailto:k...@cesnet.cz]
> Sent: Monday, 7 July 2025 09.51
>
> Introduce a new ptype for identifying slow protocol packets.
>
> Signed-off-by: Mario Kuka
> * <'ether type'=[0x8847|0x8848]>
> */
> #define RTE_PTYPE_L2_ETHER_MPLS 0x000a
> +/**
> + * Ethernet
> From: Shani Peretz [mailto:shper...@nvidia.com]
> Sent: Monday, 7 July 2025 07.45
>
> > From: Stephen Hemminger
> > Sent: Monday, 16 June 2025 18:30
> >
> > On Mon, 16 Jun 2025 10:29:05 +0300
> > Shani Peretz wrote:
> >
> > > This feature is designed to monitor the lifecycle of mempool objects
> From: Konstantin Ananyev [mailto:konstantin.anan...@huawei.com]
> Sent: Friday, 4 July 2025 18.20
>
> > For TX mbuf fast release offload, I propose to add the mbuf mempool
> > pointer to the ethdev tx queue configuration structure,
> > so the ethdev TX burst operation doesn't need to fetch it fr
> From: Dengdui Huang [mailto:huangdeng...@huawei.com]
> Sent: Thursday, 3 July 2025 11.30
>
> The current rte_net_get_ptype() only supports parsing packets with
> one 0x8100 VLAN tag or two 0x88a8 VLAN tags. This patch extends it
> to support parsing packets with two 0x8100 VLAN tags.
>
> Signed
> diff --git a/lib/mbuf/rte_mbuf_ptype.h b/lib/mbuf/rte_mbuf_ptype.h
> index c46a94f89f..66c4eeb954 100644
> --- a/lib/mbuf/rte_mbuf_ptype.h
> +++ b/lib/mbuf/rte_mbuf_ptype.h
> @@ -144,6 +144,13 @@ extern "C" {
> * <'ether type'=[0x8847|0x8848]>
> */
> #define RTE_PTYPE_L2_ETHER_MPLS
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Thursday, 3 July 2025 17.36
>
> On Thu, Jul 03, 2025 at 05:29:26PM +0200, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > > Sent: Thursday, 3 July 2025 17
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Thursday, 3 July 2025 17.21
>
> On Thu, Jul 03, 2025 at 05:12:46PM +0200, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > > Sent: Thursday, 3 July 2025 16
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Thursday, 3 July 2025 16.14
>
> On Thu, Jul 03, 2025 at 03:59:14PM +0200, Morten Brørup wrote:
> > For TX mbuf fast release offload, I propose to add the mbuf mempool
> > pointer to the ethdev tx queue
For TX mbuf fast release offload, I propose to add the mbuf mempool
pointer to the ethdev tx queue configuration structure,
so the ethdev TX burst operation doesn't need to fetch it from the
first mbuf of each burst being fast free'd to the mempool.
This modification of the struct rte_eth_txconf,
> > > I am talking about different thing:
> > > I think with some extra effort driver can use (in some cases)
> > > rte_mbuf_raw_free_bulk() even when
> RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE
> > > is not specified.
> > > Let say we can make txq->fast_free_mp[] an array with the same size
> as txq-
>
> From: huangdengdui [mailto:huangdeng...@huawei.com]
> Sent: Wednesday, 2 July 2025 04.38
>
> Hi everyone,
>
> The current rte_net_get_ptype() only supports parsing packets with a
> single 0x8100 VLAN tag and two 0x88a8 VLAN tags,
> but does not support processing packets with two 0x8100 VLAN t
> From: Konstantin Ananyev [mailto:konstantin.anan...@huawei.com]
> Sent: Tuesday, 1 July 2025 10.16
[...]
> I am talking about different thing:
> I think with some extra effort driver can use (in some cases)
> rte_mbuf_raw_free_bulk() even when RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE
> is not spec
> From: Morten Brørup [mailto:m...@smartsharesystems.com]
> Sent: Monday, 30 June 2025 18.06
>
> > From: Morten Brørup [mailto:m...@smartsharesystems.com]
> > Sent: Monday, 30 June 2025 15.46
> >
> > > From: Konstantin Ananyev [mailto:konstantin.anan...@hua
> From: Morten Brørup [mailto:m...@smartsharesystems.com]
> Sent: Monday, 30 June 2025 15.46
>
> > From: Konstantin Ananyev [mailto:konstantin.anan...@huawei.com]
> > Sent: Monday, 30 June 2025 13.41
> >
> > > When fast releasing mbufs, the mbufs are not acces
f has been freed, so do
> > not reset the pointer.
> > This saves a txep store operation for each TX mbuf freed.
> >
> > Signed-off-by: Morten Brørup
> > ---
> > drivers/net/intel/common/tx.h | 5 +++
> > .../i40e/i40e_recycle_mbufs_
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Friday, 27 June 2025 20.30
>
> 27/06/2025 19:49, Morten Brørup:
> > > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > > Sent: Friday, 27 June 2025 19.35
> > >
> > > 27/06/2025 18:38
> From: Morten Brørup
> Sent: Friday, 27 June 2025 19.51
>
> > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > Sent: Friday, 27 June 2025 19.34
> >
> > 27/06/2025 18:47, Morten Brørup:
> > > > From: Thomas Monjalon [mailto:tho...@monjalon.
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Friday, 27 June 2025 19.34
>
> 27/06/2025 18:47, Morten Brørup:
> > > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > > Sent: Friday, 27 June 2025 17.56
> > >
> > > 24/06/2025 1
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Friday, 27 June 2025 19.35
>
> 27/06/2025 18:38, Morten Brørup:
> > > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > > Sent: Friday, 27 June 2025 17.58
> > >
> > > 24/06/2025
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Friday, 27 June 2025 17.56
>
> 24/06/2025 10:03, Morten Brørup:
> > In eal_mem_set_dump(), when madvise() failed, an incorrect reason was
> > logged.
> >
> > Signed-off-by: Morten Brørup
> >
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Friday, 27 June 2025 17.58
>
> 24/06/2025 10:03, Morten Brørup:
> > + if ((ssize_t)page_size < 0)
> > + rte_panic("sysconf(_SC_PAGESIZE) failed: %s",
> > +
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Thursday, 26 June 2025 16.06
>
> On Tue, 24 Jun 2025 18:14:16 +0000
> Morten Brørup wrote:
>
> > Added fast mbuf release, re-using the existing mbuf pool pointer
> > in the queue structure.
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Thursday, 26 June 2025 16.32
>
> On Thu, 26 Jun 2025 01:55:02 +0200
> Morten Brørup wrote:
>
> > I was wondering if this was somehow possible:
> >
> > #define RTE_VERIFY(exp) d
I was wondering if this was somehow possible:
#define RTE_VERIFY(exp) do { \
+ if (__rte_constant(exp)) \
+ FAIL_AT_BUILD_TIME(); \
if (unlikely(!(exp))) \
rte_panic("line %d\tassert \"%s\" failed\n", __LINE__, #exp); \
} while (0)
I tried static_assert
each burst of fast released TX
mbufs.
The txep->mbuf pointer is not used after the mbuf has been freed, so do
not reset the pointer.
This saves a txep store operation for each TX mbuf freed.
Signed-off-by: Morten Brørup
---
drivers/net/intel/common/tx.h | 5 +++
.../i
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Wednesday, 25 June 2025 12.48
>
> On Tue, Jun 24, 2025 at 06:12:38AM +0000, Morten Brørup wrote:
> > When fast releasing mbufs, the mbufs are not accessed, so do not
> prefetch
> > them.
> > Thi
Added fast mbuf release, re-using the existing mbuf pool pointer
in the queue structure.
Signed-off-by: Morten Brørup
---
drivers/net/null/rte_eth_null.c | 30 +++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/net/null/rte_eth_null.c b/drivers
In eal_mem_set_dump(), when madvise() failed, an incorrect reason was
logged.
Signed-off-by: Morten Brørup
Acked-by: Anatoly Burakov
---
lib/eal/unix/eal_unix_memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/eal/unix/eal_unix_memory.c b/lib/eal/unix
updated
to call rte_mem_page_size() instead.
Except the PMU library, because of its dependency chain. (EAL depends on
PMU, because Trace is part of EAL, and Trace depends on PMU; so PMU cannot
call EAL functions.)
Signed-off-by: Morten Brørup
Acked-by: Anatoly Burakov
---
lib/eal/freebsd/eal.c
depends on PMU; so PMU cannot call EAL functions.)
So mem_page_size(), inspired by rte_mem_page_size(), was added to PMU, and
used instead.
Signed-off-by: Morten Brørup
Acked-by: Anatoly Burakov
---
lib/pmu/pmu.c | 32 ++--
1 file changed, 30 insertions(+), 2 deletions
Coverity reports some defects, where the root cause seems to be negative
return value from sysconf(_SC_PAGESIZE) not being handled.
This series addresses those defects in the DPDK libraries.
PS: "_SC_PAGESIZE" has the alias "_SC_PAGE_SIZE". Both are covered here.
Morten Br
> From: David Marchand [mailto:david.march...@redhat.com]
> Sent: Monday, 23 June 2025 14.08
>
> On Mon, Jun 23, 2025 at 10:53 AM Marat Khalili
> wrote:
> >
> > We cannot just remove __rte_cache_aligned from rte_graph_cluster_stats
> without removing it from rte_graph_cluster_node_stats because o
Don't the Intel i40e and e1000 drivers support RSS on IP addresses [1]?
It looks like they do, but don't report it.
For i40e:
Accepted: 0x2288 FRAG_IPV4 NONFRAG_IPV4_OTHER FRAG_IPV6 NONFRAG_IPV6_OTHER
Unsupported: 0x8104 IPV4 IPV6 IPV6_EX
For e1000:
Accepted: 0x8104 IPV4 IPV6 IPV6_EX
Unsupported:
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Monday, 16 June 2025 17.30
>
> On Mon, 16 Jun 2025 10:29:05 +0300
> Shani Peretz wrote:
>
> > This feature is designed to monitor the lifecycle of mempool objects
> > as they move between the application and the PMD.
> >
> > I
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Wednesday, 18 June 2025 12.28
>
> On Wed, Jun 18, 2025 at 11:47:13AM +0200, Thomas Monjalon wrote:
> > 18/06/2025 09:16, Morten Brørup:
> > > > diff --git a/lib/meson.build b/lib/meson.build
> &
> From: Tomasz Duszynski [mailto:tduszyn...@marvell.com]
> Sent: Wednesday, 18 June 2025 12.23
>
> >> diff --git a/lib/meson.build b/lib/meson.build
> >> index 1934cb4a29..87b567f01b 100644
> >> --- a/lib/meson.build
> >> +++ b/lib/meson.build
> >> @@ -13,7 +13,7 @@ libraries = [
> >> 'kv
> Why are we still building one .so file per DPDK library, instead of just
> building one big dpdk.so for all DPDK libraries?
> I think it's legacy from when DPDK libraries were versioned individually, and
> thus not relevant anymore.
>
> Wouldn't building one big dpdk.so eliminate the problems wi
> diff --git a/lib/meson.build b/lib/meson.build
> index 1934cb4a29..87b567f01b 100644
> --- a/lib/meson.build
> +++ b/lib/meson.build
> @@ -13,7 +13,7 @@ libraries = [
> 'kvargs', # eal depends on kvargs
> 'argparse',
> 'telemetry', # basic info querying
> -'pmu'
Why are we still building one .so file per DPDK library, instead of just
building one big dpdk.so for all DPDK libraries?
I think it's legacy from when DPDK libraries were versioned individually, and
thus not relevant anymore.
Wouldn't building one big dpdk.so eliminate the problems with circula
or Marvell platform and will share.
> >
>
> Hi Morten,
> I got performance numbers on multiple Marvell's platforms and observed gain
> around 0.1% (~20K pps) with this patch. Other than this, there are other fast
> path callbacks (rx_pkt_burst and tx_pkt_burst) which avoid this check.
>
> IMO, this patch has no negative impact and slight improvement & cleanup the
> fast path. Please suggest.
I still like this patch, so I confirm my ACK:
Acked-by: Morten Brørup
> From: Tomasz Duszynski [mailto:tduszyn...@marvell.com]
> Sent: Monday, 16 June 2025 11.49
>
> >16/06/2025 08:53, Tomasz Duszynski:
> >> @@ -86,6 +86,7 @@ always_enable = [
> >> 'ring',
> >> 'stack',
> >> 'telemetry',
> >> +'pmu',
> >> ]
> >
> >This list is alp
brary to the correct location in the meson.build file; it
depends on the EAL, not vice versa.
And an unrelated drive-by minor fix in eal_mem_set_dump():
When madvise() failed, an incorrect reason was logged.
Signed-off-by: Morten Brørup
---
v2:
* Clarify in title and description that only sysc
call rte_mem_page_size() instead.
At this time, no other calls to sysconf() have been found in DPDK.
Also, an unrelated drive-by minor fix in eal_mem_set_dump():
When madvise() failed, an incorrect reason was logged.
Signed-off-by: Morten Brørup
---
lib/eal/freebsd/eal.c | 3 ++-
lib
> 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 Jun
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Monday, 9 June 2025 17.26
>
> On Mon, 9 Jun 2025 14:42:26 +0000
> Morten Brørup wrote:
>
> > @@ -141,8 +141,13 @@ rte_mem_page_size(void)
> > {
> > static size_t page_size;
&g
ity issue: 442155
Calling rte_mempool_ops_dequeue_bulk without checking return value.
Coverity issue: 363744
And an unrelated drive-by fix in eal_mem_set_dump():
When madvise() failed, an incorrect reason was logged.
Signed-off-by: Morten Brørup
---
lib/eal/unix/eal_unix_memory.c |
> 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.
>
> Also added an API to convert the RTE_ETH_LINK_TYPE_XXX
> to a readable string.
>
> Si
Anatoly,
I noticed you are consolidating the Intel NIC drivers into common code, which
is good.
While you are at it, please also consider replacing some ancient code with
functions doing the same:
https://git.dpdk.org/dpdk/tree/drivers/net/intel/common/tx.h#n157
Something like (untested):
sta
C.
> Since only one driver is using this, this patch adds the macro to
> that driver only. It can be moved to some common place if/when
> needed.
This seems to be consensus over adding it to rte_math.h, so:
Acked-by: Morten Brørup
>
> Signed-off-by: Andre Muezerie
> Acked-by: B
> From: Burakov, Anatoly [mailto:anatoly.bura...@intel.com]
> Sent: Thursday, 5 June 2025 11.29
>
> On 6/4/2025 4:59 PM, Bruce Richardson wrote:
> > On Fri, May 30, 2025 at 02:57:19PM +0100, Anatoly Burakov wrote:
> >> Currently, for 32-byte descriptor format, only SSE instruction set
> is
> >> su
> From: David Marchand [mailto:david.march...@redhat.com]
> Sent: Wednesday, 4 June 2025 12.41
>
> On Wed, Jun 4, 2025 at 12:29 PM Morten Brørup
> wrote:
> > > I am not a fan of adding such public API, an internal API would be
> > > enough.
> > >
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Wednesday, 4 June 2025 11.49
>
> On Wed, Jun 04, 2025 at 11:43:01AM +0200, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > > Sent: Wednesday, 4 June 2025 11
> From: David Marchand [mailto:david.march...@redhat.com]
> Sent: Wednesday, 4 June 2025 12.08
>
> On Fri, Mar 14, 2025 at 3:34 PM Andre Muezerie
> wrote:
> >
> > __builtin_add_overflow is gcc specific. There's a need for a portable
> > version that can also be used with other compilers.
> >
> >
1 - 100 of 1490 matches
Mail list logo
