netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luka Perkov <luka.perkov@sartura.hr>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Domagoj Pintaric <domagoj.pintaric@sartura.hr>,
	netdev@vger.kernel.org,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	"David S . Miller" <davem@davemloft.net>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Marcin Wojtas <mw@semihalf.com>,
	damir.samardzic@sartura.hr
Subject: Re: [PATCH v2] net: mvneta: add basic XDP_DROP support
Date: Mon, 24 Dec 2018 11:16:27 +0100	[thread overview]
Message-ID: <20181224101627.GA8770@archlinux> (raw)
In-Reply-To: <20181222115254.2001201b@redhat.com>

Hi Jesper,

On Sat, Dec 22, 2018 at 11:52:54AM +0100, Jesper Dangaard Brouer wrote:
> On Fri, 21 Dec 2018 14:22:23 +0100
> Domagoj Pintaric <domagoj.pintaric@sartura.hr> wrote:
> 
> > Add initial mvneta XDP support for hardware buffer management enabled
> > devices only.
> 
> Hi Domagoj,
> 
> I would really appreciate if we could coordinate our work on the mvneta
> driver.  Ilias (Cc'ed) and I are also working on adding XDP support for
> this driver, although this is the software-buffer side of the driver we
> have functioning now.
> 
> You can directly follow our progress here: [1][2]
>  [1] https://github.com/xdp-project/xdp-project/blob/master/areas/arm64/board_espressobin04_bench_xdp.org
>  [2] https://github.com/apalos/bpf-next/commits/mvneta_04_page_pool_recycle_xdp
> 
> You XDP-setup function is actually more correct that ours[3], as you
> handle BPF per queue (which we were planning to fix before upstreaming).
> 
> That said, adding XDP_DROP is easy, but I want to see more of the XDP
> features/actions added, as those require a lot more work.  I always
> worry that a driver will stop at just XDP_DROP, so what are your plans
> for adding the harder features? 

Thank you for point out the you already made so much progress as we were
not aware of it. Generally speaking, in Sartura our goal was to leverage
all the development done in eBPF and XDP mainly for datacenter use-cases
and use the technology in embedded systems where our primary focus is.
That said, in OpenWrt summit two months ago Damir gave a talk about
these technologies [1].

You are correct that we have sent a patch only for the easy part. But
that is only what we have implemented so far :) As this was low-priority
project on our side we didn't have concrete timelines for other
features. Looking at what you have done and what we have I'd be happy to
see if we can somehow divide the efforts in most optimal way.

Except the mvneta driver (and we have a lot of boards utilizing that
driver) we would also like to collaborate in mainline XDP support for
mvpp2 which I have seen you have in plans as well.


Thanks,
Luka


[1] https://openwrtsummit.files.wordpress.com/2018/11/20181029-state-of-fast-path-networking-in-linux.pdf
 
> Even-thought XDP_DROP looks easy in this patch, then you are actually
> doing some wrong, as XDP can also modify frames before doing XDP_PASS,
> and (1) you have non-standard-head room (MVNETA_MH_SIZE + NET_SKB_PAD),
> (2) and you don't handle if XDP changed the xdp.data header pointer,
> and (3) you backing memory either comes from page-fragments or kmalloc
> which also goes against the XDP memory requirements.
> 
> [3] https://github.com/apalos/bpf-next/commit/4b567e74552d3cdf55
> -- 
> Best regards,
>   Jesper Dangaard Brouer
>   MSc.CS, Principal Kernel Engineer at Red Hat
>   LinkedIn: http://www.linkedin.com/in/brouer

      parent reply	other threads:[~2018-12-24 10:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-21 13:22 [PATCH v2] net: mvneta: add basic XDP_DROP support Domagoj Pintaric
2018-12-21 17:05 ` David Miller
2018-12-22 10:52 ` Jesper Dangaard Brouer
2018-12-24  6:59   ` Ilias Apalodimas
2018-12-24 10:16   ` Luka Perkov [this message]

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=20181224101627.GA8770@archlinux \
    --to=luka.perkov@sartura.hr \
    --cc=brouer@redhat.com \
    --cc=damir.samardzic@sartura.hr \
    --cc=davem@davemloft.net \
    --cc=domagoj.pintaric@sartura.hr \
    --cc=ilias.apalodimas@linaro.org \
    --cc=mw@semihalf.com \
    --cc=netdev@vger.kernel.org \
    --cc=thomas.petazzoni@bootlin.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;
as well as URLs for NNTP newsgroup(s).