From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
To: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: netdev@vger.kernel.org, jaswinder.singh@linaro.org,
ard.biesheuvel@linaro.org, bjorn.topel@intel.com,
magnus.karlsson@intel.com, brouer@redhat.com,
daniel@iogearbox.net, ast@kernel.org,
makita.toshiaki@lab.ntt.co.jp, jakub.kicinski@netronome.com,
john.fastabend@gmail.com, davem@davemloft.net,
maciejromanfijalkowski@gmail.com
Subject: Re: [net-next, PATCH 3/3, v2] net: netsec: add XDP support
Date: Sun, 30 Jun 2019 19:41:28 +0300 [thread overview]
Message-ID: <20190630164127.GC12704@khorivan> (raw)
In-Reply-To: <20190630163214.GA10484@apalos>
On Sun, Jun 30, 2019 at 07:32:14PM +0300, Ilias Apalodimas wrote:
>On Sun, Jun 30, 2019 at 07:25:53PM +0300, Ivan Khoronzhuk wrote:
>> On Sat, Jun 29, 2019 at 08:23:25AM +0300, Ilias Apalodimas wrote:
>> >The interface only supports 1 Tx queue so locking is introduced on
>> >the Tx queue if XDP is enabled to make sure .ndo_start_xmit and
>> >.ndo_xdp_xmit won't corrupt Tx ring
>> >
>> >- Performance (SMMU off)
>> >
>> >Benchmark XDP_SKB XDP_DRV
>> >xdp1 291kpps 344kpps
>> >rxdrop 282kpps 342kpps
>> >
>> >- Performance (SMMU on)
>> >Benchmark XDP_SKB XDP_DRV
>> >xdp1 167kpps 324kpps
>> >rxdrop 164kpps 323kpps
>> >
>> >Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
>> >---
>> >drivers/net/ethernet/socionext/netsec.c | 361 ++++++++++++++++++++++--
>> >1 file changed, 334 insertions(+), 27 deletions(-)
>> >
>>
>> [...]
>>
>> >+
>> >+static int netsec_xdp_setup(struct netsec_priv *priv, struct bpf_prog *prog,
>> >+ struct netlink_ext_ack *extack)
>> >+{
>> >+ struct net_device *dev = priv->ndev;
>> >+ struct bpf_prog *old_prog;
>> >+
>> >+ /* For now just support only the usual MTU sized frames */
>> >+ if (prog && dev->mtu > 1500) {
>> >+ NL_SET_ERR_MSG_MOD(extack, "Jumbo frames not supported on XDP");
>> >+ return -EOPNOTSUPP;
>> >+ }
>> >+
>> >+ if (netif_running(dev))
>> >+ netsec_netdev_stop(dev);
>> And why to stop the interface. XDP allows to update prog in runtime.
>>
>Adding the support is not limited to adding a prog only in this driver.
>It also rebuilts the queues which changes the dma mapping of buffers.
>Since i don't want to map BIDIRECTIONAL buffers if XDP is not in place,
>i am resetting the device and forcing the buffer re-allocation
>
>Thanks
>/Ilias
I don't know the internals, probably it has some dependencies, but here you
just update the prog and can at least do it when exchange is happening.
I mean not in case of prog is attached/removed first time.
In case of prog -> prog it seems doable...
It ups to you ofc, but I can run smth like:
ip -force link set dev eth0 xdp obj xdp-example-pass.o sec .text
and expect it's updated w/o interface reset I mean on new prog.
I'm not sure, but maintainers can help, conceptually it's supposed to be in
runtime the prog be update uder rcu as a part of API usage...
--
Regards,
Ivan Khoronzhuk
next prev parent reply other threads:[~2019-06-30 16:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-29 5:23 [PATCH 0/3, net-next, v2] net: netsec: Add XDP Support Ilias Apalodimas
2019-06-29 5:23 ` [net-next, PATCH 1/3, v2] net: netsec: Use page_pool API Ilias Apalodimas
2019-06-29 5:23 ` [net-next, PATCH 2/3, v2] net: page_pool: add helper function for retrieving dma direction Ilias Apalodimas
2019-06-29 5:23 ` [net-next, PATCH 3/3, v2] net: netsec: add XDP support Ilias Apalodimas
2019-06-29 10:36 ` Jesper Dangaard Brouer
2019-06-30 16:20 ` Ivan Khoronzhuk
2019-06-30 16:34 ` Ilias Apalodimas
2019-06-30 16:45 ` Ivan Khoronzhuk
2019-06-30 16:50 ` Ilias Apalodimas
2019-06-30 16:25 ` Ivan Khoronzhuk
2019-06-30 16:32 ` Ilias Apalodimas
2019-06-30 16:41 ` Ivan Khoronzhuk [this message]
2019-06-30 16:47 ` Ilias Apalodimas
2019-06-30 16:51 ` Ivan Khoronzhuk
2019-06-30 17:09 ` Ivan Khoronzhuk
2019-07-02 2:27 ` [PATCH 0/3, net-next, v2] net: netsec: Add XDP Support David Miller
2019-07-02 3:18 ` 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=20190630164127.GC12704@khorivan \
--to=ivan.khoronzhuk@linaro.org \
--cc=ard.biesheuvel@linaro.org \
--cc=ast@kernel.org \
--cc=bjorn.topel@intel.com \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=ilias.apalodimas@linaro.org \
--cc=jakub.kicinski@netronome.com \
--cc=jaswinder.singh@linaro.org \
--cc=john.fastabend@gmail.com \
--cc=maciejromanfijalkowski@gmail.com \
--cc=magnus.karlsson@intel.com \
--cc=makita.toshiaki@lab.ntt.co.jp \
--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).