DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Xie, Huawei" <huawei.xie@intel.com>
To: Tetsuya Mukawa <mukawa@igel.co.jp>, "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 08:07:59 +0000
Message-ID: <C37D651A908B024F974696C65296B57B0F2EFFBC@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <54604943.5030601@igel.co.jp>



> -----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 abstraction
> layer tointerpret messages
> 
> 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.

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 common message handler in virtio net layer as much as possible,
and different layer 2 only do the local message preprocessing, and then pass 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 layer(cuse/user) implementation's choice whether to  provide an interface between
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 interface provided by layer 3. I don't want to register another callbacks for my driver which
are used by myself only.
Let us think more about this.
> 
> 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

  reply	other threads:[~2014-11-10  8:00 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
2014-11-10  8:07       ` Xie, Huawei [this message]
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=C37D651A908B024F974696C65296B57B0F2EFFBC@SHSMSX101.ccr.corp.intel.com \
    --to=huawei.xie@intel.com \
    --cc=dev@dpdk.org \
    --cc=masutani.hitoshi@lab.ntt.co.jp \
    --cc=mukawa@igel.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

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git