All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Shay Agroskin <shayagr@amazon.com>,
	David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org
Cc: "Woodhouse, David" <dwmw@amazon.com>,
	"Machulsky, Zorik" <zorik@amazon.com>,
	"Matushevsky, Alexander" <matua@amazon.com>,
	Saeed Bshara <saeedb@amazon.com>, "Wilson, Matt" <msw@amazon.com>,
	"Liguori, Anthony" <aliguori@amazon.com>,
	"Bshara, Nafea" <nafea@amazon.com>,
	"Tzalik, Guy" <gtzalik@amazon.com>,
	"Belgazal, Netanel" <netanel@amazon.com>,
	"Saidi, Ali" <alisaidi@amazon.com>,
	"Herrenschmidt, Benjamin" <benh@amazon.com>,
	"Kiyanovski, Arthur" <akiyano@amazon.com>,
	"Jubran, Samih" <sameehj@amazon.com>,
	"Dagan, Noam" <ndagan@amazon.com>
Subject: Re: [RFC Patch v1 1/3] net: ena: implement local page cache (LPC) system
Date: Tue, 9 Mar 2021 18:57:06 +0100	[thread overview]
Message-ID: <67d3cf28-b1fd-ce51-5011-96ddd783dc71@gmail.com> (raw)
In-Reply-To: <20210309171014.2200020-2-shayagr@amazon.com>



On 3/9/21 6:10 PM, Shay Agroskin wrote:
> The page cache holds pages we allocated in the past during napi cycle,
> and tracks their availability status using page ref count.
> 
> The cache can hold up to 2048 pages. Upon allocating a page, we check
> whether the next entry in the cache contains an unused page, and if so
> fetch it. If the next page is already used by another entity or if it
> belongs to a different NUMA core than the napi routine, we allocate a
> page in the regular way (page from a different NUMA core is replaced by
> the newly allocated page).
> 
> This system can help us reduce the contention between different cores
> when allocating page since every cache is unique to a queue.

For reference, many drivers already use a similar strategy.

> +
> +/* Fetch the cached page (mark the page as used and pass it to the caller).
> + * If the page belongs to a different NUMA than the current one, free the cache
> + * page and allocate another one instead.
> + */
> +static struct page *ena_fetch_cache_page(struct ena_ring *rx_ring,
> +					 struct ena_page *ena_page,
> +					 dma_addr_t *dma,
> +					 int current_nid)
> +{
> +	/* Remove pages belonging to different node than current_nid from cache */
> +	if (unlikely(page_to_nid(ena_page->page) != current_nid)) {
> +		ena_increase_stat(&rx_ring->rx_stats.lpc_wrong_numa, 1, &rx_ring->syncp);
> +		ena_replace_cache_page(rx_ring, ena_page);
> +	}
> +
> 

And they use dev_page_is_reusable() instead of copy/pasting this logic.

As a bonus, they properly deal with pfmemalloc





  reply	other threads:[~2021-03-09 17:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-09 17:10 [RFC Patch v1 0/3] Introduce ENA local page cache Shay Agroskin
2021-03-09 17:10 ` [RFC Patch v1 1/3] net: ena: implement local page cache (LPC) system Shay Agroskin
2021-03-09 17:57   ` Eric Dumazet [this message]
2021-03-10  2:04     ` Andrew Lunn
2021-03-11 23:15       ` Saeed Mahameed
2021-03-16  8:23         ` Shay Agroskin
2021-03-16  8:26     ` Shay Agroskin
2021-03-09 19:22   ` kernel test robot
2021-03-09 17:10 ` [RFC Patch v1 2/3] net: ena: update README file with a description about LPC Shay Agroskin
2021-03-09 17:10 ` [RFC Patch v1 3/3] net: ena: support ethtool priv-flags and LPC state change Shay Agroskin
  -- strict thread matches above, loose matches on Subject: below --
2021-03-09 17:07 [RFC Patch v1 0/3] Introduce ENA local page cache Shay Agroskin
2021-03-09 17:07 ` [RFC Patch v1 1/3] net: ena: implement local page cache (LPC) system Shay Agroskin

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=67d3cf28-b1fd-ce51-5011-96ddd783dc71@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=akiyano@amazon.com \
    --cc=aliguori@amazon.com \
    --cc=alisaidi@amazon.com \
    --cc=benh@amazon.com \
    --cc=davem@davemloft.net \
    --cc=dwmw@amazon.com \
    --cc=gtzalik@amazon.com \
    --cc=kuba@kernel.org \
    --cc=matua@amazon.com \
    --cc=msw@amazon.com \
    --cc=nafea@amazon.com \
    --cc=ndagan@amazon.com \
    --cc=netanel@amazon.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeedb@amazon.com \
    --cc=sameehj@amazon.com \
    --cc=shayagr@amazon.com \
    --cc=zorik@amazon.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 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.