From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 567D358F1 for ; Mon, 10 Nov 2014 09:00:51 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 10 Nov 2014 00:10:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,351,1413270000"; d="scan'208";a="629402303" Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78]) by fmsmga002.fm.intel.com with ESMTP; 10 Nov 2014 00:10:16 -0800 Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 10 Nov 2014 16:08:01 +0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 10 Nov 2014 16:08:01 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.130]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.3]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 16:08:00 +0800 From: "Xie, Huawei" To: Tetsuya Mukawa , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC PATCH 3/7] lib/librte_vhost: Add an abstraction layer tointerpret messages Thread-Index: AQHP/L1xuPNCg761skmApR8mLvhnkg== Date: Mon, 10 Nov 2014 08:07:59 +0000 Message-ID: References: <1415272471-3299-1-git-send-email-mukawa@igel.co.jp> <1415272471-3299-4-git-send-email-mukawa@igel.co.jp> <54604943.5030601@igel.co.jp> In-Reply-To: <54604943.5030601@igel.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nakajima.yoshihiro@lab.ntt.co.jp" , "masutani.hitoshi@lab.ntt.co.jp" Subject: Re: [dpdk-dev] [RFC PATCH 3/7] lib/librte_vhost: Add an abstraction layer tointerpret messages X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 08:00:52 -0000 > -----Original Message----- > From: Tetsuya Mukawa [mailto:mukawa@igel.co.jp] > Sent: Sunday, November 09, 2014 10:13 PM > To: Xie, Huawei; dev@dpdk.org > Cc: nakajima.yoshihiro@lab.ntt.co.jp; masutani.hitoshi@lab.ntt.co.jp > Subject: Re: [dpdk-dev] [RFC PATCH 3/7] lib/librte_vhost: Add an abstract= ion > layer tointerpret messages >=20 > Hi Xie, >=20 > (2014/11/08 5:43), Xie, Huawei wrote: > >> -struct vhost_net_device_ops const *get_virtio_net_callbacks(void); > >> +struct vhost_net_device_ops const *get_virtio_net_callbacks( > >> + vhost_driver_type_t type); > > Tetsuya: > > I feel currently it is better we still keep the common get_virtio_net_c= allbacks(). > > For the message flow from control layer 1 (cuse ioctl or user sock mess= age > recv/xmit)---> cuse/user local message handling layer 2-> common virtio > message handling layer 3 > > Layer 1 and layer 2 belong to one module. It is that module's choice w= hether > to implement callbacks between internal layer1 and layer2. We don't need = to > force that. > > Besides, even that module wants to define the ops between layer 1 and l= ayer2, > the interface could be different between cuse/user. > > Refer to the following code for user: > > > > vhost-user-server.c: > > case VHOST_USER_SET_MEM_TABLE: > > user_set_mem_table(ctx, &msg) > > > > virtio-net-user.c: > > user_set_mem_table(struct vhost_device_ctx ctx, struct VhostUserMsg *pm= sg) > > { > > > > .... > > > > ops->set_mem_table(ctx, regions, memory.nregions); > > } > > > > > I may misunderstand what you say, please let me know in the case. > I guess it's difficult to remove 'vhost_driver_type_t' from > 'get_virtio_net_callbacks()'. > In original vhost example code, there are 2 layers related with > initialization as you mentioned. > + Layer1: cuse ioctl handling layer. > + Layer2: vhost-cuse( =3D vhost-net) message handling layer. >=20 > Layer1 needs function pointers to call Layer2 functions. > 'get_virtio_net_callbacks()' is used for that purpose. >=20 > My RFC is based on above, but Layer1/2 are abstracted to hide vhost-cuse > and vhost-user. > + Layer1: device control abstraction layer. > -- Layer1-a: cuse ioctl handling layer. > -- Layer1-b: unix domain socket handling layer. > + Layer2: message handling abstraction layer. > -- Layer2-a: vhost-cuse(vhost-net) message handling layer. > -- Layer2-b: vhost-user message handling layer. >=20 > Still Layer1 needs function pointers of Layer2. > So, anyway, we still need to implement 'get_virtio_net_callbacks()'. >=20 > Also, as you mentioned, function definition and behavior are different > between Layer2-a and Lanyer2-b like 'user_set_mem_table()'. > Because of this, 'get_virtio_net_callbacks()' need to return collect > function pointers to Layer1. > So I guess 'get_virtio_net_callbacks()' needs 'vhost_driver_type_t' to > know which function pointers are needed by Layer1. Here all layer 2 implementations are required to return same type of vhost_= net_device_ops function pointers to layer 1, so layer 1 need to do some kind of preprocessing of its message or= wrap some private message ctx in like vhost_device_ctx, and then pass the message to layer2. But as we have a more common layer 3, virtio-net layer, how about we put co= mmon message handler in virtio net layer as much as possible, and different layer 2 only do the local message preprocessing, and then pas= s common message format to layer 3? I think we at least need to define functional pointers between layer 2 and = layer 3. Layer 1 and layer 2 actually are sub layers of the same layer. It is that l= ayer(cuse/user) implementation's choice whether to provide an interface be= tween them, and the interface could be different in terms of function prototype. Let us say we are to implement a new vhost, I only care the common interfa= ce provided by layer 3. I don't want to register another callbacks for my d= river which are used by myself only. Let us think more about this. >=20 > If someone wants to implement new vhost-backend, of course they can > implement Layer2 implementation and Layer1 together. > In the case, they doesn't need to call 'get_virtio_net_callbacks()'. > Also they can reuse existing Layer2 implementation by calling > 'get_virtio_net_callbacks()' with existing driver type, or they can > implement a new Layer2 implementation for new vhost-backend. >=20 > BTW, the name of 'vhost_driver_type_t' is redundant, I will change the na= me. >=20 > Tetsuya