DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: dev@dpdk.org, shperetz@nvidia.com, viacheslavo@nvidia.com,
	bruce.richardson@intel.com, stephen@networkplumber.org
Subject: Re: [PATCH v5 3/7] mbuf: record mbuf operations history
Date: Tue, 14 Oct 2025 14:03:43 +0200	[thread overview]
Message-ID: <2949753.n0HT0TaD9V@thomas> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F654C7@smartserver.smartshare.dk>

14/10/2025 11:59, Morten Brørup:
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > --- /dev/null
> > +++ b/lib/mbuf/mbuf_history.c
> > @@ -0,0 +1,227 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(c) 2024 NVIDIA Corporation & Affiliates
> 
> Suggest: 2024 -> 2025
> Also in other files.

No, it is the year of initial write.
It has been used internally before pushing upstream.


[...]
> > +#define HISTORY_LAST_MASK (RTE_BIT64(RTE_MBUF_HISTORY_BITS) - 1)
> 
> Various places in the code has something like:
> +	last_op = history & HISTORY_LAST_MASK;
> +	RTE_ASSERT(last_op < RTE_MBUF_HISTORY_OP_MAX);

There is only one.
Other asserts are validating function parameters to be of the right size.

> Suggest replacing those by adding a static_assert here instead:
> static_assert(RTE_MBUF_HISTORY_OP_MAX == HISTORY_LAST_MASK + 1, "Op size mismatch")

It is just checking RTE_MBUF_HISTORY_BITS and RTE_MBUF_HISTORY_OP_MAX are in sync.
Honestly I don't see a real benefit, but I will add
RTE_BUILD_BUG_ON(RTE_MBUF_HISTORY_OP_MAX > HISTORY_LAST_MASK + 1);


[...]
> > +static void
> > +mbuf_history_count_stats_and_print(struct rte_mempool *mp
> > __rte_unused,
> > +		void *opaque, void *obj, unsigned obj_idx __rte_unused)
> 
> Fix:
> unsigned -> unsigned int

It is the definition:
typedef void (rte_mempool_obj_cb_t)(struct rte_mempool *mp,
        void *opaque, void *obj, unsigned obj_idx);

