From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by dpdk.org (Postfix) with ESMTP id 267227E8E for ; Mon, 10 Nov 2014 06:02:54 +0100 (CET) Received: by mail-pa0-f45.google.com with SMTP id lf10so7471118pab.4 for ; Sun, 09 Nov 2014 21:12:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=N/SfIP2xAb8AU9X4zOCACHKGhtQZF/wMM1uxMdX/o60=; b=KPFao0/oOVS26eLhuuO4tKviANg9PtEt2OIy2La6xQNxMNwqKNPdhc90SWer1nUrks DevXFz/At+1xh4AqL+2/ptp8XdU3x7kE3piL5CqTjhQFsTfqqUTBnXlWO9M0Y3NwgfdB n0AJY+51Nf6eOT5Rz0MrOn0U/zQyWoeSoC49osZA2mynou1Ao5J3ZpsA5jUtMNrLIqfH 2LDL/VVWH697eo3eh4EGmomUXOSSdW2Q/rRh9c06o9ALIDzGPfvzDqgSXgzUTRMdQ2XI v3HTFrLsrsZhJQaaxzhJpkfpQBM/26mvvUhjtiFTL7Ewro0lOQIT/Pa5tFI4hUWPE9b7 37fQ== X-Gm-Message-State: ALoCoQkQ+qCZm9ttZqKbNvvTb6WZAqt/+vdvPTwYjGbKZJe2/DSsangqIOOiAlc68ZtdNyD7xDKN X-Received: by 10.68.88.164 with SMTP id bh4mr1321088pbb.141.1415596357187; Sun, 09 Nov 2014 21:12:37 -0800 (PST) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by mx.google.com with ESMTPSA id r4sm15175728pdm.93.2014.11.09.21.12.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Nov 2014 21:12:36 -0800 (PST) Message-ID: <54604943.5030601@igel.co.jp> Date: Mon, 10 Nov 2014 14:12:35 +0900 From: Tetsuya Mukawa User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Xie, Huawei" , "dev@dpdk.org" References: <1415272471-3299-1-git-send-email-mukawa@igel.co.jp> <1415272471-3299-4-git-send-email-mukawa@igel.co.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 05:02:54 -0000 Hi Xie, (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().=20 > 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 virt= io 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.=20 > 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. Layer1 needs function pointers to call Layer2 functions. 'get_virtio_net_callbacks()' is used for that purpose. 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. Still Layer1 needs function pointers of Layer2. So, anyway, we still need to implement 'get_virtio_net_callbacks()'. 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. 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. BTW, the name of 'vhost_driver_type_t' is redundant, I will change the na= me. Tetsuya