From: Jesper Dangaard Brouer <brouer@redhat•com>
To: Christoph Hellwig <hch@lst•de>
Cc: "xdp-newbies@vger•kernel.org" <xdp-newbies@vger•kernel.org>,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>,
"David Woodhouse" <dwmw2@infradead•org>,
"William Tu" <u9012063@gmail•com>,
"Björn Töpel" <bjorn.topel@intel•com>,
"Karlsson, Magnus" <magnus.karlsson@intel•com>,
"Alexander Duyck" <alexander.duyck@gmail•com>,
"Arnaldo Carvalho de Melo" <acme@redhat•com>,
brouer@redhat•com
Subject: Re: XDP performance regression due to CONFIG_RETPOLINE Spectre V2
Date: Thu, 12 Apr 2018 17:31:31 +0200 [thread overview]
Message-ID: <20180412173131.49f01252@redhat.com> (raw)
In-Reply-To: <20180412145653.GA7172@lst.de>
On Thu, 12 Apr 2018 16:56:53 +0200 Christoph Hellwig <hch@lst•de> wrote:
> On Thu, Apr 12, 2018 at 04:51:23PM +0200, Christoph Hellwig wrote:
> > On Thu, Apr 12, 2018 at 03:50:29PM +0200, Jesper Dangaard Brouer wrote:
> > > ---------------
> > > Implement support for keeping the DMA mapping through the XDP return
> > > call, to remove RX map/unmap calls. Implement bulking for XDP
> > > ndo_xdp_xmit and XDP return frame API. Bulking allows to perform DMA
> > > bulking via scatter-gatter DMA calls, XDP TX need it for DMA
> > > map+unmap. The driver RX DMA-sync (to CPU) per packet calls are harder
> > > to mitigate (via bulk technique). Ask DMA maintainer for a common
> > > case direct call for swiotlb DMA sync call ;-)
> >
> > Why do you even end up in swiotlb code? Once you bounce buffer your
> > performance is toast anyway..
>
> I guess that is because x86 selects it as the default as soon as
> we have more than 4G memory.
I were also confused why I ended up using SWIOTLB (SoftWare IO-TLB),
that might explain it. And I'm not hitting the bounce-buffer case.
How do I control which DMA engine I use? (So, I can play a little)
> That should be solveable fairly easily with the per-device dma ops,
> though.
I didn't understand this part.
I wanted to ask your opinion, on a hackish idea I have...
Which is howto detect, if I can reuse the RX-DMA map address, for TX-DMA
operation on another device (still/only calling sync_single_for_device).
With XDP_REDIRECT we are redirecting between net_device's. Usually
we keep the RX-DMA mapping as we recycle the page. On the redirect to
TX-device (via ndo_xdp_xmit) we do a new DMA map+unmap for TX. The
question is how to avoid this mapping(?). In some cases, with some DMA
engines (or lack of) I guess the DMA address is actually the same as
the RX-DMA mapping dma_addr_t already known, right? For those cases,
would it be possible to just (re)use that address for TX?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2018-04-12 15:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-12 13:50 XDP performance regression due to CONFIG_RETPOLINE Spectre V2 Jesper Dangaard Brouer
2018-04-12 14:51 ` Christoph Hellwig
2018-04-12 14:56 ` Christoph Hellwig
2018-04-12 15:31 ` Jesper Dangaard Brouer [this message]
2018-04-13 16:49 ` Christoph Hellwig
2018-04-13 17:12 ` Tushar Dave
2018-04-13 17:26 ` Christoph Hellwig
2018-04-14 19:29 ` David Woodhouse
2018-04-16 6:02 ` Jesper Dangaard Brouer
2018-04-16 12:27 ` Christoph Hellwig
2018-04-16 16:04 ` Alexander Duyck
2018-04-17 6:19 ` Christoph Hellwig
2018-04-16 18:05 ` dma-mapping: bypass dma_ops for direct mappings kbuild test robot
2018-04-16 18:26 ` Jesper Dangaard Brouer
2018-04-16 18:31 ` kbuild test robot
2018-04-16 21:07 ` XDP performance regression due to CONFIG_RETPOLINE Spectre V2 Jesper Dangaard Brouer
2018-04-17 6:15 ` Christoph Hellwig
2018-04-17 7:07 ` Jesper Dangaard Brouer
2018-04-17 7:13 ` Christoph Hellwig
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=20180412173131.49f01252@redhat.com \
--to=brouer@redhat$(echo .)com \
--cc=acme@redhat$(echo .)com \
--cc=alexander.duyck@gmail$(echo .)com \
--cc=bjorn.topel@intel$(echo .)com \
--cc=dwmw2@infradead$(echo .)org \
--cc=hch@lst$(echo .)de \
--cc=magnus.karlsson@intel$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=u9012063@gmail$(echo .)com \
--cc=xdp-newbies@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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