From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id BAFADDE0 for ; Tue, 29 May 2018 15:38:41 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 May 2018 06:38:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,456,1520924400"; d="scan'208";a="60015542" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga001.jf.intel.com with ESMTP; 29 May 2018 06:38:38 -0700 Received: from fmsmsx152.amr.corp.intel.com (10.18.125.5) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 29 May 2018 06:38:38 -0700 Received: from lcsmsx155.ger.corp.intel.com (10.186.165.233) by FMSMSX152.amr.corp.intel.com (10.18.125.5) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 29 May 2018 06:38:37 -0700 Received: from hasmsx105.ger.corp.intel.com ([169.254.1.132]) by LCSMSX155.ger.corp.intel.com ([169.254.12.62]) with mapi id 14.03.0319.002; Tue, 29 May 2018 16:38:34 +0300 From: "Stojaczyk, DariuszX" To: Stefan Hajnoczi CC: "dev@dpdk.org" , Maxime Coquelin , "Bie, Tiwei" , "Tetsuya Mukawa" , Thomas Monjalon , "yliu@fridaylinux.org" , "Harris, James R" Thread-Topic: [RFC v2] vhost: new rte_vhost API proposal Thread-Index: AQHT7on2huGy3KtQDE+XGzZuey1czqRAEIsAgAaoa6A= Date: Tue, 29 May 2018 13:38:33 +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> In-Reply-To: <20180525100550.GD14757@stefanha-x1.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZmM3MmZiMTAtNjAzZC00ODMwLWFiMzMtYzFhYTJkZDFmZDdkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjIuNS4xOCIsIlRydXN0ZWRMYWJlbEhhc2giOiJueVZzc3BVRjB3SXIrVFgwbCtuZ2NmT2U3UGlYRHhJcEFoNEc1cDJVQ1JyWDJWTllaWG13TWp4cDFjWEs1Z1JKIn0= x-ctpclassification: CTP_NT x-originating-ip: [10.103.103.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC v2] vhost: new rte_vhost API proposal 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: , X-List-Received-Date: Tue, 29 May 2018 13:38:42 -0000 > -----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; >=20 > Is this what the vhost-user specification calls the "request type"? I > suggest following the vhost-user spec terminology. >=20 > > + uint32_t flags; > > + uint32_t size; /**< The following payload size. */ > > + void *payload; > > + int fds[RTE_VHOST2_MEMORY_MAX_NREGIONS]; >=20 > 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 t= his > 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 virtio-vhost-us= er anyway. I guess I'll get back the original custom_msg idea from V1. >=20 > > +}; > > + > > +/** Single memory region. Both physically and virtually contiguous */ > > +struct rte_vhost2_mem_region { > > + uint64_t guest_phys_addr; > > + uint64_t guest_user_addr; > > + uint64_t host_user_addr; > > + uint64_t size; > > + void *mmap_addr; > > + uint64_t mmap_size; > > + int fd; >=20 > virtio-vhost-user doesn't have an fd. Why do API consumers need to > know about the fd? They don't. Ack. I'll strip this struct. >=20 > > +/** > > + * Device/queue related callbacks, all optional. Provided callback > > + * parameters are guaranteed not to be NULL unless explicitly > specified. > > + */ >=20 > This is a good place to mention that all callbacks are asynchronous unles= s > specified otherwise. Without that knowledge statements below like "If > this is completed with a non-zero status" are confusing on a void > function. Ack. >=20 > > +struct rte_vhost2_tgt_ops { > > + /** > > + * New driver connected. If this is completed with a non-zero > status, > > + * rte_vhost2 will terminate the connection. > > + */ > > + void (*device_create)(struct rte_vhost2_dev *vdev); > > + /** > > + * Device is ready to operate. vdev data is now initialized. This > callback > > + * may be called multiple times as e.g. memory mappings can > change > > + * dynamically. All queues are guaranteed to be stopped by now. > > + */ > > + void (*device_init)(struct rte_vhost2_dev *vdev); > > + /** > > + * Features have changed in runtime. This is called at least once > > +during >=20 > s/in/at/ Ack. >=20 > > + /** > > + * Custom vhost-user message handler. This is called for > > + * backend-specific messages (net/crypto/scsi) that weren't > recognized > > + * by the generic message parser. `msg` is available until > > + * \c rte_vhost2_tgt_cb_complete is called. > > + */ > > + void (*custom_msg)(struct rte_vhost2_dev *vdev, struct > > +rte_vhost2_msg *msg); >=20 > What happens if rte_vhost2_tgt_cb_complete() is called with a negative > rc? Does the specific errno value matter? My current implementation only checks for rc !=3D 0 now. I'm still working = this out. >=20 > Where is the API for sending a vhost-user reply message? I didn't push any. Now that you pointed out the fds in public API I think I= 'll rollback this custom_msg stuff to V1. D.