From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Stojaczyk, DariuszX" Subject: Re: [RFC v2] vhost: new rte_vhost API proposal Date: Wed, 30 May 2018 12:24:58 +0000 Message-ID: References: <1525958573-184361-1-git-send-email-dariuszx.stojaczyk@intel.com> <1526648465-62579-1-git-send-email-dariuszx.stojaczyk@intel.com> <20180525100550.GD14757@stefanha-x1.localdomain> <20180530085700.GC14623@stefanha-x1.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , Maxime Coquelin , "Bie, Tiwei" , "Tetsuya Mukawa" , Thomas Monjalon , "yliu@fridaylinux.org" , "Harris, James R" To: Stefan Hajnoczi Return-path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id AEF1B2B96 for ; Wed, 30 May 2018 14:25:04 +0200 (CEST) In-Reply-To: <20180530085700.GC14623@stefanha-x1.localdomain> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Stefan Hajnoczi [mailto:stefanha@redhat.com] > Sent: Wednesday, May 30, 2018 10:57 AM > On Tue, May 29, 2018 at 01:38:33PM +0000, Stojaczyk, DariuszX wrote: > > > > > > > -----Original Message----- > > > From: Stefan Hajnoczi [mailto:stefanha@redhat.com] > > > Sent: Friday, May 25, 2018 12:06 PM > > > On Fri, May 18, 2018 at 03:01:05PM +0200, Dariusz Stojaczyk wrote: > > > > +struct rte_vhost2_msg { > > > > + uint32_t id; > > > > > > Is this what the vhost-user specification calls the "request type"? > > > I suggest following the vhost-user spec terminology. > > > > > > > + uint32_t flags; > > > > + uint32_t size; /**< The following payload size. */ > > > > + void *payload; > > > > + int fds[RTE_VHOST2_MEMORY_MAX_NREGIONS]; > > > > > > Is it necessary to expose file descriptor passing in the API? > > > virtio-vhost-user doesn't have file descriptor passing, so it's best > > > if this can be hidden inside rte_vhost2. > > > > So it's another argument for not exposing raw message handling to the > user. > > If there's some backend-specific vhost-user message in future that > contains an fd, it will need a set of new abstractions to work with virti= o- > vhost-user anyway. > > I guess I'll get back the original custom_msg idea from V1. >=20 > Hold on, have you looked at the device-specific messages defined in the > vhost-user spec? Do any of them even pass resources (file descriptors)? There's at least VHOST_USER_NVME_SET_CQ_CALL (currently in review, not pres= ent in master yet). Vhost-nvme is a one big hack that doesn't use any virtq= ueues, so it has its own message for callfd.