From: Eric Dumazet <eric.dumazet@gmail.com>
To: Tariq Toukan <tariqt@mellanox.com>,
Eric Dumazet <eric.dumazet@gmail.com>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Matthew Wilcox <willy@infradead.org>,
"brouer@redhat.com" <brouer@redhat.com>
Cc: David Miller <davem@davemloft.net>,
"toke@redhat.com" <toke@redhat.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"mgorman@techsingularity.net" <mgorman@techsingularity.net>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [RFC, PATCH] net: page_pool: Don't use page->private to store dma_addr_t
Date: Tue, 12 Feb 2019 07:15:55 -0800 [thread overview]
Message-ID: <d8fa6786-c252-6bb0-409f-42ce18127cb3@gmail.com> (raw)
In-Reply-To: <27e97aac-f25b-d46c-3e70-7d0d44f784b5@mellanox.com>
On 02/12/2019 04:39 AM, Tariq Toukan wrote:
>
>
> On 2/11/2019 7:14 PM, Eric Dumazet wrote:
>>
>>
>> On 02/11/2019 12:53 AM, Tariq Toukan wrote:
>>>
>>
>>> Hi,
>>>
>>> It's great to use the struct page to store its dma mapping, but I am
>>> worried about extensibility.
>>> page_pool is evolving, and it would need several more per-page fields.
>>> One of them would be pageref_bias, a planned optimization to reduce the
>>> number of the costly atomic pageref operations (and replace existing
>>> code in several drivers).
>>>
>>
>> But the point about pageref_bias is to place it in a different cache line than "struct page"
>>
>> The major cost is having a cache line bouncing between producer and consumer.
>>
>
> pageref_bias is meant to be dirtied only by the page requester, i.e. the
> NIC driver / page_pool.
> All other components (basically, SKB release flow / put_page) should
> continue working with the atomic page_refcnt, and not dirty the
> pageref_bias.
This is exactly my point.
You suggested to put pageref_bias in struct page, which breaks this completely.
pageref_bias is better kept in a driver structure, with appropriate prefetching
since most NIC use a ring buffer for their queues.
The dma address _can_ be put in the struct page, since the driver does not dirty it
and does not even read it when page can be recycled.
next prev parent reply other threads:[~2019-02-12 15:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-07 14:36 [RFC, PATCH] net: page_pool: Don't use page->private to store dma_addr_t Ilias Apalodimas
2019-02-07 15:07 ` Matthew Wilcox
2019-02-07 15:20 ` Ilias Apalodimas
2019-02-07 21:25 ` David Miller
2019-02-07 21:34 ` Matthew Wilcox
2019-02-07 21:42 ` Ilias Apalodimas
2019-02-11 8:53 ` Tariq Toukan
2019-02-11 12:12 ` Matthew Wilcox
2019-02-11 15:38 ` Tariq Toukan
2019-02-11 17:14 ` Eric Dumazet
2019-02-12 12:39 ` Tariq Toukan
2019-02-12 13:49 ` Jesper Dangaard Brouer
2019-02-12 14:58 ` Tariq Toukan
2019-02-12 15:15 ` Eric Dumazet [this message]
2019-02-12 18:13 ` Alexander Duyck
2019-02-12 18:20 ` Ilias Apalodimas
2019-02-13 8:50 ` Tariq Toukan
2019-02-13 8:46 ` Tariq Toukan
2019-02-07 21:37 ` Ilias Apalodimas
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=d8fa6786-c252-6bb0-409f-42ce18127cb3@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=brouer@redhat.com \
--cc=davem@davemloft.net \
--cc=ilias.apalodimas@linaro.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=netdev@vger.kernel.org \
--cc=tariqt@mellanox.com \
--cc=toke@redhat.com \
--cc=willy@infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).