From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; 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: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdehledguddufecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc fkphepjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpeht hhhomhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: 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 To: "Xu, Rosen" Cc: Matan Azrad , Maxime Coquelin , "Bie, Tiwei" , "Wang, Zhihong" , "Wang, Xiao W" , "Yigit, Ferruh" , "dev@dpdk.org" , "Pei, Andy" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 09/01/2020 03:27, Xu, Rosen: > Hi, > > From: Thomas Monjalon > > 08/01/2020 13:39, Xu, Rosen: > > > From: Matan Azrad > > > > 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.