From: "Yu, Jin" <jin.yu@intel.com>
To: "Bie, Tiwei" <tiwei.bie@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"Liu, Changpeng" <changpeng.liu@intel.com>,
"maxime.coquelin@redhat.com" <maxime.coquelin@redhat.com>,
"Wang, Zhihong" <zhihong.wang@intel.com>,
LinLi <lilin24@baidu.com>, XunNi <nixun@baidu.com>,
YuZhang <zhangyu31@baidu.com>
Subject: Re: [dpdk-dev] [PATCH v2 1/2] vhost: support inflight share memory protocol feature
Date: Thu, 11 Jul 2019 02:09:26 +0000 [thread overview]
Message-ID: <B9FBC361811A3D4DBB02350807E29F7B0B930701@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <20190710071806.GA24475@___>
Hi Tiwei, thanks.
> -----Original Message-----
> From: Bie, Tiwei
> Sent: Wednesday, July 10, 2019 3:18 PM
> To: Yu, Jin <jin.yu@intel.com>
> Cc: dev@dpdk.org; Liu, Changpeng <changpeng.liu@intel.com>;
> maxime.coquelin@redhat.com; Wang, Zhihong <zhihong.wang@intel.com>;
> LinLi <lilin24@baidu.com>; XunNi <nixun@baidu.com>; YuZhang
> <zhangyu31@baidu.com>
> Subject: Re: [PATCH v2 1/2] vhost: support inflight share memory protocol
> feature
>
> On Wed, Jul 10, 2019 at 06:43:55PM +0800, JinYu wrote:
> > This patch introduces two new messages VHOST_USER_GET_INFLIGHT_FD
> and
> > VHOST_USER_SET_INFLIGHT_FD to support transferring a shared buffer
> > between qemu and backend.
> >
> > Firstly, qemu uses VHOST_USER_GET_INFLIGHT_FD to get the shared buffer
> > from backend. Then qemu should send it back through
> > VHOST_USER_SET_INFLIGHT_FD each time we start vhost-user.
> >
> > This shared buffer is used to process inflight I/O when backend
> > reconnect.
>
> I saw you send several patch sets for v2. It's a bit confusing. Please bump the
> version when you send a new series. Besides, please keep the cover letter.
Sorry for the confusion. There are some misoperations and I have set them superseded.
>
> >
> > Signed-off-by: LinLi <lilin24@baidu.com>
> > Signed-off-by: XunNi <nixun@baidu.com>
> > Signed-off-by: YuZhang <zhangyu31@baidu.com>
> > Signed-off-by: JinYu <jin.yu@intel.com>
>
> There should be a space between FirstName and LastName.
Got it.
>
> [...]
> >
> > +struct inflight_desc_split {
> > + uint8_t inflight;
> > + uint8_t padding[5];
> > + uint16_t next;
> > + uint64_t counter;
> > +};
> > +
> > +struct inflight_info_split {
> > + uint64_t features;
> > + uint16_t version;
> > + uint16_t desc_num;
> > + uint16_t last_inflight_io;
> > + uint16_t used_idx;
> > + struct inflight_desc_split desc[0];
> > +};
>
> I haven't looked into the details yet. Is it necessary to expose above
> definitions to applications? It seems they are not used in your example code.
Will revise in the next version.
>
> > +
> > +struct resubmit_desc {
> > + uint16_t index;
> > + uint64_t counter;
> > +};
> > +
> > +struct resubmit_info {
> > + struct resubmit_desc *resubmit_list;
> > + uint16_t resubmit_num;
> > +};
>
> The rte_vhost_ prefix is needed for vhost APIs.
>
> > +
> > +struct rte_vhost_ring_inflight_split {
> > + union {
> > + struct inflight_info_split *inflight_split;
> > + /* TODO */
> > + };
>
> Ditto. Seems it's not used in example code.
>
> > +
> > + struct resubmit_info *resubmit_inflight_split; };
> > +
> > struct rte_vhost_vring {
> > struct vring_desc *desc;
> > struct vring_avail *avail;
> > @@ -603,6 +642,22 @@ uint16_t rte_vhost_dequeue_burst(int vid,
> uint16_t queue_id,
> > */
> > int rte_vhost_get_mem_table(int vid, struct rte_vhost_memory **mem);
> >
> > +/**
> > + * Get guest inflight vring info, including inflight ring and resubmit list.
> > + *
> > + * @param vid
> > + * vhost device ID
> > + * @param vring_idx
> > + * vring index
> > + * @param vring
> > + * the structure to hold the requested inflight vring info
> > + * @return
> > + * 0 on success, -1 on failure
> > + */
> > +int __rte_experimental
> > +rte_vhost_get_vhost_ring_inflight_split(int vid, uint16_t vring_idx,
> > + struct rte_vhost_ring_inflight_split *vring);
> > +
> > /**
> > * Get guest vring info, including the vring address, vring size, etc.
> > *
> > @@ -631,6 +686,56 @@ int rte_vhost_get_vhost_vring(int vid, uint16_t
> vring_idx,
> > */
> > int rte_vhost_vring_call(int vid, uint16_t vring_idx);
> >
> > +/**
> > + * set inflight flag for a desc.
> > + *
> > + * @param vid
> > + * vhost device ID
> > + * @param vring_idx
> > + * vring index
> > + * @param idx
> > + * inflight entry index
> > + * @return
> > + * 0 on success, -1 on failure
> > + */
> > +int __rte_experimental
> > +rte_vhost_set_inflight_desc_split(int vid, uint16_t vring_idx,
> > + uint16_t idx);
> [...]
> > +int __rte_experimental
> > +rte_vhost_clr_inflight_desc_split(int vid, uint16_t vring_idx,
> > + uint16_t last_used_idx, uint16_t idx);
> [...]
> > +int __rte_experimental
> > +rte_vhost_set_last_inflight_io_split(int vid, uint16_t vring_idx,
> > + uint16_t idx);
>
> What will be different in the function prototype when we design above three
> APIs for packed ring?
The whole process is quite different as there are no avail ring and userd ring.
next prev parent reply other threads:[~2019-07-11 2:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190708183959.50293>
2019-07-10 10:43 ` JinYu
2019-07-10 7:18 ` Tiwei Bie
2019-07-11 2:09 ` Yu, Jin [this message]
2019-07-11 2:18 ` Tiwei Bie
2019-07-11 2:39 ` Yu, Jin
2019-07-11 4:09 ` Tiwei Bie
2019-07-10 10:43 ` [dpdk-dev] [PATCH v2 2/2] vhost: Add vhost-user-blk example which support inflight JinYu
2019-07-10 7:26 ` Tiwei Bie
2019-07-11 2:23 ` Yu, Jin
2019-07-11 4:08 ` Tiwei Bie
2019-07-11 12:11 ` Yu, Jin
2019-06-26 16:38 [dpdk-dev] [PATCH] [v1]vhost: support inflight share memory protocol feature JinYu
2019-07-08 17:53 ` [dpdk-dev] [PATCH] [v2, 1/2]vhost: " JinYu
2019-07-08 18:00 ` JinYu
2019-07-08 18:16 ` [dpdk-dev] [PATCH v2] [1/2]vhost: " JinYu
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=B9FBC361811A3D4DBB02350807E29F7B0B930701@SHSMSX101.ccr.corp.intel.com \
--to=jin.yu@intel.com \
--cc=changpeng.liu@intel.com \
--cc=dev@dpdk.org \
--cc=lilin24@baidu.com \
--cc=maxime.coquelin@redhat.com \
--cc=nixun@baidu.com \
--cc=tiwei.bie@intel.com \
--cc=zhangyu31@baidu.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).