> 
> > +{
> > +	struct count_and_print_ctx *ctx = (struct count_and_print_ctx
> > *)opaque;
> > +	struct rte_mbuf *m = (struct rte_mbuf *)obj;
> > +	uint64_t history, last_op;
> 
> Suggest using the enum type for operation variables:
> uint64_t history;
> enum rte_mbuf_history_op last_op;
> 
> Also elsewhere in the code.

Yes it would be better to use the right type.


[...]
> > @@ -667,6 +672,7 @@ rte_mbuf_raw_free(struct rte_mbuf *m)
> >  {
> >  	__rte_mbuf_raw_sanity_check(m);
> >  	rte_mempool_put(m->pool, m);
> > +	rte_mbuf_history_mark(m, RTE_MBUF_HISTORY_OP_LIB_FREE);
> 
> Fix: For improved race protection, mark the mbuf before actually freeing it, like this:
>  	__rte_mbuf_raw_sanity_check(m);
> +	rte_mbuf_history_mark(m, RTE_MBUF_HISTORY_OP_LIB_FREE);
>  	rte_mempool_put(m->pool, m);

The race is about a debugging mark.
The benefit of marking after is that the last mark is the upper level,
so we can easily distinguish between a free initiated by the app or the PMD.


[...]
> > @@ -701,6 +707,7 @@ rte_mbuf_raw_free_bulk(struct rte_mempool *mp,
> > struct rte_mbuf **mbufs, unsigned
> >  		RTE_ASSERT(m != NULL);
> >  		RTE_ASSERT(m->pool == mp);
> >  		__rte_mbuf_raw_sanity_check(m);
> > +		rte_mbuf_history_mark(mbufs[idx],
> > RTE_MBUF_HISTORY_OP_LIB_FREE);
> >  	}
> 
> Fix: The loop is normally omitted, so use rte_mbuf_history_mark_bulk() here instead of rte_mbuf_history_mark() inside the loop.
> It also makes the code easier to read.

OK


[...]
> > +enum rte_mbuf_history_op {
> > +	RTE_MBUF_HISTORY_OP_NEVER     =  0, /**< Initial state - never
> > allocated */
> > +	RTE_MBUF_HISTORY_OP_LIB_FREE  =  1, /**< Freed back to pool */
> > +	RTE_MBUF_HISTORY_OP_PMD_FREE  =  2, /**< Freed by PMD */
> > +	RTE_MBUF_HISTORY_OP_APP_FREE  =  3, /**< Freed by application */
> > +	RTE_MBUF_HISTORY_OP_LIB_ALLOC =  4, /**< Allocation in mbuf
> > library */
> > +	RTE_MBUF_HISTORY_OP_PMD_ALLOC =  5, /**< Allocated by PMD for Rx
> > */
> > +	RTE_MBUF_HISTORY_OP_APP_ALLOC =  6, /**< Allocated by application
> > */
> > +	RTE_MBUF_HISTORY_OP_RX        =  7, /**< Received */
> > +	RTE_MBUF_HISTORY_OP_TX        =  8, /**< Sent */
> > +	RTE_MBUF_HISTORY_OP_PREP_TX   =  9, /**< Being prepared before Tx
> > */
> > +	RTE_MBUF_HISTORY_OP_BUSY_TX   = 10, /**< Returned due to Tx busy
> > */
> 
> Suggest:
> RTE_MBUF_HISTORY_OP_PREP_TX -> RTE_MBUF_HISTORY_OP_TX_PREP
> RTE_MBUF_HISTORY_OP_BUSY_TX -> RTE_MBUF_HISTORY_OP_TX_BUSY

OK

> > +	RTE_MBUF_HISTORY_OP_ENQUEUE   = 11, /**< Enqueued for processing
> > */
> > +	RTE_MBUF_HISTORY_OP_DEQUEUE   = 12, /**< Dequeued for processing
> > */
> > +	/*                              13,      reserved for future */
> > +	RTE_MBUF_HISTORY_OP_USR2      = 14, /**< Application-defined
> > event 2 */
> > +	RTE_MBUF_HISTORY_OP_USR1      = 15, /**< Application-defined
> > event 1 */
> > +	RTE_MBUF_HISTORY_OP_MAX       = 16, /**< Maximum number of
> > operation types */
> > +};
> 
> Suggest adding:
> static_assert(RTE_MBUF_HISTORY_OP_MAX == 1 << RTE_MBUF_HISTORY_BITS, "Enum vs bitsize mismatch");

Done with RTE_BUILD_BUG_ON(RTE_MBUF_HISTORY_OP_MAX > HISTORY_LAST_MASK + 1);
in next version.

No need to test equality.
Being more tolerant allows playing with tuning easily.


[...]
> > +/**
> > + * Mark an mbuf with a history event.
> > + *
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * @param m
> > + *   Pointer to the mbuf.
> > + * @param op
> > + *   The operation to record.
> > + */
> > +static inline void rte_mbuf_history_mark(struct rte_mbuf *m, uint32_t
> > op)
> 
> Fix:
> uint32_t op -> enum rte_mbuf_history_op op

Yes


[...]
> > +/**
> > + * Mark multiple mbufs with a history event.
> > + *
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * @param mbufs
> > + *   Array of mbuf pointers.
> > + * @param n
> > + *   Number of mbufs to mark.
> > + * @param op
> > + *   The operation to record.
> > + */
> > +static inline void rte_mbuf_history_mark_bulk(struct rte_mbuf * const
> > *mbufs,
> > +		uint32_t n, uint32_t op)
> 
> Fix:
> uint32_t n -> unsigned int count (for consistency)
> uint32_t op -> enum rte_mbuf_history_op op

Yes


[...]
> With fixes (suggestions optional),
> Acked-by: Morten Brørup <mb@smartsharesystems.com>

Thanks for the very detailed review.



  reply	other threads:[~2025-10-14 12:03 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-16  7:29 [RFC PATCH 0/5] Introduce mempool object new debug capabilities Shani Peretz
2025-06-16  7:29 ` [RFC PATCH 1/5] mempool: record mempool objects operations history Shani Peretz
2025-06-16  7:29 ` [RFC PATCH 2/5] drivers: add mempool history compilation flag Shani Peretz
2025-06-16  7:29 ` [RFC PATCH 3/5] net/mlx5: mark an operation in mempool object's history Shani Peretz
2025-06-16  7:29 ` [RFC PATCH 4/5] app/testpmd: add testpmd command to dump mempool history Shani Peretz
2025-06-16  7:29 ` [RFC PATCH 5/5] usertool: add a script to parse mempool history dump Shani Peretz
2025-06-16 15:30 ` [RFC PATCH 0/5] Introduce mempool object new debug capabilities Stephen Hemminger
2025-06-19 12:57   ` Morten Brørup
2025-07-07  5:46     ` Shani Peretz
2025-07-07  5:45   ` Shani Peretz
2025-07-07 12:10     ` Morten Brørup
2025-07-19 14:39       ` Morten Brørup
2025-08-25 11:27         ` Slava Ovsiienko
2025-09-01 15:34           ` Morten Brørup
2025-09-16 15:12 ` [PATCH v2 0/4] add mbuf " Shani Peretz
2025-09-16 15:12   ` [PATCH v2 1/4] mbuf: record mbuf operations history Shani Peretz
2025-09-16 21:17     ` Stephen Hemminger
2025-09-16 21:33       ` Thomas Monjalon
2025-09-17  1:22         ` Morten Brørup
2025-09-17 14:46     ` Morten Brørup
2025-09-19  9:14       ` Shani Peretz
2025-09-16 15:12   ` [PATCH v2 2/4] net/mlx5: mark an operation in mbuf's history Shani Peretz
2025-09-16 21:14     ` Stephen Hemminger
2025-09-16 21:31       ` Thomas Monjalon
2025-09-17 15:04         ` Stephen Hemminger
2025-09-16 15:12   ` [PATCH v2 3/4] app/testpmd: add testpmd command to dump mbuf history Shani Peretz
2025-09-16 15:12   ` [PATCH v2 4/4] usertool: add a script to parse mbuf history dump Shani Peretz
2025-09-30 23:25 ` [PATCH v3 0/5] add mbuf debug capabilities Thomas Monjalon
2025-09-30 23:25   ` [PATCH v3 1/5] mbuf: move header include for logs Thomas Monjalon
2025-09-30 23:25   ` [PATCH v3 2/5] mbuf: record mbuf operations history Thomas Monjalon
2025-10-01  0:12     ` Thomas Monjalon
2025-10-02  7:37     ` Morten Brørup
2025-10-02 21:23       ` Thomas Monjalon
2025-10-13 18:39       ` Thomas Monjalon
2025-10-13 20:08         ` Morten Brørup
2025-10-13 21:07           ` Thomas Monjalon
2025-10-14 10:04             ` Morten Brørup
2025-09-30 23:25   ` [PATCH v3 3/5] ethdev: mark mbufs in burst functions Thomas Monjalon
2025-10-02  7:44     ` Morten Brørup
2025-10-13 15:32       ` Thomas Monjalon
2025-09-30 23:25   ` [PATCH v3 4/5] app/testpmd: add commands to dump mbuf history Thomas Monjalon
2025-10-01  8:20     ` Stephen Hemminger
2025-10-13 15:31       ` Thomas Monjalon
2025-09-30 23:25   ` [PATCH v3 5/5] usertools/mbuf: parse mbuf history dump Thomas Monjalon
2025-10-02  8:07     ` Robin Jarry
2025-10-13 21:16 ` [PATCH v4 0/7] add mbuf debug capabilities Thomas Monjalon
2025-10-13 21:16   ` [PATCH v4 1/7] doc: explain debug options in mbuf guide Thomas Monjalon
2025-10-13 21:16   ` [PATCH v4 2/7] mbuf: move header include for logs Thomas Monjalon
2025-10-13 21:16   ` [PATCH v4 3/7] mbuf: record mbuf operations history Thomas Monjalon
2025-10-13 21:16   ` [PATCH v4 4/7] ethdev: mark mbufs in burst functions Thomas Monjalon
2025-10-13 21:16   ` [PATCH v4 5/7] app/testpmd: use space separator in dump commands Thomas Monjalon
2025-10-13 21:16   ` [PATCH v4 6/7] app/testpmd: add commands to dump mbuf history Thomas Monjalon
2025-10-13 21:16   ` [PATCH v4 7/7] usertools/mbuf: parse mbuf history dump Thomas Monjalon
2025-10-14  6:58 ` [PATCH v5 0/7] add mbuf debug capabilities Thomas Monjalon
2025-10-14  6:58   ` [PATCH v5 1/7] doc: explain debug options in mbuf guide Thomas Monjalon
2025-10-14  6:58   ` [PATCH v5 2/7] mbuf: move header include for logs Thomas Monjalon
2025-10-14  8:47     ` Morten Brørup
2025-10-14  6:58   ` [PATCH v5 3/7] mbuf: record mbuf operations history Thomas Monjalon
2025-10-14  9:59     ` Morten Brørup
2025-10-14 12:03       ` Thomas Monjalon [this message]
2025-10-14 12:31         ` Thomas Monjalon
2025-10-14  6:58   ` [PATCH v5 4/7] ethdev: mark mbufs in burst functions Thomas Monjalon
2025-10-14  6:58   ` [PATCH v5 5/7] app/testpmd: use space separator in dump commands Thomas Monjalon
2025-10-14  6:58   ` [PATCH v5 6/7] app/testpmd: add commands to dump mbuf history Thomas Monjalon
2025-10-14  8:45     ` Morten Brørup
2025-10-14  9:43       ` Thomas Monjalon
2025-10-14  9:48         ` Bruce Richardson
2025-10-14  9:55           ` Thomas Monjalon
2025-10-14  6:58   ` [PATCH v5 7/7] usertools/mbuf: parse mbuf history dump Thomas Monjalon
2025-10-14 12:33 ` [PATCH v6 0/7] add mbuf debug capabilities Thomas Monjalon
2025-10-14 12:33   ` [PATCH v6 1/7] doc: explain debug options in mbuf guide Thomas Monjalon
2025-10-14 12:33   ` [PATCH v6 2/7] mbuf: move header include for logs Thomas Monjalon
2025-10-14 12:33   ` [PATCH v6 3/7] mbuf: record mbuf operations history Thomas Monjalon
2025-10-14 12:33   ` [PATCH v6 4/7] ethdev: mark mbufs in burst functions Thomas Monjalon
2025-10-14 12:33   ` [PATCH v6 5/7] app/testpmd: use space separator in dump commands Thomas Monjalon
2025-10-14 12:33   ` [PATCH v6 6/7] app/testpmd: add commands to dump mbuf history Thomas Monjalon
2025-10-14 12:33   ` [PATCH v6 7/7] usertools/mbuf: parse mbuf history dump Thomas Monjalon
2025-10-14 14:03     ` Robin Jarry

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2949753.n0HT0TaD9V@thomas \
    --to=thomas@monjalon.net \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=mb@smartsharesystems.com \
    --cc=shperetz@nvidia.com \
    --cc=stephen@networkplumber.org \
    --cc=viacheslavo@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).