On Sat, 21 Feb 2026 04:37:44 +0530
<[email protected]> wrote:
> From: Pavan Nikhilesh <[email protected]>
>
> Replace hardcoded burst sizes with RTE_MBUF_BURST_SIZE_DEFAULT
> to adapt to platform-specific optimal burst sizes.
>
> Signed-off-by: Pavan Nikhilesh <[email protected]>
> ---
This is way to broad. See deeper AI analysis for all the places
this patch is over stepping...
Should only touch examples, and never change the MAX values.
It should not change any drivers.
-----
Patch 2/2: examples: use default mbuf burst size
Error: Semantic mismatch — evt_options.vector_size set to burst size macro
In app/test-eventdev/evt_options.c:

c
- opt->vector_size = 64;
+ opt->vector_size = RTE_MBUF_BURST_SIZE_DEFAULT;
The original hardcoded value of 64 for vector_size is an event vector size, not
an mbuf burst size. Event vector sizes and mbuf burst sizes serve different
purposes — event vectors aggregate events for batch processing and can
legitimately be larger than the Rx/Tx burst size. Replacing 64 with
RTE_MBUF_BURST_SIZE_DEFAULT (which defaults to 32 in throughput mode) silently
halves the default event vector size on all non-CN10K platforms. This is a
functional regression that could degrade event-mode throughput. The original
value should remain 64, or a separate RTE_EVENT_VECTOR_SIZE_DEFAULT macro
should be introduced.
Error: MAX_PKT_BURST_VEC reduced from 256 to burst default
In examples/ipsec-secgw/ipsec-secgw.h:

c
-#define MAX_PKT_BURST_VEC 256
+#define MAX_PKT_BURST_VEC RTE_MBUF_BURST_SIZE_DEFAULT
MAX_PKT_BURST_VEC was intentionally set to 256 for vectorized IPsec processing,
which processes packets in large vectorized batches. Reducing it to 32 (the
default throughput burst size) is a significant behavioral change that will
likely hurt vectorized IPsec performance. This macro also feeds into the
MAX_PKTS calculation immediately below it, so the reduction cascades. This
should either keep 256 or use a separate vector-specific configuration.
Error: MAX_PKT_BURST and DEF_PKT_BURST collapsed to same value in bonding tests
In app/test/test_link_bonding_mode4.c:

c
-#define MAX_PKT_BURST (32)
-#define DEF_PKT_BURST (16)
+#define MAX_PKT_BURST (RTE_MBUF_BURST_SIZE_DEFAULT)
+#define DEF_PKT_BURST (RTE_MBUF_BURST_SIZE_DEFAULT)
Originally MAX_PKT_BURST (32) and DEF_PKT_BURST (16) were intentionally
different values — the max is a buffer/array size limit and the default is the
actual burst count used. Setting both to the same value means the test now
always bursts at the maximum array size with no headroom. If any code path
allocates MAX_PKT_BURST elements and bursts DEF_PKT_BURST, this distinction is
lost. At minimum, DEF_PKT_BURST should remain smaller than MAX_PKT_BURST.
Similarly in app/test/test_link_bonding.c, the original DEF_PKT_BURST was 16,
now it becomes RTE_MBUF_BURST_SIZE_DEFAULT (32), which equals MAX_PKT_BURST in
some cases — same concern about losing the max/default distinction.
Warning: NTB_MAX_PKT_BURST and NTB_DFLT_PKT_BURST collapsed
In examples/ntb/ntb_fwd.c:

c
-#define NTB_MAX_PKT_BURST 32
-#define NTB_DFLT_PKT_BURST 32
+#define NTB_MAX_PKT_BURST RTE_MBUF_BURST_SIZE_DEFAULT
+#define NTB_DFLT_PKT_BURST RTE_MBUF_BURST_SIZE_DEFAULT
These were already the same value (32), so there's no regression today, but the
intent of having separate MAX and DEFAULT macros is to allow them to diverge.
Replacing both with the same configurable macro permanently ties them together.
Consider using RTE_MBUF_BURST_SIZE_DEFAULT only for the default and keeping MAX
as a separate (potentially larger) constant.
Warning: RTE_MBUF_F_RX_BURST_MAX / RTE_MBUF_F_TX_BURST_MAX naming confusion
In examples/qos_meter/main.c:

c
-#define RTE_MBUF_F_RX_BURST_MAX 32
-#define RTE_MBUF_F_TX_BURST_MAX 32
+#define RTE_MBUF_F_RX_BURST_MAX RTE_MBUF_BURST_SIZE_DEFAULT
+#define RTE_MBUF_F_TX_BURST_MAX RTE_MBUF_BURST_SIZE_DEFAULT
The RTE_MBUF_F_ prefix is reserved for mbuf flags (e.g.,
RTE_MBUF_F_RX_RSS_HASH). These macros are local to the example and not real
mbuf flags, but this naming is confusing and was a pre-existing issue. Since
this patch is already touching these lines, it would be a good opportunity to
rename them to something like QOS_RX_BURST_MAX/QOS_TX_BURST_MAX to avoid
namespace confusion.
Warning: PKT_ENQUEUE and PKT_DEQUEUE not updated in qos_sched
In examples/qos_sched/main.h:

c
#define MAX_PKT_RX_BURST RTE_MBUF_BURST_SIZE_DEFAULT
#define PKT_ENQUEUE 64
#define PKT_DEQUEUE 63
#define MAX_PKT_TX_BURST RTE_MBUF_BURST_SIZE_DEFAULT
MAX_PKT_RX_BURST and MAX_PKT_TX_BURST are updated from 64 to
RTE_MBUF_BURST_SIZE_DEFAULT (32), but PKT_ENQUEUE remains hardcoded at 64 and
PKT_DEQUEUE at 63. Now the enqueue size is 2× the Rx burst size, creating an
inconsistency. If these values are related (and they appear to be — you burst
Rx into an enqueue batch), they should be updated together or the relationship
should be documented.
Warning: fprintf(stderr, ...) in example code for non-error messages
In examples/l3fwd/main.c, the added else branches print to stderr even when the
user explicitly provided a value:

c
} else {
fprintf(stderr, "vector size set to (%" PRIu16 ")\n",
evt_rsrc->vector_size);
}
Using stderr for informational messages (not errors) is unconventional. This is
example code so it's not critical, but printf or RTE_LOG would be more
appropriate for confirming a user-supplied setting.
Warning: Duplicate MAX_PKT_BURST definition
In examples/link_status_interrupt/main.c, MAX_PKT_BURST is defined twice (lines
41 and 63 in the original). Both are being updated, but this pre-existing
duplicate #define should ideally be cleaned up. Since the patch is already
modifying both lines, removing the duplicate would be a good cleanup.




