From: Kees Cook <keescook@chromium.org>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: Jesper Dangaard Brouer <hawk@kernel.org>,
netdev@vger.kernel.org, Alexander Duyck <alexanderduyck@fb.com>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Yunsheng Lin <linyunsheng@huawei.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Eric Dumazet <edumazet@google.com>,
intel-wired-lan@lists.osuosl.org,
nex.sw.ncis.osdt.itp.upstreaming@intel.com,
Jakub Kicinski <kuba@kernel.org>,
Christoph Lameter <cl@linux.com>, Paolo Abeni <pabeni@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [Intel-wired-lan] [PATCH net-next v9 7/9] libeth: add Rx buffer management
Date: Tue, 9 Apr 2024 09:17:53 -0700 [thread overview]
Message-ID: <202404090909.51BAC81A6@keescook> (raw)
In-Reply-To: <755c17b2-0ec2-49dd-9352-63e5d2f1ba4c@intel.com>
On Mon, Apr 08, 2024 at 11:45:32AM +0200, Alexander Lobakin wrote:
> From: Alexander Lobakin <aleksander.lobakin@intel.com>
> Date: Mon, 8 Apr 2024 11:11:12 +0200
>
> > From: Jakub Kicinski <kuba@kernel.org>
> > Date: Fri, 5 Apr 2024 21:25:13 -0700
> >
> >> On Thu, 4 Apr 2024 17:44:00 +0200 Alexander Lobakin wrote:
> >>> +/**
> >>> + * struct libeth_fq - structure representing a buffer queue
> >>> + * @fp: hotpath part of the structure
> >>
> >> Second time this happens this week, so maybe some tooling change in 6.9
> >> but apparently kdoc does not want to know about the tagged struct:
> >>
> >> include/net/libeth/rx.h:69: warning: Excess struct member 'fp' description in 'libeth_fq'
> >
> > Oh no, maybe we should teach kdoc to parse struct_group*()?
>
> scripts/kernel-doc apparently can handle them...
>
> + Kees
>
Ah, hm, scripts/kernel-doc throws away the early arguments of
struct_group_tagged, but I suspect it needs to create a synthetic member
for the tag. i.e. instead of:
struct_group_tagged(tag, name, members...)
becoming
members...
it needs to become
struct tag name;
members...
It seems this is the first place anyone has tried to document the tagged
struct name! :)
Does this work? I haven't tested it...
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 967f1abb0edb..64a19228d5dd 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1151,7 +1151,8 @@ sub dump_struct($$) {
# - first eat non-declaration parameters and rewrite for final match
# - then remove macro, outer parens, and trailing semicolon
$members =~ s/\bstruct_group\s*\(([^,]*,)/STRUCT_GROUP(/gos;
- $members =~ s/\bstruct_group_(attr|tagged)\s*\(([^,]*,){2}/STRUCT_GROUP(/gos;
+ $members =~ s/\bstruct_group_attr\s*\(([^,]*,){2}/STRUCT_GROUP(/gos;
+ $members =~ s/\bstruct_group_tagged\s*\(([^,]*,)([^,]*,)/struct $1 $2; STRUCT_GROUP(/gos;
$members =~ s/\b__struct_group\s*\(([^,]*,){3}/STRUCT_GROUP(/gos;
$members =~ s/\bSTRUCT_GROUP(\(((?:(?>[^)(]+)|(?1))*)\))[^;]*;/$2/gos;
> >
> >>
> >>> + * @pp: &page_pool for buffer management
> >>> + * @fqes: array of Rx buffers
> >>> + * @truesize: size to allocate per buffer, w/overhead
> >>> + * @count: number of descriptors/buffers the queue has
> >>> + * @buf_len: HW-writeable length per each buffer
> >>> + * @nid: ID of the closest NUMA node with memory
> >>> + */
> >>> +struct libeth_fq {
> >>> + struct_group_tagged(libeth_fq_fp, fp,
> >>> + struct page_pool *pp;
> >>> + struct libeth_fqe *fqes;
> >>> +
> >>> + u32 truesize;
> >>> + u32 count;
> >>> + );
> >>> +
> >>> + /* Cold fields */
> >>> + u32 buf_len;
> >>> + int nid;
> >>> +};
>
> Thanks,
> Olek
--
Kees Cook
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Alexander Duyck <alexanderduyck@fb.com>,
Yunsheng Lin <linyunsheng@huawei.com>,
Jesper Dangaard Brouer <hawk@kernel.org>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Christoph Lameter <cl@linux.com>,
Vlastimil Babka <vbabka@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
nex.sw.ncis.osdt.itp.upstreaming@intel.com,
netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v9 7/9] libeth: add Rx buffer management
Date: Tue, 9 Apr 2024 09:17:53 -0700 [thread overview]
Message-ID: <202404090909.51BAC81A6@keescook> (raw)
In-Reply-To: <755c17b2-0ec2-49dd-9352-63e5d2f1ba4c@intel.com>
On Mon, Apr 08, 2024 at 11:45:32AM +0200, Alexander Lobakin wrote:
> From: Alexander Lobakin <aleksander.lobakin@intel.com>
> Date: Mon, 8 Apr 2024 11:11:12 +0200
>
> > From: Jakub Kicinski <kuba@kernel.org>
> > Date: Fri, 5 Apr 2024 21:25:13 -0700
> >
> >> On Thu, 4 Apr 2024 17:44:00 +0200 Alexander Lobakin wrote:
> >>> +/**
> >>> + * struct libeth_fq - structure representing a buffer queue
> >>> + * @fp: hotpath part of the structure
> >>
> >> Second time this happens this week, so maybe some tooling change in 6.9
> >> but apparently kdoc does not want to know about the tagged struct:
> >>
> >> include/net/libeth/rx.h:69: warning: Excess struct member 'fp' description in 'libeth_fq'
> >
> > Oh no, maybe we should teach kdoc to parse struct_group*()?
>
> scripts/kernel-doc apparently can handle them...
>
> + Kees
>
Ah, hm, scripts/kernel-doc throws away the early arguments of
struct_group_tagged, but I suspect it needs to create a synthetic member
for the tag. i.e. instead of:
struct_group_tagged(tag, name, members...)
becoming
members...
it needs to become
struct tag name;
members...
It seems this is the first place anyone has tried to document the tagged
struct name! :)
Does this work? I haven't tested it...
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 967f1abb0edb..64a19228d5dd 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1151,7 +1151,8 @@ sub dump_struct($$) {
# - first eat non-declaration parameters and rewrite for final match
# - then remove macro, outer parens, and trailing semicolon
$members =~ s/\bstruct_group\s*\(([^,]*,)/STRUCT_GROUP(/gos;
- $members =~ s/\bstruct_group_(attr|tagged)\s*\(([^,]*,){2}/STRUCT_GROUP(/gos;
+ $members =~ s/\bstruct_group_attr\s*\(([^,]*,){2}/STRUCT_GROUP(/gos;
+ $members =~ s/\bstruct_group_tagged\s*\(([^,]*,)([^,]*,)/struct $1 $2; STRUCT_GROUP(/gos;
$members =~ s/\b__struct_group\s*\(([^,]*,){3}/STRUCT_GROUP(/gos;
$members =~ s/\bSTRUCT_GROUP(\(((?:(?>[^)(]+)|(?1))*)\))[^;]*;/$2/gos;
> >
> >>
> >>> + * @pp: &page_pool for buffer management
> >>> + * @fqes: array of Rx buffers
> >>> + * @truesize: size to allocate per buffer, w/overhead
> >>> + * @count: number of descriptors/buffers the queue has
> >>> + * @buf_len: HW-writeable length per each buffer
> >>> + * @nid: ID of the closest NUMA node with memory
> >>> + */
> >>> +struct libeth_fq {
> >>> + struct_group_tagged(libeth_fq_fp, fp,
> >>> + struct page_pool *pp;
> >>> + struct libeth_fqe *fqes;
> >>> +
> >>> + u32 truesize;
> >>> + u32 count;
> >>> + );
> >>> +
> >>> + /* Cold fields */
> >>> + u32 buf_len;
> >>> + int nid;
> >>> +};
>
> Thanks,
> Olek
--
Kees Cook
next prev parent reply other threads:[~2024-04-09 16:18 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-04 15:43 [Intel-wired-lan] [PATCH net-next v9 0/9] net: intel: start The Great Code Dedup + Page Pool for iavf Alexander Lobakin
2024-04-04 15:43 ` Alexander Lobakin
2024-04-04 15:43 ` [Intel-wired-lan] [PATCH net-next v9 1/9] net: intel: introduce {, Intel} Ethernet common library Alexander Lobakin
2024-04-04 15:43 ` [PATCH net-next v9 1/9] net: intel: introduce {,Intel} " Alexander Lobakin
2024-04-04 15:43 ` [Intel-wired-lan] [PATCH net-next v9 2/9] iavf: kill "legacy-rx" for good Alexander Lobakin
2024-04-04 15:43 ` Alexander Lobakin
2024-04-05 10:15 ` [Intel-wired-lan] " Przemek Kitszel
2024-04-05 10:15 ` Przemek Kitszel
2024-04-04 15:43 ` [Intel-wired-lan] [PATCH net-next v9 3/9] iavf: drop page splitting and recycling Alexander Lobakin
2024-04-04 15:43 ` Alexander Lobakin
2024-04-04 15:43 ` [Intel-wired-lan] [PATCH net-next v9 4/9] slab: introduce kvmalloc_array_node() and kvcalloc_node() Alexander Lobakin
2024-04-04 15:43 ` Alexander Lobakin
2024-04-05 10:12 ` [Intel-wired-lan] " Przemek Kitszel
2024-04-05 10:12 ` Przemek Kitszel
2024-04-05 10:44 ` [Intel-wired-lan] " Vlastimil Babka
2024-04-05 10:44 ` Vlastimil Babka
2024-04-04 15:43 ` [Intel-wired-lan] [PATCH net-next v9 5/9] page_pool: constify some read-only function arguments Alexander Lobakin
2024-04-04 15:43 ` Alexander Lobakin
2024-04-04 15:43 ` [Intel-wired-lan] [PATCH net-next v9 6/9] page_pool: add DMA-sync-for-CPU inline helper Alexander Lobakin
2024-04-04 15:43 ` Alexander Lobakin
2024-04-04 15:44 ` [Intel-wired-lan] [PATCH net-next v9 7/9] libeth: add Rx buffer management Alexander Lobakin
2024-04-04 15:44 ` Alexander Lobakin
2024-04-05 10:32 ` [Intel-wired-lan] " Przemek Kitszel
2024-04-05 10:32 ` Przemek Kitszel
2024-04-08 9:09 ` [Intel-wired-lan] " Alexander Lobakin
2024-04-08 9:09 ` Alexander Lobakin
2024-04-09 10:58 ` [Intel-wired-lan] " Przemek Kitszel
2024-04-09 10:58 ` Przemek Kitszel
2024-04-10 11:49 ` [Intel-wired-lan] " Alexander Lobakin
2024-04-10 11:49 ` Alexander Lobakin
2024-04-10 13:01 ` [Intel-wired-lan] " Przemek Kitszel
2024-04-10 13:01 ` Przemek Kitszel
2024-04-10 13:01 ` [Intel-wired-lan] " Alexander Lobakin
2024-04-10 13:01 ` Alexander Lobakin
2024-04-10 13:12 ` [Intel-wired-lan] " Przemek Kitszel
2024-04-10 13:12 ` Przemek Kitszel
2024-04-06 4:25 ` [Intel-wired-lan] " Jakub Kicinski
2024-04-06 4:25 ` Jakub Kicinski
2024-04-08 9:11 ` [Intel-wired-lan] " Alexander Lobakin
2024-04-08 9:11 ` Alexander Lobakin
2024-04-08 9:45 ` [Intel-wired-lan] " Alexander Lobakin
2024-04-08 9:45 ` Alexander Lobakin
2024-04-09 16:17 ` Kees Cook [this message]
2024-04-09 16:17 ` Kees Cook
2024-04-10 13:36 ` [Intel-wired-lan] " Alexander Lobakin
2024-04-10 13:36 ` Alexander Lobakin
2024-04-11 0:54 ` [Intel-wired-lan] " Jakub Kicinski
2024-04-11 0:54 ` Jakub Kicinski
2024-04-11 9:07 ` [Intel-wired-lan] " Alexander Lobakin
2024-04-11 9:07 ` Alexander Lobakin
2024-04-11 13:45 ` [Intel-wired-lan] " Jakub Kicinski
2024-04-11 13:45 ` Jakub Kicinski
2024-04-04 15:44 ` [Intel-wired-lan] [PATCH net-next v9 8/9] iavf: pack iavf_ring more efficiently Alexander Lobakin
2024-04-04 15:44 ` Alexander Lobakin
2024-04-04 15:44 ` [Intel-wired-lan] [PATCH net-next v9 9/9] iavf: switch to Page Pool Alexander Lobakin
2024-04-04 15:44 ` Alexander Lobakin
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=202404090909.51BAC81A6@keescook \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=aleksander.lobakin@intel.com \
--cc=alexanderduyck@fb.com \
--cc=cl@linux.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linyunsheng@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=nex.sw.ncis.osdt.itp.upstreaming@intel.com \
--cc=pabeni@redhat.com \
--cc=vbabka@suse.cz \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.