All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Przemek Kitszel <przemyslaw.kitszel@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: Mon, 8 Apr 2024 11:09:44 +0200	[thread overview]
Message-ID: <bebf1a1a-e4ec-4ec0-9d01-57a51bcf14ca@intel.com> (raw)
In-Reply-To: <45eb2bf1-e7b0-4045-82b3-93b9f81b7988@intel.com>

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 :>

> 
> otherwise the whole series is very good for me, thank you very much!
> 

Thanks,
Olek

WARNING: multiple messages have this Message-ID (diff)
From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Przemek Kitszel <przemyslaw.kitszel@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: Mon, 8 Apr 2024 11:09:44 +0200	[thread overview]
Message-ID: <bebf1a1a-e4ec-4ec0-9d01-57a51bcf14ca@intel.com> (raw)
In-Reply-To: <45eb2bf1-e7b0-4045-82b3-93b9f81b7988@intel.com>

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 :>

> 
> otherwise the whole series is very good for me, thank you very much!
> 

Thanks,
Olek


  reply	other threads:[~2024-04-08  9:11 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     ` Alexander Lobakin [this message]
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         ` [Intel-wired-lan] " Kees Cook
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=bebf1a1a-e4ec-4ec0-9d01-57a51bcf14ca@intel.com \
    --to=aleksander.lobakin@intel.com \
    --cc=akpm@linux-foundation.org \
    --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=przemyslaw.kitszel@intel.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.