From: Przemek Kitszel <przemyslaw.kitszel@intel.com>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, 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: Wed, 10 Apr 2024 15:12:10 +0200 [thread overview]
Message-ID: <f4874ba7-4933-474a-b5d1-c00e6ec25bbd@intel.com> (raw)
In-Reply-To: <b1438638-a6f9-4a88-b8fe-7bec28ba124f@intel.com>
On 4/10/24 15:01, Alexander Lobakin wrote:
> From: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> Date: Wed, 10 Apr 2024 15:01:32 +0200
>
>> On 4/10/24 13:49, Alexander Lobakin wrote:
>>> From: Przemek Kitszel <przemyslaw.kitszel@intel.com>
>>> Date: Tue, 9 Apr 2024 12:58:33 +0200
>>>
>>>> On 4/8/24 11:09, Alexander Lobakin wrote:
>>>>> From: Przemek Kitszel <przemyslaw.kitszel@intel.com>
>>>>> Date: Fri, 5 Apr 2024 12:32:55 +0200
>>>>>
>>>>>> On 4/4/24 17:44, Alexander Lobakin wrote:
>>>>>>> Add a couple intuitive helpers to hide Rx buffer implementation
>>>>>>> details
>>>>>
>>>>> [...]
>>>>>
>>>>>>> +struct libeth_fqe {
>>>>>>> + struct page *page;
>>>>>>> + u32 offset;
>>>>>>> + u32 truesize;
>>>>>>> +} __aligned_largest;
>>>>>>> +
>>>>>>> +/**
>>>>>>> + * struct libeth_fq - structure representing a buffer queue
>>>>>>> + * @fp: hotpath part of the structure
>>>>>>> + * @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;
>>>>>>> +};
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>> Could you please unpack the meaning of `fq` and `fqe` acronyms here?
>>>>>
>>>>> Rx:
>>>>>
>>>>> RQ -- receive queue, on which you get Rx DMA complete descriptors
>>>>> FQ -- fill queue, the one you fill with free buffers
>>>>> FQE -- fill queue element, i.e. smth like "iavf_rx_buffer" or
>>>>> whatever
>>>>>
>>>>> Tx:
>>>>>
>>>>> SQ -- send queue, the one you fill with buffers to transmit
>>>>> SQE -- send queue element, i.e. "iavf_tx_buffer"
>>>>> CQ -- completion queue, on which you get Tx DMA complete descriptors
>>>>>
>>>>> XDPSQ, XSkRQ etc. -- same as above, but for XDP / XSk
>>>>>
>>>>> I know that rxq, txq, bufq, complq is more common since it's been used
>>>>> for years, but I like these "new" ones more :>
>>>>>
>>>>
>>>> Thank you, that sounds right. If you happen to sent v10, a bit of code
>>>> comment with this info would be useful ;)
>>>
>>> The current kdoc in front of each struct and function declaration is not
>>> enough? :D
>>>
>>> Thanks,
>>> Olek
>>
>> I've asked my initial question just after reading it thrice, without
>> your reply `FQE` was as meaningful as `ABC`
>
> In the commit:
>
> + * struct libeth_fqe - structure representing an Rx buffer
>
> :z
>
> or you want me to expand FQ, FQE etc. abbrevs in the kdoc?
yes, please very much!
could be as an additional comment at the top of the file too,
with that you could reuse the naming convention later in the file
>
> Thanks,
> Olek
next prev parent reply other threads:[~2024-04-10 13:24 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-04 15:43 [PATCH net-next v9 0/9] net: intel: start The Great Code Dedup + Page Pool for iavf Alexander Lobakin
2024-04-04 15:43 ` [PATCH net-next v9 1/9] net: intel: introduce {,Intel} Ethernet common library Alexander Lobakin
2024-04-04 15:43 ` [PATCH net-next v9 2/9] iavf: kill "legacy-rx" for good Alexander Lobakin
2024-04-05 10:15 ` Przemek Kitszel
2024-04-04 15:43 ` [PATCH net-next v9 3/9] iavf: drop page splitting and recycling Alexander Lobakin
2024-04-04 15:43 ` [PATCH net-next v9 4/9] slab: introduce kvmalloc_array_node() and kvcalloc_node() Alexander Lobakin
2024-04-05 10:12 ` Przemek Kitszel
2024-04-05 10:44 ` Vlastimil Babka
2024-04-04 15:43 ` [PATCH net-next v9 5/9] page_pool: constify some read-only function arguments Alexander Lobakin
2024-04-04 15:43 ` [PATCH net-next v9 6/9] page_pool: add DMA-sync-for-CPU inline helper Alexander Lobakin
2024-04-04 15:44 ` [PATCH net-next v9 7/9] libeth: add Rx buffer management Alexander Lobakin
2024-04-05 10:32 ` Przemek Kitszel
2024-04-08 9:09 ` Alexander Lobakin
2024-04-09 10:58 ` Przemek Kitszel
2024-04-10 11:49 ` Alexander Lobakin
2024-04-10 13:01 ` Przemek Kitszel
2024-04-10 13:01 ` Alexander Lobakin
2024-04-10 13:12 ` Przemek Kitszel [this message]
2024-04-06 4:25 ` Jakub Kicinski
2024-04-08 9:11 ` Alexander Lobakin
2024-04-08 9:45 ` Alexander Lobakin
2024-04-09 16:17 ` Kees Cook
2024-04-10 13:36 ` Alexander Lobakin
2024-04-11 0:54 ` Jakub Kicinski
2024-04-11 9:07 ` Alexander Lobakin
2024-04-11 13:45 ` Jakub Kicinski
2024-04-04 15:44 ` [PATCH net-next v9 8/9] iavf: pack iavf_ring more efficiently Alexander Lobakin
2024-04-04 15:44 ` [PATCH net-next v9 9/9] iavf: switch to Page Pool 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=f4874ba7-4933-474a-b5d1-c00e6ec25bbd@intel.com \
--to=przemyslaw.kitszel@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox