From: Tetsuya Mukawa <mukawa@igel.co.jp>
To: "Xie, Huawei" <huawei.xie@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "nakajima.yoshihiro@lab.ntt.co.jp"
<nakajima.yoshihiro@lab.ntt.co.jp>,
"masutani.hitoshi@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
Date: Mon, 10 Nov 2014 14:12:35 +0900 [thread overview]
Message-ID: <54604943.5030601@igel.co.jp> (raw)
In-Reply-To: <C37D651A908B024F974696C65296B57B0F2E4C8C@SHSMSX101.ccr.corp.intel.com>
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_callbacks().
> For the message flow from control layer 1 (cuse ioctl or user sock message 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 whether 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 layer2, 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 *pmsg)
> {
>
> ....
>
> 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( = 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 name.
Tetsuya
next prev parent reply other threads:[~2014-11-10 5:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-06 11:14 [dpdk-dev] [RFC PATCH 0/7] lib/librte_vhost: Add vhost-user extension Tetsuya Mukawa
2014-11-06 11:14 ` [dpdk-dev] [RFC PATCH 1/7] lib/librte_vhost: Fix host_memory_map() to handle various memory regions Tetsuya Mukawa
2014-11-06 11:14 ` [dpdk-dev] [RFC PATCH 2/7] lib/librte_vhost: Add an abstraction layer for vhost backends Tetsuya Mukawa
2014-11-06 11:14 ` [dpdk-dev] [RFC PATCH 3/7] lib/librte_vhost: Add an abstraction layer tointerpret messages Tetsuya Mukawa
2014-11-07 20:43 ` Xie, Huawei
2014-11-10 5:12 ` Tetsuya Mukawa [this message]
2014-11-10 8:07 ` Xie, Huawei
2014-11-10 8:44 ` Tetsuya Mukawa
2014-11-06 11:14 ` [dpdk-dev] [RFC PATCH 4/7] lib/librte_vhost: Move vhost vhost-cuse device list and accessor functions Tetsuya Mukawa
2014-11-06 11:14 ` [dpdk-dev] [RFC PATCH 5/7] lib/librte_vhost: Add a vhost session abstraction Tetsuya Mukawa
2014-11-06 11:14 ` [dpdk-dev] [RFC PATCH 6/7] lib/librte_vhost: Add vhost-cuse/user specific initialization Tetsuya Mukawa
2014-11-06 11:14 ` [dpdk-dev] [RFC PATCH 7/7] lib/librte_vhost: Add vhost-user implementation Tetsuya Mukawa
2014-11-07 21:25 ` Xie, Huawei
2014-11-10 5:11 ` Tetsuya Mukawa
2014-11-10 8:18 ` Xie, Huawei
2014-11-10 8:55 ` Tetsuya Mukawa
2014-11-14 0:07 ` Xie, Huawei
2014-11-14 4:41 ` Tetsuya Mukawa
2014-11-07 3:33 ` [dpdk-dev] [RFC PATCH 0/7] lib/librte_vhost: Add vhost-user extension Xie, Huawei
2014-11-07 5:09 ` Tetsuya Mukawa
[not found] ` <C37D651A908B024F974696C65296B57B0F2E3C93@SHSMSX101.ccr.corp.intel.com>
2014-11-07 6:16 ` Tetsuya Mukawa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54604943.5030601@igel.co.jp \
--to=mukawa@igel.co.jp \
--cc=dev@dpdk.org \
--cc=huawei.xie@intel.com \
--cc=masutani.hitoshi@lab.ntt.co.jp \
--cc=nakajima.yoshihiro@lab.ntt.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).