[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180412145653.GA7172@lst.de>
Date: Thu, 12 Apr 2018 16:56:53 +0200
From: Christoph Hellwig <hch@....de>
To: Jesper Dangaard Brouer <brouer@...hat.com>
Cc: "xdp-newbies@...r.kernel.org" <xdp-newbies@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Christoph Hellwig <hch@....de>,
David Woodhouse <dwmw2@...radead.org>,
William Tu <u9012063@...il.com>,
Björn Töpel <bjorn.topel@...el.com>,
"Karlsson, Magnus" <magnus.karlsson@...el.com>,
Alexander Duyck <alexander.duyck@...il.com>,
Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: XDP performance regression due to CONFIG_RETPOLINE Spectre V2
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. That should be solveable fairly easily
with the per-device dma ops, though.
Powered by blists - more mailing lists