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 8C7FBA04F9; Fri, 10 Jan 2020 03:38:22 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 423D61E548; Fri, 10 Jan 2020 03:38:21 +0100 (CET) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 118641E53B for ; Fri, 10 Jan 2020 03:38:18 +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 fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2020 18:38:17 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,414,1571727600"; d="scan'208";a="421975632" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga005.fm.intel.com with ESMTP; 09 Jan 2020 18:38:17 -0800 Received: from fmsmsx609.amr.corp.intel.com (10.18.126.89) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 9 Jan 2020 18:38:17 -0800 Received: from fmsmsx609.amr.corp.intel.com (10.18.126.89) by fmsmsx609.amr.corp.intel.com (10.18.126.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 9 Jan 2020 18:38:17 -0800 Received: from shsmsx108.ccr.corp.intel.com (10.239.4.97) by fmsmsx609.amr.corp.intel.com (10.18.126.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Thu, 9 Jan 2020 18:38:17 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.197]) by SHSMSX108.ccr.corp.intel.com ([169.254.8.39]) with mapi id 14.03.0439.000; Fri, 10 Jan 2020 10:38:15 +0800 From: "Xu, Rosen" To: Matan Azrad , Thomas Monjalon CC: Maxime Coquelin , "Bie, Tiwei" , "Wang, Zhihong" , "Wang, Xiao W" , "Yigit, Ferruh" , "dev@dpdk.org" , "Pei, Andy" , "Roni Bar Yanai" Thread-Topic: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device drivers Thread-Index: AQHVxiNyDwxDyyJixUGx6fiR8bhkS6fhlTjQ///pjICAAJ2eoP//krqAgAGBAEA= Date: Fri, 10 Jan 2020 02:38:15 +0000 Message-ID: <0E78D399C70DA940A335608C6ED296D73AC869EE@SHSMSX104.ccr.corp.intel.com> References: <1577287161-10321-1-git-send-email-matan@mellanox.com> <2962572.5fSG56mABF@xps> <0E78D399C70DA940A335608C6ED296D73AC7E548@SHSMSX104.ccr.corp.intel.com> <1669723.3VsfAaAtOV@xps> <0E78D399C70DA940A335608C6ED296D73AC8000B@SHSMSX104.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDcyMWJjY2MtYWY3My00YjBlLTg5MzQtMjExNmE2ZmU2YjRkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoid3FMNWYwaEc2NlZmbzVsbGhOSWp4RXh6SGdcL202ZnRvWmpoKzZ1U2E4OE03bUFOWkJDZXViOGhcL3JDMTcxNCtFIn0= 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" > -----Original Message----- > From: Matan Azrad > Sent: Thursday, January 09, 2020 19:34 > To: Xu, Rosen ; Thomas Monjalon > > Cc: Maxime Coquelin ; Bie, Tiwei > ; Wang, Zhihong ; Wang, > Xiao W ; Yigit, Ferruh ; > dev@dpdk.org; Pei, Andy ; Roni Bar Yanai > > Subject: RE: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA devic= e > drivers >=20 >=20 >=20 > From: Xu, Rosen > > > -----Original Message----- > > > From: Thomas Monjalon > > > Sent: Thursday, January 09, 2020 16:41 > > > To: Xu, Rosen > > > Cc: Matan Azrad ; Maxime Coquelin > > > ; Bie, Tiwei ; > > > Wang, Zhihong ; Wang, Xiao W > > > ; Yigit, Ferruh ; > > > dev@dpdk.org; Pei, Andy > > > Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA > > > device drivers > > > > > > 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. > > > > Yes, vhost pmd is not a good example. > > > > > > 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=3Ddpdkvhostuser 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 O= VS. > > > > > > No, vDPA is not "implemented as rte_eth_dev". > > > > Currently, vDPA isn't integrated with OVS. > > > > > > So, it's not ok to move ifc code from drivers/net. > > > > > > drivers/net/ifc has no ethdev implementation at all. > > > > For OVS hasn't integrated vDPA, it doesn't implement rte_eth_dev, but > > there are many discussions in OVS community about vDPA, some are from > > Mellanox, it seems vDPA port will be implemented as rte_eth_dev port > > in OVS in the near feature. > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fpat= c > > h > > > work.ozlabs.org%2Fpatch%2F1178474%2F&data=3D02%7C01%7Cmatan% > 4 > > > 0mellanox.com%7C9e84c2581e2f414e0aca08d794f22e8d%7Ca652971c7d2e4 > d > > > 9ba6a4d149256f461b%7C0%7C0%7C637141640216181763&sdata=3DTA% > 2F > > 0zU495kXUqhC6eP09NDzBZfjJz1dbfkRcDpV%2BYAs%3D&reserved=3D0 > > > > Matan, > > Could you clarify how OVS integrates vDPA in Mellanox patch? > > > > > > > > Rosen, I'm sorry, these arguments look irrelevant, so I won't > > > consider them as blocking the integration of this patch. > > > > What I mentioned is not blocking the integration of this patch, I just > > want to get clarification from Matan how to integrate vDPA port in OVS. >=20 >=20 > Hi >=20 > OVS like any other application should use the current API of vDPA to atta= ch a > probed vdpa device to a vhost device. > See example application /examples/vdpa. >=20 > Here, we just introduce a new class to hold all the vDPA drivers, no chan= ge in > the API. >=20 > As I understand, no vDPA device is currently integrated in OVS. >=20 > I think it can be integrated only when a full offload will be integrated = since > the vDPA device forward the traffic from the HW directly to the virtio qu= eue, > once it will be there, I guess the offload will be configured by the repr= esentor > of the vdpa device(VF) which is managed by an ethdev device. > >=20 > Matan. >=20 Hi, I'm still confused about your last sentence " the representor of the vdpa d= evice(VF) which is managed by an ethdev device". My understanding is that there are some connections and dependency between = rte_eth_dev and vdpa device? Am I right or any other explanations from you? Rosen.