* Re: [PATCH] ethdev: promote experimental API's to stable
From: Stephen Hemminger @ 2026-06-01 15:26 UTC (permalink / raw)
To: David Marchand; +Cc: Andrew Rybchenko, dev, Thomas Monjalon
In-Reply-To: <CAJFAV8ztviupv0rcjvL9MkBQSzY+yfak0RK8GzNbe-8s5JiyEw@mail.gmail.com>
On Mon, 1 Jun 2026 13:55:13 +0200
David Marchand <david.marchand@redhat.com> wrote:
> On Wed, 27 May 2026 at 16:44, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> > + * ``rte_eth_macaddrs_get``
>
> I am not enthousiastic on marking this stable.
> It more or less sets in stone that the mac addresses are stored in an array.
So either we kill it or make it stable, having experimental API for so long
seems like a todo list that never gets done.
^ permalink raw reply
* Re: [PATCH] devtools: add Vertex AI to review scripts
From: Stephen Hemminger @ 2026-06-01 15:11 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: David Marchand, dev, Aaron Conole
In-Reply-To: <bUYoD1-ARAaefqQHkOtV4Q@monjalon.net>
On Mon, 01 Jun 2026 16:21:25 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:
> 01/06/2026 15:24, David Marchand:
> > + if args.auth == "auto":
> > + auth_method = detect_auth_method(args.provider)
> > + else:
> > + auth_method = args.auth
> > +
> > + if auth_method == "vertex":
> > + if not VERTEX_AI_AVAILABLE:
> > + error("Vertex AI support requires 'google-auth' library. Install with: pip install google-auth")
> > + auth = "vertex"
> > + else:
> > + api_key = os.environ.get(config["env_var"])
> > + if not api_key:
> > + error(f"{config['env_var']} environment variable not set")
> > + auth = f"direct:{api_key}"
>
> Could we have such code in the common file?
Yes please add to devtools/ai/_common.py used by both review-doc and review-patch
^ permalink raw reply
* Re: [PATCH] devtools: add Vertex AI to review scripts
From: David Marchand @ 2026-06-01 14:39 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Stephen Hemminger, Aaron Conole
In-Reply-To: <bUYoD1-ARAaefqQHkOtV4Q@monjalon.net>
On Mon, 1 Jun 2026 at 16:21, Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 01/06/2026 15:24, David Marchand:
> > + if args.auth == "auto":
> > + auth_method = detect_auth_method(args.provider)
> > + else:
> > + auth_method = args.auth
> > +
> > + if auth_method == "vertex":
> > + if not VERTEX_AI_AVAILABLE:
> > + error("Vertex AI support requires 'google-auth' library. Install with: pip install google-auth")
> > + auth = "vertex"
> > + else:
> > + api_key = os.environ.get(config["env_var"])
> > + if not api_key:
> > + error(f"{config['env_var']} environment variable not set")
> > + auth = f"direct:{api_key}"
>
> Could we have such code in the common file?
Indeed, I'll wait a bit for more comments before sending a v2.
--
David Marchand
^ permalink raw reply
* Re: [PATCH] net: fix GTP Tunnel parse out-of-bounds read
From: Andrew Rybchenko @ 2026-06-01 14:27 UTC (permalink / raw)
To: Thomas Monjalon, dev, Bruce Richardson, Jerin Jacob,
Hemant Agrawal
Cc: Stephen Hemminger, stable, Jie Hai
In-Reply-To: <-yUhN_HpTAq8QmssYJx54A@monjalon.net>
On 6/1/26 3:59 PM, Thomas Monjalon wrote:
> Any comment about this fix?
>
>
> 09/04/2026 18:15, Stephen Hemminger:
>> If packet is fragmented across multiple mbufs or the packet
>> has only GTP header the code would reference outside
>> the incoming mbuf.
>>
>> Send GTP packet:
>> - Valid GTP header (8 bytes)
>> - msg_type = 0xff
>> - e=1, s=1, pn=1 (sets gtp_len = 12)
>> - Total packet size = 10 bytes
>>
>> Read at gh + 12 accesses 2 bytes beyond packet end.
>>
>> The fix is to use rte_pktmbuf_read in a manner similar
>> to the read of the GTP header.
>>
>> Fixes: 64ed7f854cf4 ("net: add tunnel packet type parsing")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The overall idea LGTM. However one nit in the code.
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>> ---
>> lib/net/rte_net.c | 15 ++++++++++-----
>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/lib/net/rte_net.c b/lib/net/rte_net.c
>> index 458b4814a9..da4018437b 100644
>> --- a/lib/net/rte_net.c
>> +++ b/lib/net/rte_net.c
>> @@ -219,8 +219,7 @@ ptype_tunnel_with_udp(uint16_t *proto, const struct rte_mbuf *m,
>> case RTE_GTPU_UDP_PORT: {
>> const struct rte_gtp_hdr *gh;
>> struct rte_gtp_hdr gh_copy;
>> - uint8_t gtp_len;
>> - uint8_t ip_ver;
>> + uint32_t gtp_len;
>> gh = rte_pktmbuf_read(m, *off, sizeof(*gh), &gh_copy);
>> if (unlikely(gh == NULL))
>> return 0;
>> @@ -231,9 +230,16 @@ ptype_tunnel_with_udp(uint16_t *proto, const struct rte_mbuf *m,
>> * Check message type. If message type is 0xff, it is
>> * a GTP data packet. If not, it is a GTP control packet
>> */
>> + *off += gtp_len;
>> if (gh->msg_type == 0xff) {
>> - ip_ver = *(const uint8_t *)((const char *)gh + gtp_len);
>> - ip_ver = (ip_ver) & 0xf0;
>> + const uint8_t *l3_hdr;
l3_hdr is confusing here. It sounds like a complete layer 3 header, but
it is just one first byte. May be it would be useful to highlight that
it is an inner Layer 3 header.
E.g. inner_l3_hdr_byte (I'm not fully happy with the name too, but
I hope idea is clear)
>> + uint8_t l3_copy, ip_ver;
>> +
>> + l3_hdr = rte_pktmbuf_read(m, *off, sizeof(*l3_hdr), &l3_copy);
sizeof(l3_copy) would be safer here.
>> + if (unlikely(l3_hdr == NULL))
>> + return 0;
>> +
>> + ip_ver = *l3_hdr & 0xf0;
>> if (ip_ver == RTE_GTP_TYPE_IPV4)
>> *proto = rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4);
>> else if (ip_ver == RTE_GTP_TYPE_IPV6)
>> @@ -243,7 +249,6 @@ ptype_tunnel_with_udp(uint16_t *proto, const struct rte_mbuf *m,
>> } else {
>> *proto = 0;
>> }
>> - *off += gtp_len;
>> hdr_lens->inner_l2_len = gtp_len + sizeof(struct rte_udp_hdr);
>> hdr_lens->tunnel_len = gtp_len;
>> if (port_no == RTE_GTPC_UDP_PORT)
>>
>
>
>
>
>
^ permalink raw reply
* RE: [PATCH v6] mempool: improve cache behaviour and performance
From: Morten Brørup @ 2026-06-01 14:27 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Bruce Richardson, dev
In-Reply-To: <6w4sxDwSRYyFMvKExI5ztQ@monjalon.net>
> > > > > Depends-on: patch-163181 ("net/intel: do not bypass mbuf lib
> for
> > > mbuf
> > > > > fast-free")
> > > >
> > > > This dependency seems to cause CI apply failures.
> > > > The dependency is based on an older snapshot of main,
> > > > and this patch is based on a new snapshot of main.
> > >
> > > The dependency should be resolved now.
> > > Please could you send a v7?
> > >
> >
> > I'm not 100 % sure, but I think the problem is CI only...
> >
> > This patch is based on main, so it should apply as-is.
> >
> > Bruce has already applied the other patch (that this one depends on)
> to the intel-next-net tree.
> > The other patch is based on an older snapshot of main, so when using
> "Depends-on", I guess the CI bases its series on the other patch; and
> then the CI fails to apply this patch (because it's based on a newer
> snapshot of main).
>
> The patch is in main since last week.
>
> So you could send a new version with the ack and it will run in CI.
>
OK. Will do.
^ permalink raw reply
* Re: [PATCH] devtools: add Vertex AI to review scripts
From: Thomas Monjalon @ 2026-06-01 14:21 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Stephen Hemminger, Aaron Conole
In-Reply-To: <20260601132402.1125588-1-david.marchand@redhat.com>
01/06/2026 15:24, David Marchand:
> + if args.auth == "auto":
> + auth_method = detect_auth_method(args.provider)
> + else:
> + auth_method = args.auth
> +
> + if auth_method == "vertex":
> + if not VERTEX_AI_AVAILABLE:
> + error("Vertex AI support requires 'google-auth' library. Install with: pip install google-auth")
> + auth = "vertex"
> + else:
> + api_key = os.environ.get(config["env_var"])
> + if not api_key:
> + error(f"{config['env_var']} environment variable not set")
> + auth = f"direct:{api_key}"
Could we have such code in the common file?
^ permalink raw reply
* Re: [PATCH v6] mempool: improve cache behaviour and performance
From: Thomas Monjalon @ 2026-06-01 14:19 UTC (permalink / raw)
To: Morten Brørup
Cc: Bruce Richardson, dev, Andrew Rybchenko, Jingjing Wu,
Praveen Shetty, Hemant Agrawal, Sachin Saxena
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F658CC@smartserver.smartshare.dk>
01/06/2026 15:51, Morten Brørup:
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > Sent: Monday, 1 June 2026 15.36
> >
> > 26/05/2026 18:00, Morten Brørup:
> > > > From: Morten Brørup [mailto:mb@smartsharesystems.com]
> > > > Sent: Tuesday, 26 May 2026 16.00
> > > >
> > > > This patch refactors the mempool cache to eliminate some unexpected
> > > > behaviour and reduce the mempool cache miss rate.
> > > >
> > > > 1.
> > > > The actual cache size was 1.5 times the cache size specified at
> > run-
> > > > time
> > > > mempool creation.
> > > > This was obviously not expected by application developers.
> > > >
> > > > 2.
> > > > In get operations, the check for when to use the cache as bounce
> > buffer
> > > > did not respect the run-time configured cache size,
> > > > but compared to the build time maximum possible cache size
> > > > (RTE_MEMPOOL_CACHE_MAX_SIZE, default 512).
> > > > E.g. with a configured cache size of 32 objects, getting 256
> > objects
> > > > would first fetch 32 + 256 = 288 objects into the cache,
> > > > and then move the 256 objects from the cache to the destination
> > memory,
> > > > instead of fetching the 256 objects directly to the destination
> > memory.
> > > > This had a performance cost.
> > > > However, this is unlikely to occur in real applications, so it is
> > not
> > > > important in itself.
> > > >
> > > > 3.
> > > > When putting objects into a mempool, and the mempool cache did not
> > have
> > > > free space for so many objects,
> > > > the cache was flushed completely, and the new objects were then put
> > > > into
> > > > the cache.
> > > > I.e. the cache drain level was zero.
> > > > This (complete cache flush) meant that a subsequent get operation
> > (with
> > > > the same number of objects) completely emptied the cache,
> > > > so another subsequent get operation required replenishing the
> > cache.
> > > >
> > > > Similarly,
> > > > When getting objects from a mempool, and the mempool cache did not
> > hold
> > > > so
> > > > many objects,
> > > > the cache was replenished to cache->size + remaining objects,
> > > > and then (the remaining part of) the requested objects were fetched
> > via
> > > > the cache,
> > > > which left the cache filled (to cache->size) at completion.
> > > > I.e. the cache refill level was cache->size (plus some, depending
> > on
> > > > request size).
> > > >
> > > > (1) was improved by generally comparing to cache->size instead of
> > > > cache->flushthresh, when considering the capacity of the cache.
> > > > The cache->flushthresh field is kept for API/ABI compatibility
> > > > purposes,
> > > > and initialized to cache->size instead of cache->size * 1.5.
> > > >
> > > > (2) was improved by generally comparing to cache->size / 2 instead
> > of
> > > > RTE_MEMPOOL_CACHE_MAX_SIZE, when checking the bounce buffer limit.
> > > >
> > > > (3) was improved by flushing and replenishing the cache by half its
> > > > size,
> > > > so a flush/refill can be followed randomly by get or put requests.
> > > > This also reduced the number of objects in each flush/refill
> > operation.
> > > >
> > > > As a consequence of these changes, the size of the array holding
> > the
> > > > objects in the cache (cache->objs[]) no longer needs to be
> > > > 2 * RTE_MEMPOOL_CACHE_MAX_SIZE, and can be reduced to
> > > > RTE_MEMPOOL_CACHE_MAX_SIZE at an API/ABI breaking release.
> >
> > I'm not sure why waiting?
>
> Because the rte_mempool_cache structure holding the array is part of the public API:
> https://elixir.bootlin.com/dpdk/v26.03/source/lib/mempool/rte_mempool.h#L113
>
> abidiff complained about it in v1, so I reverted the array size reduction in v2.
>
> >
> >
> > > > Performance data:
> > > > With a real WAN Optimization application, where the number of
> > allocated
> > > > packets varies (as they are held in e.g. shaper queues), the
> > mempool
> > > > cache miss rate dropped from ca. 1/20 objects to ca. 1/48 objects.
> > > > This was deployed in production at an ISP, and using an effective
> > cache
> > > > size of 384 objects.
> > > >
> > > > Bugzilla ID: 1027
> > > > Fixes: ea5dd2744b90 ("mempool: cache optimisations")
> > > > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > >
> > > Forgot carrying an Ack over from v5:
> > > Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> > >
> > > > ---
> > > > Depends-on: patch-163181 ("net/intel: do not bypass mbuf lib for
> > mbuf
> > > > fast-free")
> > >
> > > This dependency seems to cause CI apply failures.
> > > The dependency is based on an older snapshot of main,
> > > and this patch is based on a new snapshot of main.
> >
> > The dependency should be resolved now.
> > Please could you send a v7?
> >
>
> I'm not 100 % sure, but I think the problem is CI only...
>
> This patch is based on main, so it should apply as-is.
>
> Bruce has already applied the other patch (that this one depends on) to the intel-next-net tree.
> The other patch is based on an older snapshot of main, so when using "Depends-on", I guess the CI bases its series on the other patch; and then the CI fails to apply this patch (because it's based on a newer snapshot of main).
The patch is in main since last week.
So you could send a new version with the ack and it will run in CI.
^ permalink raw reply
* RE: [PATCH v11] eal/x86: optimize memcpy of small sizes
From: Morten Brørup @ 2026-06-01 14:19 UTC (permalink / raw)
To: Thomas Monjalon, Stephen Hemminger, Bruce Richardson,
Konstantin Ananyev
Cc: dev, Konstantin Ananyev, Vipin Varghese, Liangxing Wang,
Thiyagarajan P, Bala Murali Krishna, Anatoly Burakov,
Vladimir Medvedkin
In-Reply-To: <JAYuDo5qT4OWJH9lfTRFKA@monjalon.net>
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Monday, 1 June 2026 15.38
>
> 22/05/2026 00:42, Stephen Hemminger:
> > On Thu, 21 May 2026 18:56:31 +0000
> > Morten Brørup <mb@smartsharesystems.com> wrote:
> >
> > > The implementation for copying up to 64 bytes does not depend on
> address
> > > alignment with the size of the CPU's vector registers. Nonetheless,
> the
> > > exact same code for copying up to 64 bytes was present in both the
> aligned
> > > copy function and all the CPU vector register size specific
> variants of
> > > the unaligned copy functions.
> > > With this patch, the implementation for copying up to 64 bytes was
> > > consolidated into one instance, located in the common copy
> function,
> > > before checking alignment requirements.
> > > This provides three benefits:
> > > 1. No copy-paste in the source code.
> > > 2. A performance gain for copying up to 64 bytes, because the
> > > address alignment check is avoided in this case.
> > > 3. Reduced instruction memory footprint, because the compiler only
> > > generates one instance of the function for copying up to 64 bytes,
> instead
> > > of two instances (one in the unaligned copy function, and one in
> the
> > > aligned copy function).
> > >
> > > Furthermore, __rte_restrict was added to source and destination
> addresses.
> > >
> > > Also, the missing implementation of rte_mov48() was added.
> > >
> > > Until recently, some drivers required disabling stringop-overflow
> warnings
> > > when using rte_memcpy().
> > > For some strange reason, these warnings were disabled in the
> rte_memcpy
> > > header file, instead of in the problematic drivers.
> > > With series-38174 ("remove use of rte_memcpy from net/intel"), the
> > > problematic drivers were updated to use memcpy() instead of
> rte_memcpy(),
> > > so disabling these warnings is no longer required, and was removed.
> > >
> > > Regarding performance...
> > > The memcpy performance test (cache-to-cache copy) shows:
> > > Copying up to 15 bytes takes ca. 4.5 cycles, versus ca. 6.5 cycles
> before.
> > > Copying 8 bytes takes 4 cycles, versus 7 cycles before.
> > > Copying 16 bytes takes 2 cycles, versus 4 cycles before.
> > > Copying 64 bytes takes 4 cycles, versus 7 cycles before.
> > >
> > > Depends-on: series-38174 ("remove use of rte_memcpy from
> net/intel")
> > >
> > > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > > Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> > > Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> >
> > Here is the full wordy all providers reviews.
> [...]
> > Summary across 4 provider(s): clean=0 warnings=1 errors=3 failed=0
>
> What is the followup?
AI wants me to fix existing code.
I had chosen to stick to the file's existing coding style etc., including some unnecessary type casts.
So AI also complains about my code doing things the same way existing code in the file does it.
Fixing existing code is out of scope for this patch. And using a different style for my changes would be confusing.
The patch description mentions that stringop-overflow warnings are no longer disabled for rte_mempcy().
AI wants this to go into the release notes (although it is x86 architecture only).
But IMO, this is far below the threshold for what should go into the release notes.
> Do we target DPDK 26.07?
IMO, yes, this v11 patch is good.
^ permalink raw reply
* RE: [PATCH v6] mempool: improve cache behaviour and performance
From: Morten Brørup @ 2026-06-01 13:51 UTC (permalink / raw)
To: Thomas Monjalon, Bruce Richardson
Cc: dev, Andrew Rybchenko, Jingjing Wu, Praveen Shetty,
Hemant Agrawal, Sachin Saxena
In-Reply-To: <0b8SMRhASVKQeU9e_kqJHQ@monjalon.net>
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Monday, 1 June 2026 15.36
>
> 26/05/2026 18:00, Morten Brørup:
> > > From: Morten Brørup [mailto:mb@smartsharesystems.com]
> > > Sent: Tuesday, 26 May 2026 16.00
> > >
> > > This patch refactors the mempool cache to eliminate some unexpected
> > > behaviour and reduce the mempool cache miss rate.
> > >
> > > 1.
> > > The actual cache size was 1.5 times the cache size specified at
> run-
> > > time
> > > mempool creation.
> > > This was obviously not expected by application developers.
> > >
> > > 2.
> > > In get operations, the check for when to use the cache as bounce
> buffer
> > > did not respect the run-time configured cache size,
> > > but compared to the build time maximum possible cache size
> > > (RTE_MEMPOOL_CACHE_MAX_SIZE, default 512).
> > > E.g. with a configured cache size of 32 objects, getting 256
> objects
> > > would first fetch 32 + 256 = 288 objects into the cache,
> > > and then move the 256 objects from the cache to the destination
> memory,
> > > instead of fetching the 256 objects directly to the destination
> memory.
> > > This had a performance cost.
> > > However, this is unlikely to occur in real applications, so it is
> not
> > > important in itself.
> > >
> > > 3.
> > > When putting objects into a mempool, and the mempool cache did not
> have
> > > free space for so many objects,
> > > the cache was flushed completely, and the new objects were then put
> > > into
> > > the cache.
> > > I.e. the cache drain level was zero.
> > > This (complete cache flush) meant that a subsequent get operation
> (with
> > > the same number of objects) completely emptied the cache,
> > > so another subsequent get operation required replenishing the
> cache.
> > >
> > > Similarly,
> > > When getting objects from a mempool, and the mempool cache did not
> hold
> > > so
> > > many objects,
> > > the cache was replenished to cache->size + remaining objects,
> > > and then (the remaining part of) the requested objects were fetched
> via
> > > the cache,
> > > which left the cache filled (to cache->size) at completion.
> > > I.e. the cache refill level was cache->size (plus some, depending
> on
> > > request size).
> > >
> > > (1) was improved by generally comparing to cache->size instead of
> > > cache->flushthresh, when considering the capacity of the cache.
> > > The cache->flushthresh field is kept for API/ABI compatibility
> > > purposes,
> > > and initialized to cache->size instead of cache->size * 1.5.
> > >
> > > (2) was improved by generally comparing to cache->size / 2 instead
> of
> > > RTE_MEMPOOL_CACHE_MAX_SIZE, when checking the bounce buffer limit.
> > >
> > > (3) was improved by flushing and replenishing the cache by half its
> > > size,
> > > so a flush/refill can be followed randomly by get or put requests.
> > > This also reduced the number of objects in each flush/refill
> operation.
> > >
> > > As a consequence of these changes, the size of the array holding
> the
> > > objects in the cache (cache->objs[]) no longer needs to be
> > > 2 * RTE_MEMPOOL_CACHE_MAX_SIZE, and can be reduced to
> > > RTE_MEMPOOL_CACHE_MAX_SIZE at an API/ABI breaking release.
>
> I'm not sure why waiting?
Because the rte_mempool_cache structure holding the array is part of the public API:
https://elixir.bootlin.com/dpdk/v26.03/source/lib/mempool/rte_mempool.h#L113
abidiff complained about it in v1, so I reverted the array size reduction in v2.
>
>
> > > Performance data:
> > > With a real WAN Optimization application, where the number of
> allocated
> > > packets varies (as they are held in e.g. shaper queues), the
> mempool
> > > cache miss rate dropped from ca. 1/20 objects to ca. 1/48 objects.
> > > This was deployed in production at an ISP, and using an effective
> cache
> > > size of 384 objects.
> > >
> > > Bugzilla ID: 1027
> > > Fixes: ea5dd2744b90 ("mempool: cache optimisations")
> > > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> >
> > Forgot carrying an Ack over from v5:
> > Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> >
> > > ---
> > > Depends-on: patch-163181 ("net/intel: do not bypass mbuf lib for
> mbuf
> > > fast-free")
> >
> > This dependency seems to cause CI apply failures.
> > The dependency is based on an older snapshot of main,
> > and this patch is based on a new snapshot of main.
>
> The dependency should be resolved now.
> Please could you send a v7?
>
I'm not 100 % sure, but I think the problem is CI only...
This patch is based on main, so it should apply as-is.
Bruce has already applied the other patch (that this one depends on) to the intel-next-net tree.
The other patch is based on an older snapshot of main, so when using "Depends-on", I guess the CI bases its series on the other patch; and then the CI fails to apply this patch (because it's based on a newer snapshot of main).
^ permalink raw reply
* Re: [PATCH v2] ring: add cache guard after ring elements table
From: Thomas Monjalon @ 2026-06-01 13:49 UTC (permalink / raw)
To: Morten Brørup
Cc: dev, Konstantin Ananyev, Wathsala Vithanage, Konstantin Ananyev
In-Reply-To: <20260505161329.258182-1-mb@smartsharesystems.com>
05/05/2026 18:13, Morten Brørup:
> Added cache guard after the table holding the ring elements, to avoid
> false sharing conflicts caused by next-line hardware prefetchers when
> accessing elements at the end of the ring table.
>
> Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
Acked-by: Wathsala Vithanage <wathsala.vithanage@arm.com>
Applied, thanks.
^ permalink raw reply
* [PATCH] devtools: add Vertex AI to review scripts
From: David Marchand @ 2026-06-01 13:24 UTC (permalink / raw)
To: dev; +Cc: thomas, Stephen Hemminger, Aaron Conole
Add support for Google Vertex AI authentication as an alternative to
direct API key authentication. All four providers (Anthropic, Google,
OpenAI, xAI) can now use Vertex AI with Application Default Credentials.
This requires a python dependency google-auth but it is left as
optional.
Key features:
- Auto-detection of authentication method based on environment
- Manual override via --auth flag (auto, direct, vertex)
- Automatic model name translation for Vertex format
- Support for both global and regional Vertex endpoints
- Proper error handling for Vertex API responses
Provider-specific implementations:
- Anthropic: Uses /publishers/anthropic/models/{model}:rawPredict
with model name format claude-sonnet-4-5@20250929
- Google: Uses /publishers/google/models/{model}:generateContent
- OpenAI/xAI: Use /endpoints/openapi/chat/completions
with publisher prefix (e.g., openai/gpt-oss-120b-maas)
Authentication detection logic:
- Vertex: Requires google-auth library and ADC configured
- Direct: Falls back to API key from environment variables
Available models on Vertex AI:
- Anthropic: All Claude models
- Google: All Gemini models
- OpenAI: gpt-oss-120b-maas, gpt-oss-20b-maas (open-weight only)
- xAI: grok-4.20-*, grok-4.1-fast-* variants
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
Note: I only tested Vertex work.
I have no API key to double check the "direct" method is still working.
---
devtools/ai/_common.py | 166 ++++++++++++++++++++++++++++++++----
devtools/ai/review-doc.py | 35 ++++++--
devtools/ai/review-patch.py | 39 ++++++---
3 files changed, 205 insertions(+), 35 deletions(-)
diff --git a/devtools/ai/_common.py b/devtools/ai/_common.py
index 69982cbda5..0c1257842f 100644
--- a/devtools/ai/_common.py
+++ b/devtools/ai/_common.py
@@ -6,6 +6,7 @@
import argparse
import json
+import os
import subprocess
import sys
from dataclasses import dataclass
@@ -13,6 +14,14 @@
from urllib.error import HTTPError, URLError
from urllib.request import Request, urlopen
+# Optional dependency for Vertex AI
+try:
+ from google.auth import default as google_auth_default
+ from google.auth.transport.requests import Request as GoogleAuthRequest
+ VERTEX_AI_AVAILABLE = True
+except ImportError:
+ VERTEX_AI_AVAILABLE = False
+
# Provider configurations (model defaults; override with --model).
PROVIDERS: dict[str, dict[str, str]] = {
"anthropic": {
@@ -128,25 +137,137 @@ def print_token_summary(
print(format_token_summary(usage, provider, model), file=sys.stderr)
+def get_vertex_credentials() -> tuple[str, str]:
+ """Get Google Cloud access token and project for Vertex AI.
+
+ Uses Application Default Credentials (ADC).
+ Requires: gcloud auth application-default login
+
+ Returns: (access_token, project_id)
+ """
+ credentials, project = google_auth_default()
+
+ # Refresh credentials to get access token
+ auth_request = GoogleAuthRequest()
+ credentials.refresh(auth_request)
+
+ if not project:
+ error("Could not detect GCP project. Set GOOGLE_CLOUD_PROJECT environment variable or run: gcloud config set project PROJECT_ID")
+
+ return credentials.token, project
+
+
+def model_to_vertex(model: str, provider: str) -> str:
+ """Convert model name to Vertex AI format.
+
+ Anthropic models use @ for version dates:
+ - API format: claude-sonnet-4-5-20250929
+ - Vertex format: claude-sonnet-4-5@20250929
+
+ OpenAI/xAI models need publisher prefix:
+ - Vertex requires: openai/gpt-oss-120b-maas
+
+ Other providers use the same format for both.
+ """
+ if provider == "anthropic":
+ # Match pattern: ends with -YYYYMMDD (8 digits)
+ if model.count('-') >= 3:
+ parts = model.rsplit('-', 1)
+ if len(parts) == 2 and len(parts[1]) == 8 and parts[1].isdigit():
+ return f"{parts[0]}@{parts[1]}"
+ elif provider in ("openai", "xai"):
+ # Add publisher prefix if not already present
+ if "/" not in model:
+ return f"{provider}/{model}"
+ return model
+
+
+def detect_auth_method(provider: str) -> str:
+ """Detect authentication method for a provider.
+
+ Args:
+ provider: The provider name (e.g., "anthropic", "openai")
+
+ Returns:
+ "direct" or "vertex"
+ """
+ env_var = PROVIDERS[provider]["env_var"]
+ if os.environ.get(env_var):
+ return "direct"
+ if VERTEX_AI_AVAILABLE:
+ try:
+ credentials, project = google_auth_default()
+ if credentials and project:
+ return "vertex"
+ except Exception:
+ pass
+ return "direct"
+
+
def _build_request_meta(
- provider: str, api_key: str, model: str
-) -> tuple[str, dict[str, str]]:
- """Return (url, headers) for a provider request."""
+ provider: str, auth: str, model: str, request_data: dict[str, Any]
+) -> tuple[str, dict[str, str], dict[str, Any]]:
+ """Return (url, headers, request_data) for a provider request.
+
+ Args:
+ provider: Provider name
+ auth: Authentication string - either "direct:<api_key>" or "vertex"
+ model: Model identifier
+ request_data: The request payload (may be modified for Vertex)
+
+ Returns:
+ Tuple of (url, headers, modified_request_data)
+ """
config = PROVIDERS[provider]
- if provider == "anthropic":
+
+ if auth.startswith("direct:"):
+ api_key = auth[7:]
+ if provider == "anthropic":
+ request_data["model"] = model
+ return config["endpoint"], {
+ "Content-Type": "application/json",
+ "x-api-key": api_key,
+ "anthropic-version": "2023-06-01",
+ }, request_data
+ if provider == "google":
+ url = f"{config['endpoint']}/{model}:generateContent?key={api_key}"
+ return url, {"Content-Type": "application/json"}, request_data
+ # openai, xai
+ request_data["model"] = model
return config["endpoint"], {
"Content-Type": "application/json",
- "x-api-key": api_key,
- "anthropic-version": "2023-06-01",
- }
- if provider == "google":
- url = f"{config['endpoint']}/{model}:generateContent?key={api_key}"
- return url, {"Content-Type": "application/json"}
- # openai, xai
- return config["endpoint"], {
+ "Authorization": f"Bearer {api_key}",
+ }, request_data
+
+ # Vertex AI authentication
+ if auth != "vertex":
+ error(f"Invalid auth format: {auth}")
+
+ access_token, project_id = get_vertex_credentials()
+ project_id = os.environ.get("GOOGLE_CLOUD_PROJECT") or os.environ.get("GCP_PROJECT") or project_id
+ location = os.environ.get("CLOUD_ML_REGION", "global")
+
+ if location == "global":
+ vertex_base = f"https://aiplatform.googleapis.com/v1/projects/{project_id}/locations/{location}"
+ else:
+ vertex_base = f"https://{location}-aiplatform.googleapis.com/v1/projects/{project_id}/locations/{location}"
+
+ headers = {
"Content-Type": "application/json",
- "Authorization": f"Bearer {api_key}",
+ "Authorization": f"Bearer {access_token}",
}
+ vertex_model = model_to_vertex(model, provider)
+
+ if provider == "anthropic":
+ request_data["anthropic_version"] = "vertex-2023-10-16"
+ url = f"{vertex_base}/publishers/anthropic/models/{vertex_model}:rawPredict"
+ elif provider == "google":
+ url = f"{vertex_base}/publishers/google/models/{vertex_model}:generateContent"
+ else: # openai, xai
+ request_data["model"] = vertex_model
+ url = f"{vertex_base}/endpoints/openapi/chat/completions"
+
+ return url, headers, request_data
def _extract_usage(provider: str, result: dict[str, Any]) -> TokenUsage:
@@ -208,7 +329,7 @@ def _print_verbose_usage(usage: TokenUsage) -> None:
def send_request(
provider: str,
- api_key: str,
+ auth: str,
model: str,
request_data: dict[str, Any],
*,
@@ -220,8 +341,19 @@ def send_request(
The caller assembles the provider-specific request body via its own
build_*_request helpers (the prompts differ per script). This function
handles transport, error reporting, and token-usage extraction.
+
+ Args:
+ provider: Provider name (anthropic, openai, xai, google)
+ auth: Authentication string - either "direct:<api_key>" or "vertex"
+ model: Model identifier
+ request_data: Provider-specific request payload
+ timeout: Request timeout in seconds
+ verbose: Show detailed token usage
+
+ Returns:
+ Tuple of (response_text, token_usage)
"""
- url, headers = _build_request_meta(provider, api_key, model)
+ url, headers, request_data = _build_request_meta(provider, auth, model, request_data)
body = json.dumps(request_data).encode("utf-8")
req = Request(url, data=body, headers=headers)
@@ -232,6 +364,8 @@ def send_request(
error_body = e.read().decode("utf-8")
try:
error_data = json.loads(error_body)
+ if isinstance(error_data, list) and error_data:
+ error_data = error_data[0]
error(f"API error: {error_data.get('error', error_body)}")
except json.JSONDecodeError:
error(f"API error ({e.code}): {error_body}")
@@ -239,6 +373,8 @@ def send_request(
if isinstance(e.reason, TimeoutError):
error(f"Request timed out after {timeout} seconds")
error(f"Connection error: {e.reason}")
+ except TimeoutError:
+ error(f"Request timed out after {timeout} seconds")
usage = _extract_usage(provider, result)
if verbose:
diff --git a/devtools/ai/review-doc.py b/devtools/ai/review-doc.py
index 24e70ae06b..ee02c7ee40 100755
--- a/devtools/ai/review-doc.py
+++ b/devtools/ai/review-doc.py
@@ -24,8 +24,10 @@
from _common import (
PROVIDERS,
+ VERTEX_AI_AVAILABLE,
TokenUsage,
add_token_args,
+ detect_auth_method,
error,
get_git_config,
list_providers,
@@ -273,7 +275,6 @@ def build_anthropic_request(
doc_file, commit_prefix, output_format, include_diff_markers
)
return {
- "model": model,
"max_tokens": max_tokens,
"system": [
{"type": "text", "text": SYSTEM_PROMPT},
@@ -307,7 +308,6 @@ def build_openai_request(
doc_file, commit_prefix, output_format, include_diff_markers
)
return {
- "model": model,
"max_tokens": max_tokens,
"messages": [
{"role": "system", "content": SYSTEM_PROMPT},
@@ -352,7 +352,7 @@ def build_google_request(
def call_api(
provider: str,
- api_key: str,
+ auth: str,
model: str,
max_tokens: int,
agents_content: str,
@@ -399,7 +399,7 @@ def call_api(
)
return send_request(
provider,
- api_key,
+ auth,
model,
request_data,
timeout=timeout,
@@ -631,6 +631,12 @@ def main() -> None:
help="Show API request details",
)
add_token_args(parser)
+ parser.add_argument(
+ "--auth",
+ choices=["auto", "direct", "vertex"],
+ default="auto",
+ help="Authentication method: auto (default), direct (API key), vertex (Google Cloud)",
+ )
parser.add_argument(
"-q",
"--quiet",
@@ -709,10 +715,20 @@ def main() -> None:
config = PROVIDERS[args.provider]
model = args.model or config["default_model"]
- # Get API key
- api_key = os.environ.get(config["env_var"])
- if not api_key:
- error(f"{config['env_var']} environment variable not set")
+ if args.auth == "auto":
+ auth_method = detect_auth_method(args.provider)
+ else:
+ auth_method = args.auth
+
+ if auth_method == "vertex":
+ if not VERTEX_AI_AVAILABLE:
+ error("Vertex AI support requires 'google-auth' library. Install with: pip install google-auth")
+ auth = "vertex"
+ else:
+ api_key = os.environ.get(config["env_var"])
+ if not api_key:
+ error(f"{config['env_var']} environment variable not set")
+ auth = f"direct:{api_key}"
# Validate files
agents_path = Path(args.agents)
@@ -783,6 +799,7 @@ def main() -> None:
if args.verbose:
print("=== Request ===", file=sys.stderr)
print(f"Provider: {args.provider}", file=sys.stderr)
+ print(f"Auth method: {auth_method}", file=sys.stderr)
print(f"Model: {model}", file=sys.stderr)
print(f"Output format: {args.output_format}", file=sys.stderr)
print(f"AGENTS file: {args.agents}", file=sys.stderr)
@@ -800,7 +817,7 @@ def main() -> None:
# Call API
review_text, call_usage = call_api(
args.provider,
- api_key,
+ auth,
model,
args.tokens,
agents_content,
diff --git a/devtools/ai/review-patch.py b/devtools/ai/review-patch.py
index 52601ac156..8f2ce85a12 100755
--- a/devtools/ai/review-patch.py
+++ b/devtools/ai/review-patch.py
@@ -22,8 +22,10 @@
from _common import (
PROVIDERS,
+ VERTEX_AI_AVAILABLE,
TokenUsage,
add_token_args,
+ detect_auth_method,
error,
get_git_config,
list_providers,
@@ -474,7 +476,6 @@ def build_anthropic_request(
patch_name=patch_name, format_instruction=format_instruction
)
return {
- "model": model,
"max_tokens": max_tokens,
"system": [
{"type": "text", "text": system_prompt},
@@ -508,7 +509,6 @@ def build_openai_request(
patch_name=patch_name, format_instruction=format_instruction
)
return {
- "model": model,
"max_tokens": max_tokens,
"messages": [
{"role": "system", "content": system_prompt},
@@ -553,7 +553,7 @@ def build_google_request(
def call_api(
provider: str,
- api_key: str,
+ auth: str,
model: str,
max_tokens: int,
system_prompt: str,
@@ -596,7 +596,7 @@ def call_api(
)
return send_request(
provider,
- api_key,
+ auth,
model,
request_data,
timeout=timeout,
@@ -813,6 +813,12 @@ def main() -> None:
help="Show API request details",
)
add_token_args(parser)
+ parser.add_argument(
+ "--auth",
+ choices=["auto", "direct", "vertex"],
+ default="auto",
+ help="Authentication method: auto (default), direct (API key), vertex (Google Cloud)",
+ )
parser.add_argument(
"-f",
"--format",
@@ -930,10 +936,20 @@ def main() -> None:
config = PROVIDERS[args.provider]
model = args.model or config["default_model"]
- # Get API key
- api_key = os.environ.get(config["env_var"])
- if not api_key:
- error(f"{config['env_var']} environment variable not set")
+ if args.auth == "auto":
+ auth_method = detect_auth_method(args.provider)
+ else:
+ auth_method = args.auth
+
+ if auth_method == "vertex":
+ if not VERTEX_AI_AVAILABLE:
+ error("Vertex AI support requires 'google-auth' library. Install with: pip install google-auth")
+ auth = "vertex"
+ else:
+ api_key = os.environ.get(config["env_var"])
+ if not api_key:
+ error(f"{config['env_var']} environment variable not set")
+ auth = f"direct:{api_key}"
# Validate files
agents_path = Path(args.agents)
@@ -1041,7 +1057,7 @@ def main() -> None:
review_text, call_usage = call_api(
args.provider,
- api_key,
+ auth,
model,
args.tokens,
system_prompt,
@@ -1111,7 +1127,7 @@ def main() -> None:
review_text, call_usage = call_api(
args.provider,
- api_key,
+ auth,
model,
args.tokens,
system_prompt,
@@ -1136,6 +1152,7 @@ def main() -> None:
if args.verbose:
print("=== Request ===", file=sys.stderr)
print(f"Provider: {args.provider}", file=sys.stderr)
+ print(f"Auth method: {auth_method}", file=sys.stderr)
print(f"Model: {model}", file=sys.stderr)
print(f"Review date: {review_date}", file=sys.stderr)
if args.release:
@@ -1164,7 +1181,7 @@ def main() -> None:
if estimated_tokens > 0: # Not already processed
review_text, call_usage = call_api(
args.provider,
- api_key,
+ auth,
model,
args.tokens,
system_prompt,
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v11] eal/x86: optimize memcpy of small sizes
From: Thomas Monjalon @ 2026-06-01 13:38 UTC (permalink / raw)
To: Morten Brørup
Cc: dev, Bruce Richardson, Konstantin Ananyev, Vipin Varghese,
Liangxing Wang, Thiyagarajan P, Bala Murali Krishna,
Anatoly Burakov, Vladimir Medvedkin, Konstantin Ananyev,
Stephen Hemminger
In-Reply-To: <20260521154214.1c171a74@phoenix.local>
22/05/2026 00:42, Stephen Hemminger:
> On Thu, 21 May 2026 18:56:31 +0000
> Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > The implementation for copying up to 64 bytes does not depend on address
> > alignment with the size of the CPU's vector registers. Nonetheless, the
> > exact same code for copying up to 64 bytes was present in both the aligned
> > copy function and all the CPU vector register size specific variants of
> > the unaligned copy functions.
> > With this patch, the implementation for copying up to 64 bytes was
> > consolidated into one instance, located in the common copy function,
> > before checking alignment requirements.
> > This provides three benefits:
> > 1. No copy-paste in the source code.
> > 2. A performance gain for copying up to 64 bytes, because the
> > address alignment check is avoided in this case.
> > 3. Reduced instruction memory footprint, because the compiler only
> > generates one instance of the function for copying up to 64 bytes, instead
> > of two instances (one in the unaligned copy function, and one in the
> > aligned copy function).
> >
> > Furthermore, __rte_restrict was added to source and destination addresses.
> >
> > Also, the missing implementation of rte_mov48() was added.
> >
> > Until recently, some drivers required disabling stringop-overflow warnings
> > when using rte_memcpy().
> > For some strange reason, these warnings were disabled in the rte_memcpy
> > header file, instead of in the problematic drivers.
> > With series-38174 ("remove use of rte_memcpy from net/intel"), the
> > problematic drivers were updated to use memcpy() instead of rte_memcpy(),
> > so disabling these warnings is no longer required, and was removed.
> >
> > Regarding performance...
> > The memcpy performance test (cache-to-cache copy) shows:
> > Copying up to 15 bytes takes ca. 4.5 cycles, versus ca. 6.5 cycles before.
> > Copying 8 bytes takes 4 cycles, versus 7 cycles before.
> > Copying 16 bytes takes 2 cycles, versus 4 cycles before.
> > Copying 64 bytes takes 4 cycles, versus 7 cycles before.
> >
> > Depends-on: series-38174 ("remove use of rte_memcpy from net/intel")
> >
> > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> > Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
>
> Here is the full wordy all providers reviews.
[...]
> Summary across 4 provider(s): clean=0 warnings=1 errors=3 failed=0
What is the followup?
Do we target DPDK 26.07?
^ permalink raw reply
* Re: [PATCH v6] mempool: improve cache behaviour and performance
From: Thomas Monjalon @ 2026-06-01 13:36 UTC (permalink / raw)
To: Morten Brørup
Cc: dev, Andrew Rybchenko, Bruce Richardson, Jingjing Wu,
Praveen Shetty, Hemant Agrawal, Sachin Saxena
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F6589E@smartserver.smartshare.dk>
26/05/2026 18:00, Morten Brørup:
> > From: Morten Brørup [mailto:mb@smartsharesystems.com]
> > Sent: Tuesday, 26 May 2026 16.00
> >
> > This patch refactors the mempool cache to eliminate some unexpected
> > behaviour and reduce the mempool cache miss rate.
> >
> > 1.
> > The actual cache size was 1.5 times the cache size specified at run-
> > time
> > mempool creation.
> > This was obviously not expected by application developers.
> >
> > 2.
> > In get operations, the check for when to use the cache as bounce buffer
> > did not respect the run-time configured cache size,
> > but compared to the build time maximum possible cache size
> > (RTE_MEMPOOL_CACHE_MAX_SIZE, default 512).
> > E.g. with a configured cache size of 32 objects, getting 256 objects
> > would first fetch 32 + 256 = 288 objects into the cache,
> > and then move the 256 objects from the cache to the destination memory,
> > instead of fetching the 256 objects directly to the destination memory.
> > This had a performance cost.
> > However, this is unlikely to occur in real applications, so it is not
> > important in itself.
> >
> > 3.
> > When putting objects into a mempool, and the mempool cache did not have
> > free space for so many objects,
> > the cache was flushed completely, and the new objects were then put
> > into
> > the cache.
> > I.e. the cache drain level was zero.
> > This (complete cache flush) meant that a subsequent get operation (with
> > the same number of objects) completely emptied the cache,
> > so another subsequent get operation required replenishing the cache.
> >
> > Similarly,
> > When getting objects from a mempool, and the mempool cache did not hold
> > so
> > many objects,
> > the cache was replenished to cache->size + remaining objects,
> > and then (the remaining part of) the requested objects were fetched via
> > the cache,
> > which left the cache filled (to cache->size) at completion.
> > I.e. the cache refill level was cache->size (plus some, depending on
> > request size).
> >
> > (1) was improved by generally comparing to cache->size instead of
> > cache->flushthresh, when considering the capacity of the cache.
> > The cache->flushthresh field is kept for API/ABI compatibility
> > purposes,
> > and initialized to cache->size instead of cache->size * 1.5.
> >
> > (2) was improved by generally comparing to cache->size / 2 instead of
> > RTE_MEMPOOL_CACHE_MAX_SIZE, when checking the bounce buffer limit.
> >
> > (3) was improved by flushing and replenishing the cache by half its
> > size,
> > so a flush/refill can be followed randomly by get or put requests.
> > This also reduced the number of objects in each flush/refill operation.
> >
> > As a consequence of these changes, the size of the array holding the
> > objects in the cache (cache->objs[]) no longer needs to be
> > 2 * RTE_MEMPOOL_CACHE_MAX_SIZE, and can be reduced to
> > RTE_MEMPOOL_CACHE_MAX_SIZE at an API/ABI breaking release.
I'm not sure why waiting?
> > Performance data:
> > With a real WAN Optimization application, where the number of allocated
> > packets varies (as they are held in e.g. shaper queues), the mempool
> > cache miss rate dropped from ca. 1/20 objects to ca. 1/48 objects.
> > This was deployed in production at an ISP, and using an effective cache
> > size of 384 objects.
> >
> > Bugzilla ID: 1027
> > Fixes: ea5dd2744b90 ("mempool: cache optimisations")
> > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
>
> Forgot carrying an Ack over from v5:
> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>
> > ---
> > Depends-on: patch-163181 ("net/intel: do not bypass mbuf lib for mbuf
> > fast-free")
>
> This dependency seems to cause CI apply failures.
> The dependency is based on an older snapshot of main,
> and this patch is based on a new snapshot of main.
The dependency should be resolved now.
Please could you send a v7?
^ permalink raw reply
* Re: [PATCH v2] mbuf: fix mbuf operations history recording
From: Thomas Monjalon @ 2026-06-01 13:31 UTC (permalink / raw)
To: Morten Brørup; +Cc: dev, Shani Peretz, Konstantin Ananyev, stable
In-Reply-To: <20260511133952.65539-1-mb@smartsharesystems.com>
11/05/2026 15:39, Morten Brørup:
> This addresses two bugs in mbuf operations history recording.
>
> 1. With mbuf operations history recording enabled, when allocating mbufs
> from a mempool failed, the array of fetched mbuf pointers was not set, but
> it was dereferenced for mbuf operations history recording anyway, which
> would trigger a segmentation fault or cause undefined behavior.
>
> This was fixed by changing how the return value from the mempool
> allocation is checked, so the function returns early on failure, and only
> proceeds on success.
>
> 2. When allocating a bulk of mbufs using rte_pktmbuf_alloc_bulk(), two
> mbuf library allocation operations were recorded on the mbuf, because the
> function calls rte_mbuf_raw_alloc_bulk() for allocation, and both
> functions record a mbuf library allocation operation.
>
> This was fixed by not recording a mbuf library allocation operation in
> rte_pktmbuf_alloc_bulk().
>
> 3. When freeing a bulk of segmented mbufs, the free operations were only
> recorded on the first segments.
>
> This was fixed by freeing the pending bulks of segments using
> rte_mbuf_raw_free_bulk(), which records the free operation on the mbufs,
> instead of calling rte_mempool_put_bulk() directly.
> The bulk operation recording at the start of the function, which only
> affected the first segments of segmented packets, was removed.
>
> Fixes: d265a24a32a4 ("mbuf: record mbuf operations history")
> Cc: stable@dpdk.org
>
> Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Thomas Monjalon <thomas@monjalon.net>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
Applied, thanks.
^ permalink raw reply
* RE: [PATCH 4/7] app/test/mempool_perf: drop constant-values replay
From: Morten Brørup @ 2026-06-01 13:22 UTC (permalink / raw)
To: Andrew Rybchenko, Stephen Hemminger, dev
In-Reply-To: <1047eaf3-f41e-49b9-a4cf-0eb7d46dc6c6@oktetlabs.ru>
> From: Andrew Rybchenko [mailto:andrew.rybchenko@oktetlabs.ru]
> Sent: Monday, 1 June 2026 10.35
>
> On 5/29/26 8:10 PM, Stephen Hemminger wrote:
> > The second nested matrix replays each (n_get_bulk == n_put_bulk)
> > point with use_constant_values=1 to exercise the compile-time
> > constant bulk-size paths in test_loop(). This roughly doubles the
> > work for the get/put diagonal at every n_keep without adding new
> > signal: the cycles/op result for a constant bulk is interesting in
> > isolated inlining studies, not in routine regression sweeps.
> >
> > Drop the replay. The use_constant_values switch and its branches
> > in test_loop() are retained for now since they are exercised by
> > hand in any local benchmarking.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>
> As far as I can see you delete the only place where use_constant_values
> is set to 1. It looks suspicious and basically preserves dead code.
> Since Morten added the code, the patch should wait for his approval.
Having used the mempool perf test extensively myself, I agree that it is painfully slow.
Mempools are very often used with constant request sizes, so testing their performance remains relevant for regression sweeps too.
NAK to this change.
Maybe the testing of constant values could be reduced by using a subset of the non-constant mix of values.
>
> > ---
> > app/test/test_mempool_perf.c | 8 --------
> > 1 file changed, 8 deletions(-)
> >
> > diff --git a/app/test/test_mempool_perf.c
> b/app/test/test_mempool_perf.c
> > index 19591ad0c9..dd2f0bbaca 100644
> > --- a/app/test/test_mempool_perf.c
> > +++ b/app/test/test_mempool_perf.c
> > @@ -423,14 +423,6 @@ do_one_mempool_test(struct rte_mempool *mp,
> unsigned int cores, int external_cac
> > ret = launch_cores(mp, cores);
> > if (ret < 0)
> > return -1;
> > -
> > - /* replay test with constant values */
> > - if (n_get_bulk == n_put_bulk) {
> > - use_constant_values = 1;
> > - ret = launch_cores(mp, cores);
> > - if (ret < 0)
> > - return -1;
> > - }
> > }
> > }
> > }
^ permalink raw reply
* Re: [PATCH] net: fix GTP Tunnel parse out-of-bounds read
From: Thomas Monjalon @ 2026-06-01 12:59 UTC (permalink / raw)
To: dev, Andrew Rybchenko, Bruce Richardson, Jerin Jacob,
Hemant Agrawal
Cc: Stephen Hemminger, stable, Jie Hai
In-Reply-To: <20260409161556.141251-1-stephen@networkplumber.org>
Any comment about this fix?
09/04/2026 18:15, Stephen Hemminger:
> If packet is fragmented across multiple mbufs or the packet
> has only GTP header the code would reference outside
> the incoming mbuf.
>
> Send GTP packet:
> - Valid GTP header (8 bytes)
> - msg_type = 0xff
> - e=1, s=1, pn=1 (sets gtp_len = 12)
> - Total packet size = 10 bytes
>
> Read at gh + 12 accesses 2 bytes beyond packet end.
>
> The fix is to use rte_pktmbuf_read in a manner similar
> to the read of the GTP header.
>
> Fixes: 64ed7f854cf4 ("net: add tunnel packet type parsing")
> Cc: stable@dpdk.org
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> lib/net/rte_net.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/lib/net/rte_net.c b/lib/net/rte_net.c
> index 458b4814a9..da4018437b 100644
> --- a/lib/net/rte_net.c
> +++ b/lib/net/rte_net.c
> @@ -219,8 +219,7 @@ ptype_tunnel_with_udp(uint16_t *proto, const struct rte_mbuf *m,
> case RTE_GTPU_UDP_PORT: {
> const struct rte_gtp_hdr *gh;
> struct rte_gtp_hdr gh_copy;
> - uint8_t gtp_len;
> - uint8_t ip_ver;
> + uint32_t gtp_len;
> gh = rte_pktmbuf_read(m, *off, sizeof(*gh), &gh_copy);
> if (unlikely(gh == NULL))
> return 0;
> @@ -231,9 +230,16 @@ ptype_tunnel_with_udp(uint16_t *proto, const struct rte_mbuf *m,
> * Check message type. If message type is 0xff, it is
> * a GTP data packet. If not, it is a GTP control packet
> */
> + *off += gtp_len;
> if (gh->msg_type == 0xff) {
> - ip_ver = *(const uint8_t *)((const char *)gh + gtp_len);
> - ip_ver = (ip_ver) & 0xf0;
> + const uint8_t *l3_hdr;
> + uint8_t l3_copy, ip_ver;
> +
> + l3_hdr = rte_pktmbuf_read(m, *off, sizeof(*l3_hdr), &l3_copy);
> + if (unlikely(l3_hdr == NULL))
> + return 0;
> +
> + ip_ver = *l3_hdr & 0xf0;
> if (ip_ver == RTE_GTP_TYPE_IPV4)
> *proto = rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4);
> else if (ip_ver == RTE_GTP_TYPE_IPV6)
> @@ -243,7 +249,6 @@ ptype_tunnel_with_udp(uint16_t *proto, const struct rte_mbuf *m,
> } else {
> *proto = 0;
> }
> - *off += gtp_len;
> hdr_lens->inner_l2_len = gtp_len + sizeof(struct rte_udp_hdr);
> hdr_lens->tunnel_len = gtp_len;
> if (port_no == RTE_GTPC_UDP_PORT)
>
^ permalink raw reply
* RE: [PATCH 5/7] app/test/mempool_perf: scale down for high core counts
From: Morten Brørup @ 2026-06-01 12:58 UTC (permalink / raw)
To: Stephen Hemminger, Andrew Rybchenko, dev
In-Reply-To: <20260529171417.526892-6-stephen@networkplumber.org>
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Friday, 29 May 2026 19.11
>
> On a 32-core system the test matrix runs the cartesian product of
> 4 mempools, 3 core-count configurations and ~340 (n_keep, bulk)
> points at TIME_S=1 second each: about 67 minutes total, well past
> the 10 minute perf-test timeout.
>
> Two reductions, no loss of meaningful signal:
>
> 1. Per-point duration: 1 second -> 200 ms. Each point currently
> collects 10^5-10^6 mempool ops; 200 ms still yields >10^4
> samples, well above the noise floor for a cycles-per-op average.
Ack to this.
>
> 2. Matrix trim: drop adjacent bulk and n_keep points that don't
> produce regime changes. Retained set covers the boundaries
> that matter: 1, 4, cache-line burst (8), typical packet burst
> (32) and cache size (RTE_MEMPOOL_CACHE_MAX_SIZE = 512) for bulk;
> 32 (fits in cache), 512 (= cache size) and 32768 (far exceeds
> cache) for n_keep.
My mempool optimization patch [1] introduces a bounce buffer limit, so huge requests are not needlessly copied twice to bounce through the cache, but are moved directly between application memory and the mempool backend driver.
The bounce buffer limit is half the cache size.
So, please keep 256. Maybe change it to RTE_MEMPOOL_CACHE_MAX_SIZE / 2.
[1]: https://patchwork.dpdk.org/project/dpdk/patch/20260526140000.175092-1-mb@smartsharesystems.com/
Also consider keeping 64; it seems to be a popular default burst size for some CPUs.
On the other hand, if the patch introducing default mbuf burst sizes [2] gets accepted, we could replace 32 with RTE_MBUF_BURST_SIZE_THROUGHPUT and 4 with RTE_MBUF_BURST_SIZE_LATENCY.
No strong opinion on 64; I'll leave that up to you.
[2]: https://patchwork.dpdk.org/project/dpdk/list/?series=37914
>
> Combined effect: ~10x runtime reduction.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
With suggested changes,
Acked-by: Morten Brørup <mb@smartsharesystems.com>
^ permalink raw reply
* Re: [PATCH] tree-wide: fix 'allow[s] to' grammar
From: Thomas Monjalon @ 2026-06-01 12:46 UTC (permalink / raw)
To: luca.boccassi; +Cc: dev, Bruce Richardson
In-Reply-To: <aejrN1XS0LEH7hdu@bricha3-mobl1.ger.corp.intel.com>
22/04/2026 17:37, Bruce Richardson:
> On Wed, Apr 22, 2026 at 04:18:53PM +0100, luca.boccassi@gmail.com wrote:
> > From: Luca Boccassi <luca.boccassi@gmail.com>
> >
> > Lintian flags 'allow[s] to' as grammatically incorrect, as it
> > requires an object before the next verb.
> >
> > Fix docs, comments and son on by either switching to gerundinve or
> > adding 'one' as the object.
> >
> > I: dpdk-doc: typo-in-manual-page "allow to" "allow one to" [usr/share/man/man3/rte_graph_model_mcore_dispatch.h.3.gz:32]
> > I: dpdk-doc: typo-in-manual-page "allow to" "allow one to" [usr/share/man/man3/rte_mbuf_dyn.h.3.gz:167]
> > I: dpdk-doc: typo-in-manual-page "allow to" "allow one to" [usr/share/man/man3/rte_mbuf_history.h.3.gz:71]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_bpf_ethdev.h.3.gz:41]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_ethdev.h.3.gz:3423]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_ethdev.h.3.gz:5197]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_ethdev.h.3.gz:5224]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_event_crypto_adapter_runtime_params.3.gz:32]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_event_dma_adapter_runtime_params.3.gz:32]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_event_eth_rx_adapter_runtime_params.3.gz:32]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_event_eth_tx_adapter_runtime_params.3.gz:35]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_flow.h.3.gz:2669]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_graph.h.3.gz:222]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_mempool_objhdr.3.gz:33]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_mldev.h.3.gz:807]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_node_eth_api.h.3.gz:44]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_node_ip4_api.h.3.gz:73]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_node_ip6_api.h.3.gz:50]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_node_pkt_cls_api.h.3.gz:18]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_node_udp4_input_api.h.3.gz:42]
> >
> > Signed-off-by: Luca Boccassi <luca.boccassi@gmail.com>
> > ---
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 2/5] eal: fix async IPC callback not fired when no peers
From: Thomas Monjalon @ 2026-06-01 12:40 UTC (permalink / raw)
To: Anatoly Burakov; +Cc: dev, Jianfeng Tan
In-Reply-To: <n2qqs3VCRg2oTV_S-0kNSw@monjalon.net>
01/06/2026 14:21, Thomas Monjalon:
> 29/05/2026 17:26, Anatoly Burakov:
> > Currently, when rte_mp_request_async() is called and no peer processes
> > are connected (nb_sent == 0), the user callback is never invoked.
> >
> > The original implementation used a dedicated background thread and
> > pthread_cond_signal() to wake it after queuing the dummy request. When
> > that thread was replaced with per-message alarms, no alarm was set for
> > the dummy request, silently breaking the nb_sent == 0 path.
> >
> > This was not noticed because async requests are used while handling
> > secondary process requests, where peers are typically already present.
> >
> > Fix it by setting a 1us alarm on the dummy request, so the callback path
> > immediately triggers and processes it.
> >
> > Fixes: daf9bfca717e ("ipc: remove thread for async requests")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> > ---
> > lib/eal/common/eal_common_proc.c | 12 ++++++++++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/eal/common/eal_common_proc.c b/lib/eal/common/eal_common_proc.c
> > index 799c6e81b0..0ec79336a5 100644
> > --- a/lib/eal/common/eal_common_proc.c
> > +++ b/lib/eal/common/eal_common_proc.c
> > @@ -1187,11 +1187,15 @@ rte_mp_request_async(struct rte_mp_msg *req, const struct timespec *ts,
> > if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
> > ret = mp_request_async(eal_mp_socket_path(), copy, param, ts);
> >
> > - /* if we didn't send anything, put dummy request on the queue */
> > + /* if we didn't send anything, put dummy request on the queue
> > + * and set a minimum-delay alarm so the callback fires immediately.
> > + */
> > if (ret == 0 && reply->nb_sent == 0) {
> > TAILQ_INSERT_TAIL(&pending_requests.requests, dummy,
> > next);
> > dummy_used = true;
> > + if (rte_eal_alarm_set(1, async_reply_handle, dummy) < 0)
> > + EAL_LOG(ERR, "Fail to set alarm for dummy request");
>
> Shouldn't we return an error?
AI suggests this:
if (rte_eal_alarm_set(1, async_reply_handle,
(void *)(uintptr_t)dummy->id) < 0) {
EAL_LOG(ERR, "Fail to set alarm for dummy request");
TAILQ_REMOVE(&pending_requests.requests, dummy, next);
dummy_used = false;
ret = -1;
}
^ permalink raw reply
* Re: [PATCH] raw/gdtc : update MAINTAINERS entry
From: Thomas Monjalon @ 2026-06-01 12:37 UTC (permalink / raw)
To: Wenqiang Chen; +Cc: dev, ran.ming
In-Reply-To: <20260529062058.82782-1-chen.wenqiang2@zte.com.cn>
29/05/2026 08:20, Wenqiang Chen:
> ZTE GDTC
> -M: Yong Zhang <zhang.yong25@zte.com.cn>
> +M: Wenqiang Chen <chen.wenqiang2@zte.com.cn>
> F: drivers/raw/gdtc/
> F: doc/guides/rawdevs/gdtc.rst
Applied, with change in .mailmap, thanks.
^ permalink raw reply
* RE: [PATCH 3/7] app/test/mempool_perf: size mempool by tested cores
From: Morten Brørup @ 2026-06-01 12:22 UTC (permalink / raw)
To: Andrew Rybchenko, Stephen Hemminger, dev
In-Reply-To: <a239680c-0042-4635-b038-6c0a545ba0e5@oktetlabs.ru>
> From: Andrew Rybchenko [mailto:andrew.rybchenko@oktetlabs.ru]
> Sent: Monday, 1 June 2026 10.13
>
> On 5/29/26 8:10 PM, Stephen Hemminger wrote:
> > The mempool size is computed from rte_lcore_count() so on systems
> > with many lcores the test requires multiple GB of hugepages even
> > for the single-core and dual-core variants. On a 20 lcore system
> > with 2 GB of hugepages the test fails with:
> >
> > cannot populate ring_mp_mc mempool
> > Test Failed
> >
> > Size the four mempools by the number of cores actually exercised.
> >
> > Return TEST_SKIPPED rather than -1 when allocation or populate of
> > a mempool fails, so insufficient memory is reported as a skip and
> > not as a test failure. Propagate the skip through the combined
> > mempool_perf_autotest wrapper.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>
> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
LGTM too.
Acked-by: Morten Brørup <mb@smartsharesystems.com>
^ permalink raw reply
* Re: [PATCH v2 2/5] eal: fix async IPC callback not fired when no peers
From: Thomas Monjalon @ 2026-06-01 12:21 UTC (permalink / raw)
To: Anatoly Burakov; +Cc: dev, Jianfeng Tan
In-Reply-To: <1ad014dd239fa1e8ea62aab7e56a7bf7264c04ff.1780068382.git.anatoly.burakov@intel.com>
29/05/2026 17:26, Anatoly Burakov:
> Currently, when rte_mp_request_async() is called and no peer processes
> are connected (nb_sent == 0), the user callback is never invoked.
>
> The original implementation used a dedicated background thread and
> pthread_cond_signal() to wake it after queuing the dummy request. When
> that thread was replaced with per-message alarms, no alarm was set for
> the dummy request, silently breaking the nb_sent == 0 path.
>
> This was not noticed because async requests are used while handling
> secondary process requests, where peers are typically already present.
>
> Fix it by setting a 1us alarm on the dummy request, so the callback path
> immediately triggers and processes it.
>
> Fixes: daf9bfca717e ("ipc: remove thread for async requests")
> Cc: stable@dpdk.org
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
> lib/eal/common/eal_common_proc.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/lib/eal/common/eal_common_proc.c b/lib/eal/common/eal_common_proc.c
> index 799c6e81b0..0ec79336a5 100644
> --- a/lib/eal/common/eal_common_proc.c
> +++ b/lib/eal/common/eal_common_proc.c
> @@ -1187,11 +1187,15 @@ rte_mp_request_async(struct rte_mp_msg *req, const struct timespec *ts,
> if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
> ret = mp_request_async(eal_mp_socket_path(), copy, param, ts);
>
> - /* if we didn't send anything, put dummy request on the queue */
> + /* if we didn't send anything, put dummy request on the queue
> + * and set a minimum-delay alarm so the callback fires immediately.
> + */
> if (ret == 0 && reply->nb_sent == 0) {
> TAILQ_INSERT_TAIL(&pending_requests.requests, dummy,
> next);
> dummy_used = true;
> + if (rte_eal_alarm_set(1, async_reply_handle, dummy) < 0)
> + EAL_LOG(ERR, "Fail to set alarm for dummy request");
Shouldn't we return an error?
^ permalink raw reply
* Re: [PATCH v2 4/5] eal: fix async IPC resource leaks on partial failure
From: Thomas Monjalon @ 2026-06-01 12:16 UTC (permalink / raw)
To: Anatoly Burakov; +Cc: dev, Jianfeng Tan
In-Reply-To: <eea1925f6fb24f0f92a2a57d45e9a9c824d353c0.1780068382.git.anatoly.burakov@intel.com>
29/05/2026 17:26, Anatoly Burakov:
> Use a numeric request ID for alarm callback lookup so stale callbacks
> from rolled-back requests become harmless no-ops.
[...]
> +static struct pending_request *
> +find_pending_request_by_id(unsigned long id)
> +{
> + struct pending_request *r;
> +
> + TAILQ_FOREACH(r, &pending_requests.requests, next) {
> + if (r->id == id)
> + return r;
> + }
> +
> + return NULL;
> +}
This function is supposed to find only async requests?
What will happen if id wraparound and becomes 0,
matching sync requests?
I feel we should filter with r->type == REQUEST_TYPE_ASYNC
^ permalink raw reply
* Re: [PATCH] ethdev: promote experimental API's to stable
From: David Marchand @ 2026-06-01 11:55 UTC (permalink / raw)
To: Stephen Hemminger, Andrew Rybchenko; +Cc: dev, Thomas Monjalon
In-Reply-To: <20260527144407.160830-1-stephen@networkplumber.org>
On Wed, 27 May 2026 at 16:44, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> + * ``rte_eth_macaddrs_get``
I am not enthousiastic on marking this stable.
It more or less sets in stone that the mac addresses are stored in an array.
The initial goal was to retrieve all mac addresses of a port (21.11
release note entry):
"""
* **Added support to get all MAC addresses of a device.**
Added ``rte_eth_macaddrs_get`` to allow a user to retrieve all
Ethernet
addresses assigned to a given Ethernet port.
"""
And this is how it is used in testpmd.
https://git.dpdk.org/dpdk/tree/app/test-pmd/config.c#n7618
I'd rather see an API using an iterator that abstracts how macs are stored.
That would also make it possible to skip null macs (which I find ugly
in existing code).
RTE_ETH_DEV_FOREACH_MAC(mac, port_id) {
}
--
David Marchand
^ permalink raw reply
* Re: [PATCH] test/latency: fix intermittent failure on slow platforms
From: Luca Boccassi @ 2026-06-01 10:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, stable, Reshma Pattan, Bruce Richardson
In-Reply-To: <20260531180118.274308-1-stephen@networkplumber.org>
On Sun, 31 May 2026 at 19:01, Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> The forwarding loop was bounded by a fixed interval of 0.5ms
> but on slow or emulated platforms with a low-frequency timebase
> (e.g. RISC-V rdtime) this fails because the loop only ran once.
> The test needs two iterations to get any samples.
>
> Rearrange the forwarding loop so that a minimum number of iterations
> are required. The loop still has an upper bound on packets and time
> interval which is expanded to 10 ms.
>
> If no samples are collected, mark the test as skipped.
> Refactor the forwarding loop test so that cleanup happens on
> failure.
>
> Reported-by: Luca Boccassi <bluca@debian.org>
> Fixes: b34508b9cbcd ("test/latency: update with more checks")
> Cc: stable@dpdk.org
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> app/test/test_latencystats.c | 75 ++++++++++++++++++++++--------------
> 1 file changed, 46 insertions(+), 29 deletions(-)
Thanks, this has been failing consistently in riscv64 since at least
25.11, hopefully this makes it stable.
Acked-by: Luca Boccassi <luca.boccassi@gmail.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox