From: Stephen Hemminger <stephen@networkplumber.org>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: Shani Peretz <shperetz@nvidia.com>,
dev@dpdk.org, mb@smartsharesystems.com,
bruce.richardson@intel.com, ajit.khaparde@broadcom.com,
jerinj@marvell.com, konstantin.v.ananyev@yandex.ru,
david.marchand@redhat.com, maxime.coquelin@redhat.com,
gakhil@marvell.com, viacheslavo@nvidia.com,
Dariusz Sosnowski <dsosnowski@nvidia.com>,
Bing Zhao <bingz@nvidia.com>, Ori Kam <orika@nvidia.com>,
Suanming Mou <suanmingm@nvidia.com>,
Matan Azrad <matan@nvidia.com>
Subject: Re: [PATCH v2 2/4] net/mlx5: mark an operation in mbuf's history
Date: Wed, 17 Sep 2025 08:04:42 -0700 [thread overview]
Message-ID: <20250917080437.363a2ee3@hermes.local> (raw)
In-Reply-To: <13612908.O9o76ZdvQC@thomas>
On Tue, 16 Sep 2025 23:31:34 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:
> 16/09/2025 23:14, Stephen Hemminger:
> > On Tue, 16 Sep 2025 18:12:05 +0300
> > Shani Peretz <shperetz@nvidia.com> wrote:
> >
> > > record operations on mbufs when it is allocated
> > > and released inside the mlx5 PMD.
> > >
> > > Signed-off-by: Shani Peretz <shperetz@nvidia.com>
> > > ---
> >
> > If you are adding this to one driver, it means it should be
> > done to all drivers. Which means it is creating lots of churn
> > and testing.
>
> Why a new feature should be applied to all drivers?
> We never force a new feature to be implemented by all,
> it is impossible to do.
It should at least be a reasonable subset of drivers. Doing it for only
one device makes it much less usable. At a minimum need to cover the drivers
that are commonly used and part of the CI test structure. It really isn't
that hard for this history stuff to find where to put a few calls.
Also the obvious ones like null, ring, and any demo skeleton code.
>
> > For me, this amount of churn and #ifdef is not worth it.
>
> I agree we could avoid the #ifdef with a dummy function
> which would be optimized out by the compiler.
>
> > Think of a better way using some other mechanism.
>
> Except avoiding the #ifdef, I don't see what better to do
> for tracking what the driver is doing with mbufs.
Tx and Rx burst could do one marking step.
next prev parent reply other threads:[~2025-09-17 15:21 UTC|newest]
Thread overview: 26+ 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-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 [this message]
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
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=20250917080437.363a2ee3@hermes.local \
--to=stephen@networkplumber.org \
--cc=ajit.khaparde@broadcom.com \
--cc=bingz@nvidia.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=dsosnowski@nvidia.com \
--cc=gakhil@marvell.com \
--cc=jerinj@marvell.com \
--cc=konstantin.v.ananyev@yandex.ru \
--cc=matan@nvidia.com \
--cc=maxime.coquelin@redhat.com \
--cc=mb@smartsharesystems.com \
--cc=orika@nvidia.com \
--cc=shperetz@nvidia.com \
--cc=suanmingm@nvidia.com \
--cc=thomas@monjalon.net \
--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).