DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Thomas Monjalon" <thomas@monjalon.net>
Cc: "Bruce Richardson" <bruce.richardson@intel.com>, <dev@dpdk.org>,
	"Stephen Hemminger" <stephen@networkplumber.org>,
	"Konstantin Ananyev" <konstantin.ananyev@huawei.com>,
	"Andrew Rybchenko" <andrew.rybchenko@oktetlabs.ru>,
	"Ivan Malov" <ivan.malov@arknetworks.am>,
	"Chengwen Feng" <fengchengwen@huawei.com>
Subject: RE: [PATCH v8 1/3] mbuf: de-inline sanity checking a reinitialized mbuf
Date: Thu, 9 Oct 2025 19:55:16 +0200	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35F654B8@smartserver.smartshare.dk> (raw)
In-Reply-To: <3916365.44csPzL39Z@thomas>

> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Thursday, 9 October 2025 19.29
> 
> 09/10/2025 19:12, Morten Brørup:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > On Sat, Aug 23, 2025 at 06:30:00AM +0000, Morten Brørup wrote:
> > > > +/**  check reinitialized mbuf type in debug mode */
> > >
> > > This is in release mode, not debug mode. Comment below seems wrong
> too.
> >
> > Yes, I noticed the comment was present in both debug and release
> mode,
> > which I couldn't understand. So I guessed it was for Doxygen or some
> other parser.
> > I have seen weird stuff for Doxygen, e.g. "#ifdef __DOXYGEN__"
> > for documenting a function [1],
> > so I didn't attempt to understand the reason for it,
> > but just followed the same pattern.
> 
> Hum, as a maintainer, I would prefer you try to understand, or ask
> please.
> Note: we can use Slack for such questions.

Point taken. Good guidance!
I'll try to broaden my scope of knowledge to include preprocessing for Doxygen.

> 
> __DOXYGEN__ is defined only by Doxygen,
> so any code inside #ifdef __DOXYGEN__ is for documentation only.
> It was supposed to be used in lib/eal/include/generic
> for functions which are really defined inline per CPU implementation.
> 
Yes, I get that.
But I don't get - when there are two definitions of a macro - why is the same comment/documentation present in both instances?
And if the instances have different comments/documentation, how is that reflected in the documentation output from Doxygen?

In this specific case, how should the code look to both 1) get the wanted Doxygen documentation output, and 2) have relevant comments inline in the source code for both instances?


  reply	other threads:[~2025-10-09 17:55 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-21 15:02 [PATCH v5 0/3] mbuf: simplify handling of reinitialized mbufs Morten Brørup
2025-08-21 15:02 ` [PATCH v5 1/3] mbuf: de-inline sanity checking a reinitialized mbuf Morten Brørup
2025-08-21 15:02 ` [PATCH v5 2/3] promote reinitialized mbuf free and alloc bulk functions as stable Morten Brørup
2025-08-21 15:02 ` [PATCH v5 3/3] mbuf: no need to reset all fields on reinitialized mbufs Morten Brørup
2025-08-22 12:47 ` [PATCH v6 0/3] mbuf: simplify handling of " Morten Brørup
2025-08-22 12:47   ` [PATCH v6 1/3] mbuf: de-inline sanity checking a reinitialized mbuf Morten Brørup
2025-08-22 14:26     ` Morten Brørup
2025-08-22 12:47   ` [PATCH v6 2/3] mbuf: promote raw free and alloc bulk functions as stable Morten Brørup
2025-08-22 12:47   ` [PATCH v6 3/3] mbuf: no need to reset all fields on reinitialized mbufs Morten Brørup
2025-08-22 23:45 ` [PATCH v7 0/3] mbuf: simplify handling of " Morten Brørup
2025-08-22 23:45   ` [PATCH v7 1/3] mbuf: de-inline sanity checking a reinitialized mbuf Morten Brørup
2025-08-22 23:45   ` [PATCH v7 2/3] mbuf: promote raw free and alloc bulk functions as stable Morten Brørup
2025-08-22 23:45   ` [PATCH v7 3/3] mbuf: optimize reset of reinitialized mbufs Morten Brørup
2025-08-23  6:29 ` [PATCH v8 0/3] mbuf: simplify handling " Morten Brørup
2025-08-23  6:30   ` [PATCH v8 1/3] mbuf: de-inline sanity checking a reinitialized mbuf Morten Brørup
2025-10-09 16:49     ` Bruce Richardson
2025-10-09 17:12       ` Morten Brørup
2025-10-09 17:29         ` Thomas Monjalon
2025-10-09 17:55           ` Morten Brørup [this message]
2025-08-23  6:30   ` [PATCH v8 2/3] mbuf: promote raw free and alloc bulk functions as stable Morten Brørup
2025-10-09 16:53     ` Bruce Richardson
2025-08-23  6:30   ` [PATCH v8 3/3] mbuf: optimize reset of reinitialized mbufs Morten Brørup
2025-08-23 14:28     ` Stephen Hemminger
2025-10-09 17:15     ` Bruce Richardson
2025-10-09 17:35       ` Morten Brørup
2025-10-10  7:43         ` Bruce Richardson
2025-10-10  9:22           ` Morten Brørup
2025-10-06 14:43   ` [PATCH v8 0/3] mbuf: simplify handling " Morten Brørup

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=98CBD80474FA8B44BF855DF32C47DC35F654B8@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=fengchengwen@huawei.com \
    --cc=ivan.malov@arknetworks.am \
    --cc=konstantin.ananyev@huawei.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /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).