From: Christoph Hellwig <hch@lst.de>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: "Björn Töpel" <bjorn.topel@gmail.com>,
netdev@vger.kernel.org, "Björn Töpel" <bjorn.topel@intel.com>,
hch@lst.de, davem@davemloft.net, konrad.wilk@oracle.com,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
bpf@vger.kernel.org, maximmi@mellanox.com,
magnus.karlsson@intel.com, jonathan.lemon@gmail.com
Subject: Re: [PATCH net] xsk: remove cheap_dma optimization
Date: Sat, 27 Jun 2020 09:04:06 +0200 [thread overview]
Message-ID: <20200627070406.GB11854@lst.de> (raw)
In-Reply-To: <c60dfb5a-2bf3-20bd-74b3-6b5e215f73f8@iogearbox.net>
On Sat, Jun 27, 2020 at 01:00:19AM +0200, Daniel Borkmann wrote:
> Given there is roughly a ~5 weeks window at max where this removal could
> still be applied in the worst case, could we come up with a fix / proposal
> first that moves this into the DMA mapping core? If there is something that
> can be agreed upon by all parties, then we could avoid re-adding the 9%
> slowdown. :/
I'd rather turn it upside down - this abuse of the internals blocks work
that has basically just missed the previous window and I'm not going
to wait weeks to sort out the API misuse. But we can add optimizations
back later if we find a sane way.
That being said I really can't see how this would make so much of a
difference. What architecture and what dma_ops are you using for
those measurements? What is the workload?
next prev parent reply other threads:[~2020-06-27 7:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-26 13:43 [PATCH net] xsk: remove cheap_dma optimization Björn Töpel
2020-06-26 20:44 ` Jonathan Lemon
2020-06-26 23:00 ` Daniel Borkmann
2020-06-27 7:04 ` Christoph Hellwig [this message]
2020-06-28 17:16 ` Björn Töpel
2020-06-29 13:52 ` Daniel Borkmann
2020-06-29 15:10 ` Björn Töpel
2020-06-29 15:18 ` Daniel Borkmann
2020-06-29 16:23 ` Björn Töpel
2020-06-30 5:07 ` Christoph Hellwig
2020-06-30 13:47 ` Daniel Borkmann
2020-06-29 15:41 ` Robin Murphy
2020-07-01 10:17 ` Björn Töpel
2020-07-08 6:50 ` Christoph Hellwig
2020-07-08 7:57 ` Song Bao Hua (Barry Song)
2020-07-08 12:19 ` Christoph Hellwig
2020-07-08 13:18 ` Robin Murphy
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=20200627070406.GB11854@lst.de \
--to=hch@lst.de \
--cc=bjorn.topel@gmail.com \
--cc=bjorn.topel@intel.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=iommu@lists.linux-foundation.org \
--cc=jonathan.lemon@gmail.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=magnus.karlsson@intel.com \
--cc=maximmi@mellanox.com \
--cc=netdev@vger.kernel.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).