qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: Nikhil Agarwal <nagarwal@xilinx.com>,
	Stefan Hajnoczi <stefanha@gmail.com>
Cc: "libvir-list@redhat.com" <libvir-list@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Virtio-net control queue handling
Date: Thu, 28 Feb 2019 10:47:03 +0800	[thread overview]
Message-ID: <da9ffd31-370d-6f6f-5fd9-bba08de1f66e@redhat.com> (raw)
In-Reply-To: <MN2PR02MB580695B27405FA206A38110FB6740@MN2PR02MB5806.namprd02.prod.outlook.com>


On 2019/2/28 上午1:39, Nikhil Agarwal wrote:
> Hi Stefan,
>
> Thanks for directing question to correct people, yes your understanding is correct.
>
> I want virtio-net control virtqueue to be handled by vhost-user-net device based backend for vdpa use case where control message would do some configuration on actual hw device. Or these changes should to be done in libvirt where QMP event are being handled as of now?
>
> Regards
> Nikhil


Cc Michael. Several methods for dealing with control virtqueue:

1) using backend specific method. For example, multiqueue control for 
TAP was done in this way, and we plan to support RSS in this way as well 
(through steering eBPF program). But this may not work for the 
privilleged operations.
2) inventing new vhost(user) protocol, convert the vq command to 
vhost(user) command and pass it to vhost(user) backend.
3) extend vhost protocol to deal with control vq like you propose here.
4) notify libvirt using QMP event, we've already supported this if rx 
filter is changed for virtio-net, and let management to deal with the 
changes.
5) implementing or linking vhost backend qemu, then there's no need to 
invent no IPCs

For the case of vDPA, I'm not sure the use case for vDPA through 
vhost-user. Can you describe more about that? To me the best way is 
probably done through mdev and VFIO not userspace path.

Thanks


>
>
> -----Original Message-----
> From: Stefan Hajnoczi <stefanha@gmail.com>
> Sent: Wednesday, February 27, 2019 8:54 PM
> To: Nikhil Agarwal <nagarwal@xilinx.com>
> Cc: qemu-devel@nongnu.org; jasowang@redhat.com; libvir-list@redhat.com
> Subject: Re: [Qemu-devel] Virtio-net control queue handling
>
> On Tue, Feb 26, 2019 at 02:13:43PM +0000, Nikhil Agarwal wrote:
>> Is there any option in QEMU to offload virtio device control queue handling to backend instead of deciphering and passing to libvirt via QMP? if not, is there any interface in libvirt which passes on these message to application or i directly use QMP interface from QEMU?
> I'm not sure I understand your question.  It could be because of
> terminology:
>
> "virtio device control queue" == virtio-net control virtqueue?
>
> "backend" == vhost-user-net device backend?
>
> "message" == QMP event?
>
> I have CCed Jason Wang, QEMU network subsystem maintainer, and the libvirt mailing list.
>
> Stefan
>

      reply	other threads:[~2019-02-28  2:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-26 14:13 [Qemu-devel] Virtio-net control queue handling Nikhil Agarwal
2019-02-27 15:23 ` Stefan Hajnoczi
2019-02-27 17:39   ` Nikhil Agarwal
2019-02-28  2:47     ` Jason Wang [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=da9ffd31-370d-6f6f-5fd9-bba08de1f66e@redhat.com \
    --to=jasowang@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=nagarwal@xilinx.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.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).