mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Yunsheng Lin <linyunsheng@huawei.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
	Larysa Zaremba <larysa.zaremba@intel.com>,
	Alexander Duyck <alexanderduyck@fb.com>,
	Jesper Dangaard Brouer <hawk@kernel.org>,
	"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
	Simon Horman <simon.horman@corigine.com>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next 6/9] page_pool: avoid calling no-op externals when possible
Date: Fri, 28 Jul 2023 16:14:13 +0200	[thread overview]
Message-ID: <604d4f6c-a6e7-e921-2d9a-45fe46ab9e79@intel.com> (raw)
In-Reply-To: <a79cc7ed-5355-ef7d-8865-0ba9673af5c6@huawei.com>

From: Yunsheng Lin <linyunsheng@huawei.com>
Date: Fri, 28 Jul 2023 20:39:24 +0800

> On 2023/7/27 22:43, Alexander Lobakin wrote:
>> Turned out page_pool_put{,_full}_page() can burn quite a bunch of cycles
>> even when on DMA-coherent platforms (like x86) with no active IOMMU or
>> swiotlb, just for the call ladder.
>> Indeed, it's
>>
>> page_pool_put_page()
>>   page_pool_put_defragged_page()                  <- external
>>     __page_pool_put_page()
>>       page_pool_dma_sync_for_device()             <- non-inline
>>         dma_sync_single_range_for_device()
>>           dma_sync_single_for_device()            <- external
>>             dma_direct_sync_single_for_device()
>>               dev_is_dma_coherent()               <- exit
>>
>> For the inline functions, no guarantees the compiler won't uninline them
>> (they're clearly not one-liners and sometimes compilers uninline even
>> 2 + 2). The first external call is necessary, but the rest 2+ are done
>> for nothing each time, plus a bunch of checks here and there.
>> Since Page Pool mappings are long-term and for one "device + addr" pair
>> dma_need_sync() will always return the same value (basically, whether it
>> belongs to an swiotlb pool), addresses can be tested once right after
>> they're obtained and the result can be reused until the page is unmapped.
>> Define the new PP DMA sync operation type, which will mean "do DMA syncs
>> for the device, but only when needed" and turn it on by default when the
>> driver asks to sync pages. When a page is mapped, check whether it needs
>> syncs and if so, replace that "sync when needed" back to "always do
>> syncs" globally for the whole pool (better safe than sorry). As long as
>> the pool has no pages requiring DMA syncs, this cuts off a good piece
>> of calls and checks. When at least one page required it, the pool
>> conservatively falls back to "always call sync functions", no per-page
>> verdicts. It's a fairly rare case anyway that only a few pages would
>> require syncing.
>> On my x86_64, this gives from 2% to 5% performance benefit with no
>> negative impact for cases when IOMMU is on and the shortcut can't be
>> used.
>>
> 
> It seems other subsystem may have the similar problem as page_pool,
> is it possible to implement this kind of trick in the dma subsystem
> instead of every subsystem inventing their own trick?

In the ladder I described above most of overhead comes from jumping
between Page Pool functions, not the generic DMA ones. Let's say I do
this shortcut in dma_sync_single_range_for_device(), that is too late
already to count on some good CPU saves.
Plus, DMA sync API operates with dma_addr_t, not struct page. IOW it's
not clear to me where to store this "we can shortcut" bit in that case.

From "other subsystem" I remember only XDP sockets. There, they also
avoid calling their own non-inline functions in the first place, not the
generic DMA ones. So I'd say both cases (PP and XSk) can't be solved via
some "generic" solution.

Thanks,
Olek

  reply	other threads:[~2023-07-28 14:21 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-27 14:43 [PATCH net-next 0/9] page_pool: a couple of assorted optimizations Alexander Lobakin
2023-07-27 14:43 ` [PATCH net-next 1/9] page_pool: split types and declarations from page_pool.h Alexander Lobakin
2023-07-28 11:58   ` Yunsheng Lin
2023-07-28 13:55     ` Alexander Lobakin
2023-07-27 14:43 ` [PATCH net-next 2/9] net: skbuff: don't include <net/page_pool/types.h> to <linux/skbuff.h> Alexander Lobakin
2023-07-28 12:02   ` Yunsheng Lin
2023-07-28 13:58     ` Alexander Lobakin
2023-07-29 11:40       ` Yunsheng Lin
2023-08-01 13:25         ` Alexander Lobakin
2023-07-27 14:43 ` [PATCH net-next 3/9] page_pool: place frag_* fields in one cacheline Alexander Lobakin
2023-07-27 14:43 ` [PATCH net-next 4/9] page_pool: shrink &page_pool_params a tiny bit Alexander Lobakin
2023-07-27 14:43 ` [PATCH net-next 5/9] page_pool: don't use driver-set flags field directly Alexander Lobakin
2023-07-28 12:36   ` Yunsheng Lin
2023-07-28 14:03     ` Alexander Lobakin
2023-07-28 15:50       ` Jakub Kicinski
2023-07-29 11:40       ` Yunsheng Lin
2023-08-01 13:36         ` Alexander Lobakin
2023-08-02 11:36           ` Yunsheng Lin
2023-08-02 21:29           ` Jakub Kicinski
2023-08-03 14:56             ` Alexander Lobakin
2023-08-03 16:00               ` Jakub Kicinski
2023-08-03 16:07                 ` Alexander Lobakin
2023-08-03 16:40                   ` Jakub Kicinski
2023-08-03 16:42                     ` Alexander Lobakin
2023-07-27 14:43 ` [PATCH net-next 6/9] page_pool: avoid calling no-op externals when possible Alexander Lobakin
2023-07-28 12:39   ` Yunsheng Lin
2023-07-28 14:14     ` Alexander Lobakin [this message]
2023-07-29 12:46       ` Yunsheng Lin
2023-08-01 13:42         ` Alexander Lobakin
2023-08-02 11:37           ` Yunsheng Lin
2023-08-02 15:49             ` Alexander Lobakin
2023-07-27 14:43 ` [PATCH net-next 7/9] net: skbuff: avoid accessing page_pool if !napi_safe when returning page Alexander Lobakin
2023-07-27 14:43 ` [PATCH net-next 8/9] page_pool: add a lockdep check for recycling in hardirq Alexander Lobakin
2023-07-27 14:43 ` [PATCH net-next 9/9] net: skbuff: always try to recycle PP pages directly when in softirq Alexander Lobakin
2023-07-28  9:32   ` Jesper Dangaard Brouer
2023-07-28 13:50     ` 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=604d4f6c-a6e7-e921-2d9a-45fe46ab9e79@intel.com \
    --to=aleksander.lobakin@intel.com \
    --cc=alexanderduyck@fb.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hawk@kernel.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=kuba@kernel.org \
    --cc=larysa.zaremba@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linyunsheng@huawei.com \
    --cc=maciej.fijalkowski@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=simon.horman@corigine.com \
    /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

all inboxes | Powered by JetHome®