From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Alexander Lobakin <alobakin@pm.me>
Cc: Matteo Croce <mcroce@linux.microsoft.com>,
Jesper Dangaard Brouer <jbrouer@redhat.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Jonathan Lemon <jonathan.lemon@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Jesper Dangaard Brouer <hawk@kernel.org>,
Lorenzo Bianconi <lorenzo@kernel.org>,
Saeed Mahameed <saeedm@nvidia.com>,
David Ahern <dsahern@gmail.com>,
Saeed Mahameed <saeed@kernel.org>, Andrew Lunn <andrew@lunn.ch>
Subject: Re: [PATCH net-next 0/6] page_pool: recycle buffers
Date: Tue, 23 Mar 2021 19:01:52 +0200 [thread overview]
Message-ID: <YFofANKiR3tD9zgm@enceladus> (raw)
In-Reply-To: <20210323165523.187134-1-alobakin@pm.me>
On Tue, Mar 23, 2021 at 04:55:31PM +0000, Alexander Lobakin wrote:
> > > > > >
[...]
> > > > >
> > > > > Thanks for the testing!
> > > > > Any chance you can get a perf measurement on this?
> > > >
> > > > I guess you mean perf-report (--stdio) output, right?
> > > >
> > >
> > > Yea,
> > > As hinted below, I am just trying to figure out if on Alexander's platform the
> > > cost of syncing, is bigger that free-allocate. I remember one armv7 were that
> > > was the case.
> > >
> > > > > Is DMA syncing taking a substantial amount of your cpu usage?
> > > >
> > > > (+1 this is an important question)
>
> Sure, I'll drop perf tools to my test env and share the results,
> maybe tomorrow or in a few days.
> From what I know for sure about MIPS and my platform,
> post-Rx synching (dma_sync_single_for_cpu()) is a no-op, and
> pre-Rx (dma_sync_single_for_device() etc.) is a bit expensive.
> I always have sane page_pool->pp.max_len value (smth about 1668
> for MTU of 1500) to minimize the overhead.
>
> By the word, IIRC, all machines shipped with mvpp2 have hardware
> cache coherency units and don't suffer from sync routines at all.
> That may be the reason why mvpp2 wins the most from this series.
Yep exactly. It's also the reason why you explicitly have to opt-in using the
recycling (by marking the skb for it), instead of hiding the feature in the
page pool internals
Cheers
/Ilias
>
> > > > > >
> > > > > > [0] https://lore.kernel.org/netdev/20210323153550.130385-1-alobakin@pm.me
> > > > > >
> > > >
> >
> > That would be the same as for mvneta:
> >
> > Overhead Shared Object Symbol
> > 24.10% [kernel] [k] __pi___inval_dcache_area
> > 23.02% [mvneta] [k] mvneta_rx_swbm
> > 7.19% [kernel] [k] kmem_cache_alloc
> >
> > Anyway, I tried to use the recycling *and* napi_build_skb on mvpp2,
> > and I get lower packet rate than recycling alone.
> > I don't know why, we should investigate it.
>
> mvpp2 driver doesn't use napi_consume_skb() on its Tx completion path.
> As a result, NAPI percpu caches get refilled only through
> kmem_cache_alloc_bulk(), and most of skbuff_head recycling
> doesn't work.
>
> > Regards,
> > --
> > per aspera ad upstream
>
> Oh, I love that one!
>
> Al
>
next prev parent reply other threads:[~2021-03-23 17:02 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-22 17:02 [PATCH net-next 0/6] page_pool: recycle buffers Matteo Croce
2021-03-22 17:02 ` [PATCH net-next 1/6] xdp: reduce size of struct xdp_mem_info Matteo Croce
2021-03-22 17:02 ` [PATCH net-next 2/6] mm: add a signature in struct page Matteo Croce
2021-03-22 17:02 ` [PATCH net-next 3/6] page_pool: DMA handling and allow to recycles frames via SKB Matteo Croce
2021-03-22 19:38 ` Matteo Croce
2021-03-22 17:02 ` [PATCH net-next 4/6] net: change users of __skb_frag_unref() and add an extra argument Matteo Croce
2021-03-22 17:03 ` [PATCH net-next 5/6] mvpp2: recycle buffers Matteo Croce
2021-03-22 17:03 ` [PATCH net-next 6/6] mvneta: " Matteo Croce
2021-03-23 15:06 ` Jesper Dangaard Brouer
2021-03-24 9:28 ` Lorenzo Bianconi
2021-03-24 21:48 ` Ilias Apalodimas
2021-03-23 14:57 ` [PATCH net-next 0/6] page_pool: " David Ahern
2021-03-23 15:03 ` Ilias Apalodimas
2021-03-23 15:41 ` Alexander Lobakin
2021-03-23 15:47 ` Ilias Apalodimas
2021-03-23 16:04 ` Jesper Dangaard Brouer
2021-03-23 16:10 ` Ilias Apalodimas
2021-03-23 16:28 ` Matteo Croce
2021-03-23 16:55 ` Alexander Lobakin
2021-03-23 17:01 ` Ilias Apalodimas [this message]
2021-03-23 20:03 ` Alexander Lobakin
2021-03-24 7:50 ` Ilias Apalodimas
2021-03-24 11:42 ` 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=YFofANKiR3tD9zgm@enceladus \
--to=ilias.apalodimas@linaro.org \
--cc=alobakin@pm.me \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=hawk@kernel.org \
--cc=jbrouer@redhat.com \
--cc=jonathan.lemon@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo@kernel.org \
--cc=mcroce@linux.microsoft.com \
--cc=netdev@vger.kernel.org \
--cc=saeed@kernel.org \
--cc=saeedm@nvidia.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.