From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: "Charles (Chas) Williams" <ciwillia@brocade.com>
Cc: dev@dpdk.org, mtetsuyah@gmail.com
Subject: Re: [PATCH 2/2] vhost: start vhost servers once
Date: Tue, 3 Jan 2017 16:16:54 +0800 [thread overview]
Message-ID: <20170103081654.GB21228@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <be570b9e-8fe4-7b45-2598-9a44cd0fedf2@brocade.com>
On Fri, Dec 30, 2016 at 04:26:27PM -0500, Charles (Chas) Williams wrote:
>
>
> On 12/29/2016 10:15 PM, Yuanhan Liu wrote:
> >On Thu, Dec 29, 2016 at 10:58:11AM -0500, Charles (Chas) Williams wrote:
> >>On 12/29/2016 03:52 AM, Yuanhan Liu wrote:
> >>>On Wed, Dec 28, 2016 at 04:10:52PM -0500, Charles (Chas) Williams wrote:
> >>>>Start a vhost server once during devinit instead of during device start
> >>>>and stop. Some vhost clients, QEMU, don't re-attaching to sockets when
> >>>>the vhost server is stopped and later started. Preserve existing behavior
> >>>>for vhost clients.
> >>>
> >>>I didn't quite get the idea what you are going to fix.
> >>
> >>The issue I am trying to fix is QEMU interaction when DPDK's vhost is
> >>acting as a server to QEMU vhost clients. If you create a vhost server
> >>device, it doesn't create the actual datagram socket until you call
> >>.dev_start(). If you call .dev_stop() is also deletes those sockets.
> >>For QEMU, this is a problem since QEMU doesn't know how to re-attach to
> >>datagram sockets that have gone away.
> >
> >Thanks! And I'd appreciate it if you could have written the commit log
> >this way firstly.
> >
> >>.dev_start()/.dev_stop() seems to roughly means link up and link down
> >>so I understand why you might want to add/remove the datagram sockets.
> >>However, in practice, this doesn't seem to make much sense for a DPDK
> >>vhost server.
> >
> >Agree.
> >
> >>This doesn't seem like the right way to indicate link
> >>status to vhost clients.
> >>
> >>It seems like it would just be easier to do this for both clients and
> >>servers, but I don't know why it was done this way originally so I
> >>choose to keep the client behavior.
> >
> >I don't think there are any differences between DPDK acting as client or
> >server. To me, the right logic seems to be (for both DPDK as server and
> >client).
> >
> >For register,
> >- register the vhost socket at probe stage (either at rte_pmd_vhost_probe
> > or at eth_dev_vhost_create).
> >- start the vhost session right after the register when we haven't started
> > it before.
> >
> >For unregister,
> >- invoke rte_vhost_driver_unregister() at rte_pmd_vhost_remove().
>
> OK. This will be much easier than what I submitted.
Good.
>
> >For dev_start/stop,
> >- set allow_queuing to 1/0 for start/stop, respectively.
>
> Unfortunately, I don't think this will work. new_device() doesn't happen
> until a client connects. allow_queueing seems to be following the status
> of the "wire" as it where. .dev_start()/.dev_stop() is the link of local
> port connected to the wire (administratively up or down as it where).
>
> .dev_start() can happen before new_device() and attempting to RX for a
> client that doesn't exist doesn't seem like a good idea.
Right.
> Perhaps another
> flag that follows dev_started, but for the queues?
I will comment it on your v3 patches.
--yliu
next prev parent reply other threads:[~2017-01-03 8:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-28 21:10 [PATCH 1/2] vhost: reference count fix for nb_started_ports Charles (Chas) Williams
2016-12-28 21:10 ` [PATCH 2/2] vhost: start vhost servers once Charles (Chas) Williams
2016-12-29 8:52 ` Yuanhan Liu
2016-12-29 15:58 ` Charles (Chas) Williams
2016-12-30 3:15 ` Yuanhan Liu
2016-12-30 21:26 ` Charles (Chas) Williams
2017-01-03 8:16 ` Yuanhan Liu [this message]
2016-12-29 8:51 ` [PATCH 1/2] vhost: reference count fix for nb_started_ports Yuanhan Liu
2016-12-29 15:49 ` Charles (Chas) Williams
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=20170103081654.GB21228@yliu-dev.sh.intel.com \
--to=yuanhan.liu@linux.intel.com \
--cc=ciwillia@brocade.com \
--cc=dev@dpdk.org \
--cc=mtetsuyah@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 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.