From: Tetsuya Mukawa <mukawa-AlSX/UN32fvPDbFq/vQRIQ@public.gmane.org>
To: "Xie,
Huawei" <huawei.xie-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"dev-VfR2kkLFssw@public.gmane.org"
<dev-VfR2kkLFssw@public.gmane.org>
Cc: "nakajima.yoshihiro-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org"
<nakajima.yoshihiro-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>,
"masutani.hitoshi-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org"
<masutani.hitoshi-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
Subject: Re: [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-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
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:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-06 11:14 [RFC PATCH 0/7] lib/librte_vhost: Add vhost-user extension Tetsuya Mukawa
[not found] ` <1415272471-3299-1-git-send-email-mukawa-AlSX/UN32fvPDbFq/vQRIQ@public.gmane.org>
2014-11-06 11:14 ` [RFC PATCH 1/7] lib/librte_vhost: Fix host_memory_map() to handle various memory regions Tetsuya Mukawa
2014-11-06 11:14 ` [RFC PATCH 2/7] lib/librte_vhost: Add an abstraction layer for vhost backends Tetsuya Mukawa
2014-11-06 11:14 ` [RFC PATCH 3/7] lib/librte_vhost: Add an abstraction layer tointerpret messages Tetsuya Mukawa
[not found] ` <1415272471-3299-4-git-send-email-mukawa-AlSX/UN32fvPDbFq/vQRIQ@public.gmane.org>
2014-11-07 20:43 ` Xie, Huawei
[not found] ` <C37D651A908B024F974696C65296B57B0F2E4C8C-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-11-10 5:12 ` Tetsuya Mukawa [this message]
[not found] ` <54604943.5030601-AlSX/UN32fvPDbFq/vQRIQ@public.gmane.org>
2014-11-10 8:07 ` Xie, Huawei
[not found] ` <C37D651A908B024F974696C65296B57B0F2EFFBC-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-11-10 8:44 ` Tetsuya Mukawa
2014-11-06 11:14 ` [RFC PATCH 4/7] lib/librte_vhost: Move vhost vhost-cuse device list and accessor functions Tetsuya Mukawa
2014-11-06 11:14 ` [RFC PATCH 5/7] lib/librte_vhost: Add a vhost session abstraction Tetsuya Mukawa
2014-11-06 11:14 ` [RFC PATCH 6/7] lib/librte_vhost: Add vhost-cuse/user specific initialization Tetsuya Mukawa
2014-11-06 11:14 ` [RFC PATCH 7/7] lib/librte_vhost: Add vhost-user implementation Tetsuya Mukawa
[not found] ` <1415272471-3299-8-git-send-email-mukawa-AlSX/UN32fvPDbFq/vQRIQ@public.gmane.org>
2014-11-07 21:25 ` Xie, Huawei
[not found] ` <C37D651A908B024F974696C65296B57B0F2E4D05-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-11-10 5:11 ` Tetsuya Mukawa
[not found] ` <54604900.7070105-AlSX/UN32fvPDbFq/vQRIQ@public.gmane.org>
2014-11-10 8:18 ` Xie, Huawei
[not found] ` <C37D651A908B024F974696C65296B57B0F2F001E-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-11-10 8:55 ` Tetsuya Mukawa
2014-11-14 0:07 ` Xie, Huawei
[not found] ` <C37D651A908B024F974696C65296B57B0F30261A-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-11-14 4:41 ` Tetsuya Mukawa
2014-11-07 3:33 ` [RFC PATCH 0/7] lib/librte_vhost: Add vhost-user extension Xie, Huawei
[not found] ` <C37D651A908B024F974696C65296B57B0F2E3B9C-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-11-07 5:09 ` Tetsuya Mukawa
[not found] ` <545C5427.5040500-AlSX/UN32fvPDbFq/vQRIQ@public.gmane.org>
2014-11-07 5:24 ` Xie, Huawei
[not found] ` <C37D651A908B024F974696C65296B57B0F2E3C93-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
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-alsx/un32fvpdbfq/vqriq@public.gmane.org \
--cc=dev-VfR2kkLFssw@public.gmane.org \
--cc=huawei.xie-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=masutani.hitoshi-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org \
--cc=nakajima.yoshihiro-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.