From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by dpdk.org (Postfix) with ESMTP id 642DD7E8E for ; Mon, 10 Nov 2014 09:34:34 +0100 (CET) Received: by mail-pa0-f53.google.com with SMTP id kx10so7708382pab.26 for ; Mon, 10 Nov 2014 00:44:18 -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=H9xkBN7jsNKibAWQWljDnrfVPFJGOVqIP3l/6fuFy1U=; b=ZY+13OcBp/ZYjPmufKbLIa1XA4FFyb4/fse03m/by+oyN3u/gt6yOL7L/r3hhMhvP6 7W2+rtHU8shfP3AorfmmRwvu6jt6oCeBZHojJdwaLGcbt3q5KTx/OXHvRSjJiIm1zfuX MlLzCItUJcd6Vi1yWU1BN5QZnNwuuFiFZL/L4Wib3GVx9kv76JFLmlJ1Su8A09srBp+L gPyEU9OaDpU+xpQARvv9hBl+tbedIUwoJ/YLoD0TxWP1aywzmFGYGZBYGfeX5V9oQEQD SAf/dwQCt7Jdf1SBX5BsMaiM/dQ+2Nx6FHom+VfleeUFQMWtCtfbEUadBKYrOyXQu/kf o5iQ== X-Gm-Message-State: ALoCoQl/RKUxLdhArgeV9yXP/OKQ5KKTScnnKfdEzg7GTRlS6dagKEcdj3wyaKc7rAKxYdAT4Ui1 X-Received: by 10.70.102.164 with SMTP id fp4mr23871020pdb.96.1415609058343; Mon, 10 Nov 2014 00:44:18 -0800 (PST) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by mx.google.com with ESMTPSA id fo3sm15947311pad.11.2014.11.10.00.44.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 00:44:17 -0800 (PST) Message-ID: <54607AE0.1010300@igel.co.jp> Date: Mon, 10 Nov 2014 17:44:16 +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> <54604943.5030601@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 08:34:34 -0000 Hi Xie, (2014/11/10 17:07), Xie, Huawei wrote: > Here all layer 2 implementations are required to return same type of vh= ost_net_device_ops function pointers to > layer 1, so layer 1 need to do some kind of preprocessing of its messag= e 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 pu= t 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 th= at layer(cuse/user) implementation's choice whether to provide an interf= ace between > them, and the interface could be different in terms of function prototy= pe. > Let us say we are to implement a new vhost, I only care the common int= erface provided by layer 3. I don't want to register another callbacks fo= r my driver which > are used by myself only. > Let us think more about this. With my RFC implementation, sometimes Layer1 directly calls Layer2-a or Layer2-b functions. It may be fast a bit, but may not be well abstracted because Layer1 doesn't call virtio common layer sometimes. Anyway, I guess it's nice to change implementation as you mentioned. We don't need speed while initialization. Let's take well abstracted implementation. Thanks, Tetsuya