All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: netdev@vger.kernel.org, jaswinder.singh@linaro.org,
	ard.biesheuvel@linaro.org, masami.hiramatsu@linaro.org,
	arnd@arndb.de, bjorn.topel@intel.com, magnus.karlsson@intel.com,
	daniel@iogearbox.net, ast@kernel.org,
	jesus.sanchez-palencia@intel.com, vinicius.gomes@intel.com,
	makita.toshiaki@lab.ntt.co.jp, Tariq Toukan <tariqt@mellanox.com>,
	Tariq Toukan <ttoukan.linux@gmail.com>
Subject: Re: [net-next, PATCH 1/2, v3] net: socionext: different approach on DMA
Date: Mon, 1 Oct 2018 14:20:21 +0300	[thread overview]
Message-ID: <20181001112021.GA27469@apalos> (raw)
In-Reply-To: <20181001130313.318065fd@redhat.com>

On Mon, Oct 01, 2018 at 01:03:13PM +0200, Jesper Dangaard Brouer wrote:
> On Mon, 1 Oct 2018 12:56:58 +0300
> Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote:
> 
> > > > #2: You have allocations on the XDP fast-path.
> > > > 
> > > > The REAL secret behind the XDP performance is to avoid allocations on
> > > > the fast-path.  While I just told you to use the page-allocator and
> > > > order-0 pages, this will actually kill performance.  Thus, to make this
> > > > fast, you need a driver local recycle scheme that avoids going through
> > > > the page allocator, which makes XDP_DROP and XDP_TX extremely fast.
> > > > For the XDP_REDIRECT action (which you seems to be interested in, as
> > > > this is needed for AF_XDP), there is a xdp_return_frame() API that can
> > > > make this fast.  
> > >
> > > I had an initial implementation that did exactly that (that's why you the
> > > dma_sync_single_for_cpu() -> dma_unmap_single_attrs() is there). In the case 
> > > of AF_XDP isn't that introducing a 'bottleneck' though? I mean you'll feed fresh
> > > buffers back to the hardware only when your packets have been processed from
> > > your userspace application 
> >
> > Just a clarification here. This is the case if ZC is implemented. In my case
> > the buffers will be 'ok' to be passed back to the hardware once the use
> > userspace payload has been copied by xdp_do_redirect()
> 
> Thanks for clarifying.  But no, this is not introducing a 'bottleneck'
> for AF_XDP.
> 
> For (1) the copy-mode-AF_XDP the frame (as you noticed) is "freed" or
> "returned" very quickly after it is copied.  The code is a bit hard to
> follow, but in __xsk_rcv() it calls xdp_return_buff() after the memcpy.
> Thus, the frame can be kept DMA mapped and reused in RX-ring quickly.
Ok makes sense. I'll send a v4 with page re-usage, while using your API for page
allocation

> 
> For (2) the zero-copy-AF_XDP, then you need to implement a new
> allocator of type MEM_TYPE_ZERO_COPY.  The performance trick here is
> that all DMA-map/unmap and allocations go away, given everything is
> preallocated by userspace.  Through the 4 rings (SPSC) are used for
> recycling the ZC-umem frames (read Documentation/networking/af_xdp.rst).
Noted in case we implement ZC support

Thanks
/Ilias

  reply	other threads:[~2018-10-01 17:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-29 11:28 [net-next, PATCH 0/2, v3] net: socionext: XDP support Ilias Apalodimas
2018-09-29 11:28 ` [net-next, PATCH 1/2, v3] net: socionext: different approach on DMA Ilias Apalodimas
2018-10-01  9:26   ` Jesper Dangaard Brouer
2018-10-01  9:44     ` Ilias Apalodimas
2018-10-01  9:56       ` Ilias Apalodimas
2018-10-01 11:03         ` Jesper Dangaard Brouer
2018-10-01 11:20           ` Ilias Apalodimas [this message]
2018-10-01 13:48             ` Jesper Dangaard Brouer
2018-10-01 14:37               ` Ilias Apalodimas
2018-10-01 15:58                 ` Jesper Dangaard Brouer
2018-09-29 11:28 ` [net-next, PATCH 2/2, v3] net: socionext: add XDP support Ilias Apalodimas
2018-10-01 12:48 ` [net-next, PATCH 0/2, v3] net: socionext: " Björn Töpel
2018-10-01 13:59   ` Ilias Apalodimas

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=20181001112021.GA27469@apalos \
    --to=ilias.apalodimas@linaro.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=ast@kernel.org \
    --cc=bjorn.topel@intel.com \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=jaswinder.singh@linaro.org \
    --cc=jesus.sanchez-palencia@intel.com \
    --cc=magnus.karlsson@intel.com \
    --cc=makita.toshiaki@lab.ntt.co.jp \
    --cc=masami.hiramatsu@linaro.org \
    --cc=netdev@vger.kernel.org \
    --cc=tariqt@mellanox.com \
    --cc=ttoukan.linux@gmail.com \
    --cc=vinicius.gomes@intel.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.