From: Tiwei Bie <tiwei.bie@intel.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>
Cc: Ilya Maximets <i.maximets@samsung.com>,
"Liu, Changpeng" <changpeng.liu@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"Stojaczyk, Dariusz" <dariusz.stojaczyk@intel.com>,
"Wang, Zhihong" <zhihong.wang@intel.com>,
Jason Wang <jasowang@redhat.com>
Subject: Re: [dpdk-dev] vhost: add virtio configuration space access socket messages
Date: Wed, 27 Feb 2019 09:41:49 +0800 [thread overview]
Message-ID: <20190227014149.GA18641@dpdk-tbie.sh.intel.com> (raw)
In-Reply-To: <a493fc05-ce52-a60d-b239-f8bc8ca71a5b@redhat.com>
On Tue, Feb 26, 2019 at 01:32:24PM +0100, Maxime Coquelin wrote:
> On 2/26/19 9:42 AM, Ilya Maximets wrote:
> > On 26.02.2019 11:13, Liu, Changpeng wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Ilya Maximets [mailto:i.maximets@samsung.com]
> > > > Sent: Tuesday, February 26, 2019 3:39 PM
> > > > To: Liu, Changpeng <changpeng.liu@intel.com>; dev@dpdk.org
> > > > Cc: Stojaczyk, Dariusz <dariusz.stojaczyk@intel.com>;
> > > > maxime.coquelin@redhat.com; Bie, Tiwei <tiwei.bie@intel.com>; Wang,
> > > > Zhihong <zhihong.wang@intel.com>; Jason Wang <jasowang@redhat.com>
> > > > Subject: Re: vhost: add virtio configuration space access socket messages
> > > >
> > > > On 26.02.2019 10:01, Liu, Changpeng wrote:
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ilya Maximets [mailto:i.maximets@samsung.com]
> > > > > > Sent: Monday, February 25, 2019 9:20 PM
> > > > > > To: Liu, Changpeng <changpeng.liu@intel.com>; dev@dpdk.org
> > > > > > Cc: Stojaczyk, Dariusz <dariusz.stojaczyk@intel.com>;
> > > > > > maxime.coquelin@redhat.com; Bie, Tiwei <tiwei.bie@intel.com>; Wang,
> > > > > > Zhihong <zhihong.wang@intel.com>; Jason Wang <jasowang@redhat.com>
> > > > > > Subject: Re: vhost: add virtio configuration space access socket messages
> > > > > >
> > > > > > On 25.02.2019 10:51, Changpeng Liu wrote:
> > > > > > > This patch adds new vhost user messages GET_CONFIG and SET_CONFIG
> > > > > > > used to get/set virtio device's PCI configuration space.
> > > > > >
> > > > > > Beside the fact that some additional description and reasoning required,
> > > > > > I do not see the usage of this feature. You're defining the flag
> > > > > > VHOST_USER_PROTOCOL_F_CONFIG, but it's never used. So, none of dpdk
> > > > vhost
> > > > > > backends (vdpa, vhost-user) will use this feature.
> > > > > > You, probably, missed adding it to VHOST_USER_PROTOCOL_FEATURES or
> > > > > > VDPA_SUPPORTED_PROTOCOL_FEATURES.
> > > > > >
> > > > > > From the other side, current implementation forces application to properly
> > > > > > implement the get/set_config callbacks. Otherwise, receiving of the messages
> > > > > > will result in RTE_VHOST_MSG_RESULT_ERR and subsequent vhost
> > > > > > disconnection.
> > > > > > This looks strange, because supported protocol features normally enabled by
> > > > > > default. Am I misunderstood something ?
> > > > > QEMU will not send the messages if VHOST_USER_PROTOCOL_F_CONFIG
> > > > wasn't enabled.
> > > >
> > > > So, you're going to enable it only by explicit call to
> > > > 'rte_vhost_driver_set_features' ?
> > > >
> > > > In this case I'm assuming that you're implementing your own vhost backend.
> > > > But why you're not using 'dev->extern_ops' and corresponding 'pre_msg_handle'
> > > > or 'post_msg_handle' to handle your GET/SET_CONFIG messages like it does
> > > > 'vhost_crypto' backend ?
> > > The patch was developed one year ago, while DPDK didn't have external ops.
> >
> > So, maybe it's time to reconsider the implementation.
>
> +1
>
> > > The get_config/set_config was defined for all the virtio devices, so I think it makes
> > > more sense adding here.
> >
> > VHOST_USER_*_CRYPTO_SESSION messages are defined for all the virtio devices
> > too, however they makes sense for vhost_crypto backend only. These messages
> > (GET/SET_CONFIG) makes sense only when callbacks (get/set_config) are
> > implemented, so IMHO it's better to implement their handlers along with the
> > callbacks, i.e. inside the implementation of your vhost backend.
> >
> > Maxime, Tiwei, what do you think ?
>
> I would prefer it to be implemented in SPDK directly as a pre_handler
> callback, as I don't foresee a need for it for other backends, and it
> would avoid breaking the API.
>
> It would imply fixing the beginning of vhost_user_msg_handler() to accept
> requests > VHOST_USER_MAX and add necessary check before doing
> the debug logs.
>
> With above change we would also be able to remove VHOST_CRYPTO requests
> from vhost_user.c, and we could then work on moving vhost-net bits
> out of this file too.
+1
>
> Regards,
> Maxime
>
next prev parent reply other threads:[~2019-02-27 1:41 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-25 7:51 [dpdk-dev] [PATCH] " Changpeng Liu
2019-02-25 7:48 ` Jason Wang
2019-02-25 11:49 ` Stojaczyk, Dariusz
2019-02-25 12:05 ` Stojaczyk, Dariusz
[not found] ` <CGME20190225132001eucas1p25c1e925b895b3ab36da0aca27110e15c@eucas1p2.samsung.com>
2019-02-25 13:19 ` [dpdk-dev] " Ilya Maximets
2019-02-26 7:01 ` Liu, Changpeng
2019-02-26 7:39 ` Ilya Maximets
2019-02-26 8:13 ` Liu, Changpeng
2019-02-26 8:42 ` Ilya Maximets
2019-02-26 12:32 ` Maxime Coquelin
2019-02-26 13:36 ` Ilya Maximets
2019-02-26 13:43 ` Maxime Coquelin
2019-02-26 14:07 ` Ilya Maximets
2019-02-27 9:04 ` Maxime Coquelin
2019-02-27 11:48 ` Ilya Maximets
2019-02-27 1:31 ` Liu, Changpeng
2019-02-27 9:12 ` Maxime Coquelin
2019-02-27 9:50 ` Liu, Changpeng
2019-02-27 10:04 ` Maxime Coquelin
2019-02-28 12:49 ` Liu, Changpeng
2019-02-27 1:41 ` Tiwei Bie [this message]
[not found] ` <CGME20190225135328eucas1p1560252488ef0f0db87f0509d2bb7813c@eucas1p1.samsung.com>
2019-02-25 13:53 ` Ilya Maximets
2019-02-26 7:02 ` Liu, Changpeng
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=20190227014149.GA18641@dpdk-tbie.sh.intel.com \
--to=tiwei.bie@intel.com \
--cc=changpeng.liu@intel.com \
--cc=dariusz.stojaczyk@intel.com \
--cc=dev@dpdk.org \
--cc=i.maximets@samsung.com \
--cc=jasowang@redhat.com \
--cc=maxime.coquelin@redhat.com \
--cc=zhihong.wang@intel.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).