From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id CBD6BA046B;
	Thu,  9 Jan 2020 09:41:32 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 026231DBDA;
	Thu,  9 Jan 2020 09:41:32 +0100 (CET)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com
 [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id D47291DBD9
 for <dev@dpdk.org>; Thu,  9 Jan 2020 09:41:29 +0100 (CET)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailout.nyi.internal (Postfix) with ESMTP id 0BC0821CDD;
 Thu,  9 Jan 2020 03:41:29 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
 by compute1.internal (MEProxy); Thu, 09 Jan 2020 03:41:29 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
 from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding:content-type; s=mesmtp;
 bh=cL3AIq7azWjNgB9ThbPL3T+t7CbIn7TXmXzKDO9hqRM=; b=moxJ7Z5rBTTL
 /s3VRCxTrDD3huYKheHlE6j5a1JEO+R8t6zMXQ39orTb+fMUatcW66qxG7w0Z40p
 OLmpxezKQxolPPQfl61ME7mcvc7eK/CtOLkwkM5+IIPOqKbPS8rBiBgXpTh/ukm5
 8VUtRmfj/npLClWhwfXSLWfmgYAMjhU=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-transfer-encoding:content-type
 :date:from:in-reply-to:message-id:mime-version:references
 :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
 :x-sasl-enc; s=fm1; bh=cL3AIq7azWjNgB9ThbPL3T+t7CbIn7TXmXzKDO9hq
 RM=; b=gyHOM1XSPjvDJ8x1Iq+AtKwdeLSxntUphubN8qN6lO0qubUxhtQ5Sl+hD
 xAgSaYmBHXdfUD1IxTOo2PtWXjg5UR+eMGPJHWpZ0LaPYrCLeiaTSRCqv4O5ai6k
 eGj6gh202TQZDplpbw71CDWxbY1SSNXUVb2yK+YKCRgnpiYZ1nxFfJiW2eewsrCW
 4EOCSfj2xDSQ4vEo6zkAkTHklW+alCaZBj+c9hgq50IEU8NJn1NpWcNgEaTx4N7X
 mAvAOwTnGDnQh6D1m4lGts+YFnIbsCfjn9wKzktextqb3Cuiq552jwJq1QmzEF5K
 PTi3N4V+70Jp/gkCEw3K86d3G3mpw==
X-ME-Sender: <xms:OOcWXv3G2Cjxr2Fh4ccJM_S7jKV6C80VjRFyaPwxSePmc4Lr_iSc-w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdehledguddufecutefuodetggdotefrod
 ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
 necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
 enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm
 rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc
 fkphepjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpeht
 hhhomhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:OOcWXgHO7MGb-IMiM0Ii9QafeSG0_EfbMPIc2ZF0R4CbMvXWGLUTDg>
 <xmx:OOcWXovzCNv3gE--E97XfIYLoTCDyCJHG8EX4jyHwVYNFDjstyT5rw>
 <xmx:OOcWXssAnB3E6nVZ5suy2f7GUkPaBAWPsH64ZspYDEU1LWZpSOtWeA>
 <xmx:OecWXokrjSd5m8hKUw4vcYDN50i7jZoJYlYZjtRnuOyYKZqXl5dcaQ>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
 by mail.messagingengine.com (Postfix) with ESMTPA id 93A9280062;
 Thu,  9 Jan 2020 03:41:27 -0500 (EST)
From: Thomas Monjalon <thomas@monjalon.net>
To: "Xu, Rosen" <rosen.xu@intel.com>
Cc: Matan Azrad <matan@mellanox.com>,
 Maxime Coquelin <maxime.coquelin@redhat.com>, "Bie,
 Tiwei" <tiwei.bie@intel.com>, "Wang, Zhihong" <zhihong.wang@intel.com>, "Wang,
 Xiao W" <xiao.w.wang@intel.com>, "Yigit, Ferruh" <ferruh.yigit@intel.com>,
 "dev@dpdk.org" <dev@dpdk.org>, "Pei, Andy" <andy.pei@intel.com>
Date: Thu, 09 Jan 2020 09:41:25 +0100
Message-ID: <1669723.3VsfAaAtOV@xps>
In-Reply-To: <0E78D399C70DA940A335608C6ED296D73AC7E548@SHSMSX104.ccr.corp.intel.com>
References: <1577287161-10321-1-git-send-email-matan@mellanox.com>
 <2962572.5fSG56mABF@xps>
 <0E78D399C70DA940A335608C6ED296D73AC7E548@SHSMSX104.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA	device
	drivers
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

09/01/2020 03:27, Xu, Rosen:
> Hi,
> 
> From: Thomas Monjalon <thomas@monjalon.net>
> > 08/01/2020 13:39, Xu, Rosen:
> > > From: Matan Azrad <matan@mellanox.com>
> > > > From: Xu, Rosen
> > > > > Did you think about OVS DPDK?
> > > > > vDPA is a basic module for OVS, currently it will take some
> > > > > exception path packet processing for OVS, so it still needs to integrate
> > eth_dev.
> > > >
> > > > I don't understand your question.
> > > >
> > > > What do you mean by "integrate eth_dev"?
> > >
> > > My questions is in OVS DPDK scenario vDPA device implements eth_dev
> > > ops, so create a new class and move ifc code to this new class is not ok.
> > 
> > 1/ I don't understand the relation with OVS.
> >
> > 2/ no, vDPA device implements vDPA ops.
> > If it implements ethdev ops, it is an ethdev device.
> > 
> > Please show an example of what you claim.
> 
> Answers of 1 and 2.
> 
> In OVS DPDK, each network device(such as NIC, vHost etc) of DPDK needs to be implemented
> as rte_eth_dev and provides eth_dev_ops such as packet TX/RX for OVS.

No, OVS is also using the vhost API for vhost port.

> Take vHost(Virtio back end) for example, OVS startups vHost interface like this:
> ovs-vsctl add-port br0 vhost-user-1 -- set Interface vhost-user-1 type=dpdkvhostuser
> drivers/net/vhost implements vHost as rte_eth_dev and integrated in OVS.
> OVS can send/receive packets to/from VM with rte_eth_tx_burst()  rte_eth_rx_burst()
> which call eth_dev_ops implementation of drivers/net/vhost.

No, it is using rte_vhost_dequeue_burst() and rte_vhost_enqueue_burst()
which are not in ethdev.

> vDPA is also Virtio back end and works like vHost, same as vHost,
> it will be implemented as rte_eth_dev and also be integrated into OVS.

No, vDPA is not "implemented as rte_eth_dev".

> So, it's not ok to move ifc code from drivers/net.

drivers/net/ifc has no ethdev implementation at all.


Rosen, I'm sorry, these arguments look irrelevant,
so I won't consider them as blocking the integration of this patch.