From: Jakub Kicinski <kuba@kernel.org>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>,
Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
Jesper Dangaard Brouer <hawk@kernel.org>,
Eric Dumazet <edumazet@google.com>,
Larysa Zaremba <larysa.zaremba@intel.com>,
netdev@vger.kernel.org, Alexander Duyck <alexanderduyck@fb.com>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
linux-kernel@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
Yunsheng Lin <linyunsheng@huawei.com>,
Michal Kubiak <michal.kubiak@intel.com>,
intel-wired-lan@lists.osuosl.org,
David Christensen <drc@linux.vnet.ibm.com>,
Paolo Abeni <pabeni@redhat.com>, Christoph Hellwig <hch@lst.de>
Subject: Re: [Intel-wired-lan] [PATCH net-next v5 03/14] page_pool: avoid calling no-op externals when possible
Date: Mon, 27 Nov 2023 10:17:20 -0800 [thread overview]
Message-ID: <20231127101720.282862f6@kernel.org> (raw)
In-Reply-To: <a1a0c27f-f367-40e7-9dc2-9421b4b6379a@intel.com>
On Mon, 27 Nov 2023 15:32:19 +0100 Alexander Lobakin wrote:
> > Sorry for not remembering the suggestion:(
>
> In the previous versions of this change I used a global flag per whole
> page_pool, just like XSk does for the whole XSk buff pool, then you
> proposed to use the lowest bit of ::dma_addr and store it per page, so
> that it would be more granular/precise. I tested it and it doesn't
> perform worse than global, but in some cases may be beneficial.
FWIW I'd vote to stick to per-page pool. You seem to handle the
sizeof(dma_addr_t) > sizeof(long) case correctly but the code is
growing in complexity, providing no known/measurable benefit.
We can always do this later but for now it seems like a premature
optimization to me.
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: Yunsheng Lin <linyunsheng@huawei.com>,
Christoph Hellwig <hch@lst.de>,
Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
Michal Kubiak <michal.kubiak@intel.com>,
Larysa Zaremba <larysa.zaremba@intel.com>,
Alexander Duyck <alexanderduyck@fb.com>,
David Christensen <drc@linux.vnet.ibm.com>,
Jesper Dangaard Brouer <hawk@kernel.org>,
"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
Paul Menzel <pmenzel@molgen.mpg.de>, <netdev@vger.kernel.org>,
<intel-wired-lan@lists.osuosl.org>,
<linux-kernel@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>
Subject: Re: [PATCH net-next v5 03/14] page_pool: avoid calling no-op externals when possible
Date: Mon, 27 Nov 2023 10:17:20 -0800 [thread overview]
Message-ID: <20231127101720.282862f6@kernel.org> (raw)
In-Reply-To: <a1a0c27f-f367-40e7-9dc2-9421b4b6379a@intel.com>
On Mon, 27 Nov 2023 15:32:19 +0100 Alexander Lobakin wrote:
> > Sorry for not remembering the suggestion:(
>
> In the previous versions of this change I used a global flag per whole
> page_pool, just like XSk does for the whole XSk buff pool, then you
> proposed to use the lowest bit of ::dma_addr and store it per page, so
> that it would be more granular/precise. I tested it and it doesn't
> perform worse than global, but in some cases may be beneficial.
FWIW I'd vote to stick to per-page pool. You seem to handle the
sizeof(dma_addr_t) > sizeof(long) case correctly but the code is
growing in complexity, providing no known/measurable benefit.
We can always do this later but for now it seems like a premature
optimization to me.
next prev parent reply other threads:[~2023-11-27 18:17 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-24 15:47 [Intel-wired-lan] [PATCH net-next v5 00/14] net: intel: start The Great Code Dedup + Page Pool for iavf Alexander Lobakin
2023-11-24 15:47 ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 01/14] page_pool: make sure frag API fields don't span between cachelines Alexander Lobakin
2023-11-24 15:47 ` Alexander Lobakin
2023-11-25 12:29 ` [Intel-wired-lan] " Yunsheng Lin
2023-11-25 12:29 ` Yunsheng Lin
2023-11-27 14:08 ` [Intel-wired-lan] " Alexander Lobakin
2023-11-27 14:08 ` Alexander Lobakin
2023-11-29 2:55 ` [Intel-wired-lan] " Yunsheng Lin
2023-11-29 2:55 ` Yunsheng Lin
2023-11-29 13:12 ` [Intel-wired-lan] " Alexander Lobakin
2023-11-29 13:12 ` Alexander Lobakin
2023-11-26 22:54 ` [Intel-wired-lan] " Jakub Kicinski
2023-11-26 22:54 ` Jakub Kicinski
2023-11-27 14:12 ` [Intel-wired-lan] " Alexander Lobakin
2023-11-27 14:12 ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 02/14] page_pool: don't use driver-set flags field directly Alexander Lobakin
2023-11-24 15:47 ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 03/14] page_pool: avoid calling no-op externals when possible Alexander Lobakin
2023-11-24 15:47 ` Alexander Lobakin
2023-11-25 13:04 ` [Intel-wired-lan] " Yunsheng Lin
2023-11-25 13:04 ` Yunsheng Lin
2023-11-27 14:32 ` [Intel-wired-lan] " Alexander Lobakin
2023-11-27 14:32 ` Alexander Lobakin
2023-11-27 18:17 ` Jakub Kicinski [this message]
2023-11-27 18:17 ` Jakub Kicinski
2023-11-28 16:50 ` [Intel-wired-lan] " Alexander Lobakin
2023-11-28 16:50 ` Alexander Lobakin
2023-11-29 3:17 ` [Intel-wired-lan] " Yunsheng Lin
2023-11-29 3:17 ` Yunsheng Lin
2023-11-29 13:17 ` [Intel-wired-lan] " Alexander Lobakin
2023-11-29 13:17 ` Alexander Lobakin
2023-11-30 8:46 ` Yunsheng Lin
2023-11-30 8:46 ` Yunsheng Lin
2023-11-30 11:58 ` Alexander Lobakin
2023-11-30 11:58 ` Alexander Lobakin
2023-11-30 12:20 ` Yunsheng Lin
2023-11-30 12:20 ` Yunsheng Lin
2023-12-01 14:37 ` Alexander Lobakin
2023-12-01 14:37 ` Alexander Lobakin
2023-12-12 15:25 ` Christoph Hellwig
2023-12-12 15:25 ` Christoph Hellwig
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 04/14] net: intel: introduce Intel Ethernet common library Alexander Lobakin
2023-11-24 15:47 ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 05/14] iavf: kill "legacy-rx" for good Alexander Lobakin
2023-11-24 15:47 ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 06/14] iavf: drop page splitting and recycling Alexander Lobakin
2023-11-24 15:47 ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 07/14] page_pool: constify some read-only function arguments Alexander Lobakin
2023-11-24 15:47 ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 08/14] page_pool: add DMA-sync-for-CPU inline helpers Alexander Lobakin
2023-11-24 15:47 ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 09/14] libie: add Rx buffer management (via Page Pool) Alexander Lobakin
2023-11-24 15:47 ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 10/14] iavf: pack iavf_ring more efficiently Alexander Lobakin
2023-11-24 15:47 ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 11/14] iavf: switch to Page Pool Alexander Lobakin
2023-11-24 15:47 ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 12/14] libie: add common queue stats Alexander Lobakin
2023-11-24 15:47 ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 13/14] libie: add per-queue Page Pool stats Alexander Lobakin
2023-11-24 15:47 ` Alexander Lobakin
2023-11-29 13:40 ` [Intel-wired-lan] " Alexander Lobakin
2023-11-29 13:40 ` Alexander Lobakin
2023-11-29 14:29 ` [Intel-wired-lan] " Jakub Kicinski
2023-11-29 14:29 ` Jakub Kicinski
2023-11-30 16:01 ` [Intel-wired-lan] " Alexander Lobakin
2023-11-30 16:01 ` Alexander Lobakin
2023-11-30 16:45 ` [Intel-wired-lan] " Alexander Lobakin
2023-11-30 16:45 ` Alexander Lobakin
2023-12-01 6:55 ` [Intel-wired-lan] " Jakub Kicinski
2023-12-01 6:55 ` Jakub Kicinski
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 14/14] iavf: switch queue stats to libie Alexander Lobakin
2023-11-24 15:47 ` Alexander Lobakin
2023-11-27 9:04 ` [Intel-wired-lan] [PATCH net-next v5 00/14] net: intel: start The Great Code Dedup + Page Pool for iavf Jiri Pirko
2023-11-27 9:04 ` Jiri Pirko
2023-11-27 10:23 ` [Intel-wired-lan] " Przemek Kitszel
2023-11-27 10:23 ` Przemek Kitszel
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=20231127101720.282862f6@kernel.org \
--to=kuba@kernel.org \
--cc=aleksander.lobakin@intel.com \
--cc=alexanderduyck@fb.com \
--cc=davem@davemloft.net \
--cc=drc@linux.vnet.ibm.com \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=hch@lst.de \
--cc=ilias.apalodimas@linaro.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=larysa.zaremba@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linyunsheng@huawei.com \
--cc=maciej.fijalkowski@intel.com \
--cc=michal.kubiak@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pmenzel@molgen.mpg.de \
/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.