From: John Fastabend <john.fastabend@gmail.com>
To: jasowang@redhat.com, mst@redhat.com
Cc: john.r.fastabend@intel.com, netdev@vger.kernel.org,
alexei.starovoitov@gmail.com, daniel@iogearbox.net
Subject: Re: [RFC PATCH] virtio_net: XDP support for adjust_head
Date: Mon, 2 Jan 2017 11:47:39 -0800 [thread overview]
Message-ID: <586AAE5B.20708@gmail.com> (raw)
In-Reply-To: <20170102194413.9089.39078.stgit@john-Precision-Tower-5810>
On 17-01-02 11:44 AM, John Fastabend wrote:
> Add support for XDP adjust head by allocating a 256B header region
> that XDP programs can grow into. This is only enabled when a XDP
> program is loaded.
>
> In order to ensure that we do not have to unwind queue headroom push
> queue setup below bpf_prog_add. It reads better to do a prog ref
> unwind vs another queue setup call.
>
> : There is a problem with this patch as is. When xdp prog is loaded
> the old buffers without the 256B headers need to be flushed so that
> the bpf prog has the necessary headroom. This patch does this by
> calling the virtqueue_detach_unused_buf() and followed by the
> virtnet_set_queues() call to reinitialize the buffers. However I
> don't believe this is safe per comment in virtio_ring this API
> is not valid on an active queue and the only thing we have done
> here is napi_disable/napi_enable wrappers which doesn't do anything
> to the emulation layer.
>
> So the RFC is really to find the best solution to this problem.
> A couple things come to mind, (a) always allocate the necessary
> headroom but this is a bit of a waste (b) add some bit somewhere
> to check if the buffer has headroom but this would mean XDP programs
> would be broke for a cycle through the ring, (c) figure out how
> to deactivate a queue, free the buffers and finally reallocate.
> I think (c) is the best choice for now but I'm not seeing the
> API to do this so virtio/qemu experts anyone know off-hand
> how to make this work? I started looking into the PCI callbacks
> reset() and virtio_device_ready() or possibly hitting the right
> set of bits with vp_set_status() but my first attempt just hung
> the device.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
[...]
> +
> + /* Changing the headroom in buffers is a disruptive operation because
> + * existing buffers must be flushed and reallocated. This will happen
> + * when a xdp program is initially added or xdp is disabled by removing
> + * the xdp program.
> + */
> + if (old_hr != vi->headroom) {
> + cancel_delayed_work_sync(&vi->refill);
> + if (netif_running(vi->dev)) {
> + for (i = 0; i < vi->max_queue_pairs; i++)
> + napi_disable(&vi->rq[i].napi);
> + }
> + for (i = 0; i < vi->max_queue_pairs; i++) {
> + struct virtqueue *vq = vi->rq[i].vq;
> + void *buf;
> +
> + while ((buf = virtqueue_detach_unused_buf(vq)) != NULL) {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Per API in virtio_ring.c queue must be deactivated to call this.
> + if (vi->mergeable_rx_bufs) {
> + unsigned long ctx = (unsigned long)buf;
> + void *base = mergeable_ctx_to_buf_address(ctx);
> + put_page(virt_to_head_page(base));
> + } else if (vi->big_packets) {
> + give_pages(&vi->rq[i], buf);
> + } else {
> + dev_kfree_skb(buf);
> + }
> + }
> + }
> + if (netif_running(vi->dev)) {
> + for (i = 0; i < vi->max_queue_pairs; i++)
> + virtnet_napi_enable(&vi->rq[i]);
> + }
> + }
> +
Hi Jason, Michael,
Any hints on how to solve the above kludge to flush the existing ring and
reallocate with correct headroom? The above doesn't look safe to me per commit
message.
Thanks!
John
next prev parent reply other threads:[~2017-01-02 19:47 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-02 19:44 [RFC PATCH] virtio_net: XDP support for adjust_head John Fastabend
2017-01-02 19:47 ` John Fastabend [this message]
2017-01-03 6:01 ` Jason Wang
2017-01-03 16:54 ` John Fastabend
2017-01-03 16:57 ` John Fastabend
2017-01-04 3:22 ` Jason Wang
2017-01-04 3:21 ` Jason Wang
2017-01-03 22:16 ` Michael S. Tsirkin
2017-01-05 22:57 ` John Fastabend
2017-01-06 0:39 ` Michael S. Tsirkin
2017-01-06 3:28 ` John Fastabend
2017-01-04 18:58 ` John Fastabend
2017-01-05 3:10 ` Jason Wang
-- strict thread matches above, loose matches on Subject: below --
2016-12-23 18:43 John Fastabend
2016-12-23 21:46 ` John Fastabend
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=586AAE5B.20708@gmail.com \
--to=john.fastabend@gmail.com \
--cc=alexei.starovoitov@gmail.com \
--cc=daniel@iogearbox.net \
--cc=jasowang@redhat.com \
--cc=john.r.fastabend@intel.com \
--cc=mst@redhat.com \
--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).