From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id EA1B9A00E6 for ; Wed, 10 Jul 2019 09:19:49 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3134A1D7; Wed, 10 Jul 2019 09:19:48 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id CC935A3 for ; Wed, 10 Jul 2019 09:19:45 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2019 00:19:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,473,1557212400"; d="scan'208";a="170831605" Received: from npg-dpdk-virtio-tbie-2.sh.intel.com (HELO ___) ([10.67.104.66]) by orsmga006.jf.intel.com with ESMTP; 10 Jul 2019 00:19:42 -0700 Date: Wed, 10 Jul 2019 15:18:06 +0800 From: Tiwei Bie To: JinYu Cc: dev@dpdk.org, changpeng.liu@intel.com, maxime.coquelin@redhat.com, zhihong.wang@intel.com, LinLi , XunNi , YuZhang Message-ID: <20190710071806.GA24475@___> References: <20190708183959.50293> <20190710104356.6580-1-jin.yu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190710104356.6580-1-jin.yu@intel.com> User-Agent: Mutt/1.9.4 (2018-02-28) Subject: Re: [dpdk-dev] [PATCH v2 1/2] vhost: support inflight share memory protocol feature X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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. > > Signed-off-by: LinLi > Signed-off-by: XunNi > Signed-off-by: YuZhang > Signed-off-by: JinYu There should be a space between FirstName and LastName. [...] > > +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. > + > +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?