From: Yunsheng Lin <linyunsheng@huawei.com>
To: Mina Almasry <almasrymina@google.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-alpha@vger.kernel.org,
linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org,
sparclinux@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-arch@vger.kernel.org, bpf@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org,
"Donald Hunter" <donald.hunter@gmail.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Paolo Abeni" <pabeni@redhat.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Ivan Kokshaysky" <ink@jurassic.park.msu.ru>,
"Matt Turner" <mattst88@gmail.com>,
"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
"Helge Deller" <deller@gmx.de>,
"Andreas Larsson" <andreas@gaisler.com>,
"Jesper Dangaard Brouer" <hawk@kernel.org>,
"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Masami Hiramatsu" <mhiramat@kernel.org>,
"Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"Steffen Klassert" <steffen.klassert@secunet.com>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"David Ahern" <dsahern@kernel.org>,
"Willem de Bruijn" <willemdebruijn.kernel@gmail.com>,
"Björn Töpel" <bjorn@kernel.org>,
"Magnus Karlsson" <magnus.karlsson@intel.com>,
"Maciej Fijalkowski" <maciej.fijalkowski@intel.com>,
"Jonathan Lemon" <jonathan.lemon@gmail.com>,
"Shuah Khan" <shuah@kernel.org>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"John Fastabend" <john.fastabend@gmail.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Christian König" <christian.koenig@amd.com>,
"Pavel Begunkov" <asml.silence@gmail.com>,
"David Wei" <dw@davidwei.uk>, "Jason Gunthorpe" <jgg@ziepe.ca>,
"Shailend Chand" <shailend@google.com>,
"Harshitha Ramamurthy" <hramamurthy@google.com>,
"Shakeel Butt" <shakeel.butt@linux.dev>,
"Jeroen de Borst" <jeroendb@google.com>,
"Praveen Kaligineedi" <pkaligineedi@google.com>,
"Bagas Sanjaya" <bagasdotme@gmail.com>,
"Christoph Hellwig" <hch@infradead.org>,
"Nikolay Aleksandrov" <razor@blackwall.org>,
"Taehee Yoo" <ap420073@gmail.com>
Subject: Re: [PATCH net-next v25 00/13] Device Memory TCP
Date: Tue, 10 Sep 2024 18:44:51 +0800 [thread overview]
Message-ID: <95e6c282-1e4f-458b-9e40-9b626d64b3bd@huawei.com> (raw)
In-Reply-To: <CAHS8izMX+9F1NngbPx6w7ikKR9TgPvm+jMwZ8168NJYhFC7sVQ@mail.gmail.com>
On 2024/9/10 0:54, Mina Almasry wrote:
> On Mon, Sep 9, 2024 at 4:21 AM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>>
>> On 2024/9/9 13:43, Mina Almasry wrote:
>>
>>>
>>> Perf - page-pool benchmark:
>>> ---------------------------
>>>
>>> bench_page_pool_simple.ko tests with and without these changes:
>>> https://pastebin.com/raw/ncHDwAbn
>>>
>>> AFAIK the number that really matters in the perf tests is the
>>> 'tasklet_page_pool01_fast_path Per elem'. This one measures at about 8
>>> cycles without the changes but there is some 1 cycle noise in some
>>> results.
>>>
>>> With the patches this regresses to 9 cycles with the changes but there
>>> is 1 cycle noise occasionally running this test repeatedly.
>>>
>>> Lastly I tried disable the static_branch_unlikely() in
>>> netmem_is_net_iov() check. To my surprise disabling the
>>> static_branch_unlikely() check reduces the fast path back to 8 cycles,
>>> but the 1 cycle noise remains.
>>
>> Sorry for the late report, as I was adding a testing page_pool ko basing
>> on [1] to avoid introducing performance regression when fixing the bug in
>> [2].
>> I used it to test the performance impact of devmem patchset for page_pool
>> too, it seems there might be some noticable performance impact quite stably
>> for the below testcases, about 5%~16% performance degradation as below in
>> the arm64 system:
>>
>
> Correct me if I'm wrong here, but on the surface here it seems that
> you're re-reporting a known issue. Consensus seems to be that it's a
> non-issue.
>
> In v6 I reported that the bench_page_pool_simple.ko test reports a 1
> cycle regression with these patches, from 8->9 cycles. That is roughly
> consistent with the 5-15% you're reporting.
From the description above in the cover letter, I thought the performance
data using the out of tree testing ko is not stable enough to justify the
performance impact.
>
> I root caused the reason for the regression to be the
> netmem_is_net_iov() check in the fast path. I removed this regression
> in v7 (see the change log) by conditionally compiling the check in
> that function.
>
> In v8, Pavel/Jens/David pushed back on the ifdef check. See this
> entire thread, but in particular this response from Jens:
It seemed the main objection is about how to enable this feature
for the io_uring?
And it seemed that you had added the CONFIG_NET_DEVMEM for this
devmem thing, why not use it for that?
>
> https://lore.kernel.org/lkml/11f52113-7b67-4b45-ba1d-29b070050cec@kernel.dk/
>
> Seems consensus that it's 'not really worth it in this scenario'.
I was only reading through the above thread, it didn't seemed to
reach to consensus as Jesper pointed out the performance impact
for the XDP DROP case in the same thread.
https://lore.kernel.org/lkml/779b9542-4170-483a-af54-ca0dd471f774@kernel.org/
>
next prev parent reply other threads:[~2024-09-10 10:44 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-09 5:43 [PATCH net-next v25 00/13] Device Memory TCP Mina Almasry
2024-09-09 5:43 ` [PATCH net-next v25 01/13] netdev: add netdev_rx_queue_restart() Mina Almasry
2024-09-09 5:43 ` [PATCH net-next v25 02/13] net: netdev netlink api to bind dma-buf to a net device Mina Almasry
2024-09-09 5:43 ` [PATCH net-next v25 03/13] netdev: support binding dma-buf to netdevice Mina Almasry
2024-09-09 5:43 ` [PATCH net-next v25 04/13] netdev: netdevice devmem allocator Mina Almasry
2024-09-09 5:43 ` [PATCH net-next v25 05/13] page_pool: devmem support Mina Almasry
2024-09-09 5:43 ` [PATCH net-next v25 06/13] memory-provider: dmabuf devmem memory provider Mina Almasry
2024-09-10 1:56 ` Jakub Kicinski
2024-09-09 5:43 ` [PATCH net-next v25 07/13] net: support non paged skb frags Mina Almasry
2024-09-09 5:43 ` [PATCH net-next v25 08/13] net: add support for skbs with unreadable frags Mina Almasry
2024-09-10 1:57 ` Jakub Kicinski
2024-09-09 5:43 ` [PATCH net-next v25 09/13] tcp: RX path for devmem TCP Mina Almasry
2024-09-09 5:43 ` [PATCH net-next v25 10/13] net: add SO_DEVMEM_DONTNEED setsockopt to release RX frags Mina Almasry
2024-09-10 2:05 ` Jakub Kicinski
2024-10-10 11:16 ` Lai, Yi
2024-10-10 19:05 ` Mina Almasry
2024-10-11 2:53 ` Lai, Yi
2024-10-11 15:27 ` Jakub Kicinski
2024-10-11 19:38 ` Mina Almasry
2024-09-09 5:43 ` [PATCH net-next v25 11/13] net: add devmem TCP documentation Mina Almasry
2024-09-09 5:43 ` [PATCH net-next v25 12/13] selftests: add ncdevmem, netcat for devmem TCP Mina Almasry
2024-09-09 5:43 ` [PATCH net-next v25 13/13] netdev: add dmabuf introspection Mina Almasry
2024-09-09 11:21 ` [PATCH net-next v25 00/13] Device Memory TCP Yunsheng Lin
2024-09-09 16:54 ` Mina Almasry
2024-09-10 10:44 ` Yunsheng Lin [this message]
2024-09-10 12:31 ` Pavel Begunkov
2024-09-10 15:02 ` Jakub Kicinski
2024-09-10 15:38 ` Mina Almasry
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=95e6c282-1e4f-458b-9e40-9b626d64b3bd@huawei.com \
--to=linyunsheng@huawei.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=almasrymina@google.com \
--cc=andreas@gaisler.com \
--cc=ap420073@gmail.com \
--cc=arnd@arndb.de \
--cc=asml.silence@gmail.com \
--cc=ast@kernel.org \
--cc=bagasdotme@gmail.com \
--cc=bjorn@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=christian.koenig@amd.com \
--cc=corbet@lwn.net \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=donald.hunter@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=dsahern@kernel.org \
--cc=dw@davidwei.uk \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=hch@infradead.org \
--cc=herbert@gondor.apana.org.au \
--cc=hramamurthy@google.com \
--cc=ilias.apalodimas@linaro.org \
--cc=ink@jurassic.park.msu.ru \
--cc=jeroendb@google.com \
--cc=jgg@ziepe.ca \
--cc=john.fastabend@gmail.com \
--cc=jonathan.lemon@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=maciej.fijalkowski@intel.com \
--cc=magnus.karlsson@intel.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mattst88@gmail.com \
--cc=mhiramat@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pkaligineedi@google.com \
--cc=razor@blackwall.org \
--cc=richard.henderson@linaro.org \
--cc=rostedt@goodmis.org \
--cc=shailend@google.com \
--cc=shakeel.butt@linux.dev \
--cc=shuah@kernel.org \
--cc=sparclinux@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
--cc=sumit.semwal@linaro.org \
--cc=tsbogend@alpha.franken.de \
--cc=willemdebruijn.kernel@gmail.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