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 F0E59A04F3; Thu, 9 Jan 2020 03:27:54 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4A9681DB08; Thu, 9 Jan 2020 03:27:54 +0100 (CET) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id BAA751DB06 for ; Thu, 9 Jan 2020 03:27:51 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2020 18:27:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,412,1571727600"; d="scan'208";a="421643465" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga005.fm.intel.com with ESMTP; 08 Jan 2020 18:27:50 -0800 Received: from fmsmsx605.amr.corp.intel.com (10.18.126.85) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 8 Jan 2020 18:27:50 -0800 Received: from fmsmsx605.amr.corp.intel.com (10.18.126.85) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 8 Jan 2020 18:27:50 -0800 Received: from shsmsx154.ccr.corp.intel.com (10.239.6.54) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Wed, 8 Jan 2020 18:27:50 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.197]) by SHSMSX154.ccr.corp.intel.com ([169.254.7.132]) with mapi id 14.03.0439.000; Thu, 9 Jan 2020 10:27:47 +0800 From: "Xu, Rosen" To: Thomas Monjalon , Matan Azrad , Maxime Coquelin , "Bie, Tiwei" , "Wang, Zhihong" , "Wang, Xiao W" CC: "Yigit, Ferruh" , "dev@dpdk.org" , "Pei, Andy" Thread-Topic: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device drivers Thread-Index: AQHVxiNyDwxDyyJixUGx6fiR8bhkS6fhlTjQ Date: Thu, 9 Jan 2020 02:27:47 +0000 Message-ID: <0E78D399C70DA940A335608C6ED296D73AC7E548@SHSMSX104.ccr.corp.intel.com> References: <1577287161-10321-1-git-send-email-matan@mellanox.com> <0E78D399C70DA940A335608C6ED296D73AC794C5@SHSMSX104.ccr.corp.intel.com> <2962572.5fSG56mABF@xps> In-Reply-To: <2962572.5fSG56mABF@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOThmYjE3ZTAtOWQ1Yi00NzZjLTgwZmItM2IyMTBjNTVmZjRhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiY25GWmRoSWl3S1BnbnJoR09vaVQ3UjZxcFRkdE1GUFFuMDhpRlB3c29UR3N1c1RtVzBtdFM1bEhWWW9wZEQrOSJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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" Hi, > -----Original Message----- > From: Thomas Monjalon > Sent: Wednesday, January 08, 2020 20:59 > To: Matan Azrad ; Maxime Coquelin > ; Bie, Tiwei ; Wang, > Zhihong ; Wang, Xiao W > ; Xu, Rosen > Cc: Yigit, Ferruh ; dev@dpdk.org; Pei, Andy > > Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA devic= e > drivers >=20 > 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 inte= grate > 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 o= k. >=20 > 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. >=20 > 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 b= e implemented as rte_eth_dev and provides eth_dev_ops such as packet TX/RX for OVS. 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=3Ddp= dkvhostuser 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. vDPA is also Virtio back end and works like vHost, same as vHost, it will b= e implemented as rte_eth_dev and also be integrated into OVS. So, it's not ok to move ifc code from drivers/net.