| Message ID | 1577287161-10321-1-git-send-email-matan@mellanox.com (mailing list archive) |
|---|---|
| Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id F02BAA04F0; Wed, 25 Dec 2019 16:19:41 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BED071BE9E; Wed, 25 Dec 2019 16:19:41 +0100 (CET) Received: from mellanox.co.il (mail-il-dmz.mellanox.com [193.47.165.129]) by dpdk.org (Postfix) with ESMTP id 6A6321BE94 for <dev@dpdk.org>; Wed, 25 Dec 2019 16:19:40 +0100 (CET) Received: from Internal Mail-Server by MTLPINE1 (envelope-from asafp@mellanox.com) with ESMTPS (AES256-SHA encrypted); 25 Dec 2019 17:19:39 +0200 Received: from pegasus07.mtr.labs.mlnx (pegasus07.mtr.labs.mlnx [10.210.16.112]) by labmailer.mlnx (8.13.8/8.13.8) with ESMTP id xBPFJdJS020861; Wed, 25 Dec 2019 17:19:39 +0200 From: Matan Azrad <matan@mellanox.com> To: Maxime Coquelin <maxime.coquelin@redhat.com>, Tiwei Bie <tiwei.bie@intel.com>, Zhihong Wang <zhihong.wang@intel.com>, Xiao Wang <xiao.w.wang@intel.com> Cc: Ferruh Yigit <ferruh.yigit@intel.com>, dev@dpdk.org, Thomas Monjalon <thomas@monjalon.net> Date: Wed, 25 Dec 2019 15:19:18 +0000 Message-Id: <1577287161-10321-1-git-send-email-matan@mellanox.com> X-Mailer: git-send-email 1.8.3.1 Subject: [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> |
| Series |
Introduce new class for vDPA device drivers
|
|
Message
Matan Azrad
Dec. 25, 2019, 3:19 p.m. UTC
As discussed and as described in RFC "[RFC] net: new vdpa PMD for Mellanox devices", new vDPA driver is going to be added for Mellanox devices - vDPA mlx5 and more. The only vDPA driver now is the IFC driver that is located in net directory. The IFC driver and the new vDPA mlx5 driver provide the vDPA ops introduced in librte_vhost and not the eth-dev ops. All the others drivers in net class provide the eth-dev ops. The set of features is also different. Create a new class for vDPA drivers and move IFC to this class. Later, all the new drivers that implement the vDPA ops will be added to the vDPA class. Also, a vDPA device driver features list was added to vDPA documentation. Please review the features list and the series. Later on, I'm going to send the vDPA mlx5 driver. Thanks. Matan Azrad (3): drivers: introduce vDPA class doc: add vDPA feature table drivers: move ifc driver to the vDPA class MAINTAINERS | 6 +- doc/guides/conf.py | 5 + doc/guides/index.rst | 1 + doc/guides/nics/features/ifcvf.ini | 8 - doc/guides/nics/ifc.rst | 106 --- doc/guides/nics/index.rst | 1 - doc/guides/vdpadevs/features/default.ini | 55 ++ doc/guides/vdpadevs/features/ifcvf.ini | 8 + doc/guides/vdpadevs/features_overview.rst | 65 ++ doc/guides/vdpadevs/ifc.rst | 106 +++ doc/guides/vdpadevs/index.rst | 15 + drivers/Makefile | 2 + drivers/meson.build | 1 + drivers/net/Makefile | 3 - drivers/net/ifc/Makefile | 34 - drivers/net/ifc/base/ifcvf.c | 329 -------- drivers/net/ifc/base/ifcvf.h | 162 ---- drivers/net/ifc/base/ifcvf_osdep.h | 52 -- drivers/net/ifc/ifcvf_vdpa.c | 1280 ----------------------------- drivers/net/ifc/meson.build | 9 - drivers/net/ifc/rte_pmd_ifc_version.map | 3 - drivers/net/meson.build | 1 - drivers/vdpa/Makefile | 14 + drivers/vdpa/ifc/Makefile | 34 + drivers/vdpa/ifc/base/ifcvf.c | 329 ++++++++ drivers/vdpa/ifc/base/ifcvf.h | 162 ++++ drivers/vdpa/ifc/base/ifcvf_osdep.h | 52 ++ drivers/vdpa/ifc/ifcvf_vdpa.c | 1280 +++++++++++++++++++++++++++++ drivers/vdpa/ifc/meson.build | 9 + drivers/vdpa/ifc/rte_pmd_ifc_version.map | 3 + drivers/vdpa/meson.build | 8 + 31 files changed, 2152 insertions(+), 1991 deletions(-) delete mode 100644 doc/guides/nics/features/ifcvf.ini delete mode 100644 doc/guides/nics/ifc.rst create mode 100644 doc/guides/vdpadevs/features/default.ini create mode 100644 doc/guides/vdpadevs/features/ifcvf.ini create mode 100644 doc/guides/vdpadevs/features_overview.rst create mode 100644 doc/guides/vdpadevs/ifc.rst create mode 100644 doc/guides/vdpadevs/index.rst delete mode 100644 drivers/net/ifc/Makefile delete mode 100644 drivers/net/ifc/base/ifcvf.c delete mode 100644 drivers/net/ifc/base/ifcvf.h delete mode 100644 drivers/net/ifc/base/ifcvf_osdep.h delete mode 100644 drivers/net/ifc/ifcvf_vdpa.c delete mode 100644 drivers/net/ifc/meson.build delete mode 100644 drivers/net/ifc/rte_pmd_ifc_version.map create mode 100644 drivers/vdpa/Makefile create mode 100644 drivers/vdpa/ifc/Makefile create mode 100644 drivers/vdpa/ifc/base/ifcvf.c create mode 100644 drivers/vdpa/ifc/base/ifcvf.h create mode 100644 drivers/vdpa/ifc/base/ifcvf_osdep.h create mode 100644 drivers/vdpa/ifc/ifcvf_vdpa.c create mode 100644 drivers/vdpa/ifc/meson.build create mode 100644 drivers/vdpa/ifc/rte_pmd_ifc_version.map create mode 100644 drivers/vdpa/meson.build
Comments
Hi all Any comments? From: Matan Azrad > As discussed and as described in RFC "[RFC] net: new vdpa PMD for Mellanox > devices", new vDPA driver is going to be added for Mellanox devices - vDPA > mlx5 and more. > > The only vDPA driver now is the IFC driver that is located in net directory. > > The IFC driver and the new vDPA mlx5 driver provide the vDPA ops > introduced in librte_vhost and not the eth-dev ops. > All the others drivers in net class provide the eth-dev ops. > The set of features is also different. > > Create a new class for vDPA drivers and move IFC to this class. > Later, all the new drivers that implement the vDPA ops will be added to the > vDPA class. > > Also, a vDPA device driver features list was added to vDPA documentation. > > Please review the features list and the series. > > Later on, I'm going to send the vDPA mlx5 driver. > > Thanks. > > > Matan Azrad (3): > drivers: introduce vDPA class > doc: add vDPA feature table > drivers: move ifc driver to the vDPA class > > MAINTAINERS | 6 +- > doc/guides/conf.py | 5 + > doc/guides/index.rst | 1 + > doc/guides/nics/features/ifcvf.ini | 8 - > doc/guides/nics/ifc.rst | 106 --- > doc/guides/nics/index.rst | 1 - > doc/guides/vdpadevs/features/default.ini | 55 ++ > doc/guides/vdpadevs/features/ifcvf.ini | 8 + > doc/guides/vdpadevs/features_overview.rst | 65 ++ > doc/guides/vdpadevs/ifc.rst | 106 +++ > doc/guides/vdpadevs/index.rst | 15 + > drivers/Makefile | 2 + > drivers/meson.build | 1 + > drivers/net/Makefile | 3 - > drivers/net/ifc/Makefile | 34 - > drivers/net/ifc/base/ifcvf.c | 329 -------- > drivers/net/ifc/base/ifcvf.h | 162 ---- > drivers/net/ifc/base/ifcvf_osdep.h | 52 -- > drivers/net/ifc/ifcvf_vdpa.c | 1280 ----------------------------- > drivers/net/ifc/meson.build | 9 - > drivers/net/ifc/rte_pmd_ifc_version.map | 3 - > drivers/net/meson.build | 1 - > drivers/vdpa/Makefile | 14 + > drivers/vdpa/ifc/Makefile | 34 + > drivers/vdpa/ifc/base/ifcvf.c | 329 ++++++++ > drivers/vdpa/ifc/base/ifcvf.h | 162 ++++ > drivers/vdpa/ifc/base/ifcvf_osdep.h | 52 ++ > drivers/vdpa/ifc/ifcvf_vdpa.c | 1280 > +++++++++++++++++++++++++++++ > drivers/vdpa/ifc/meson.build | 9 + > drivers/vdpa/ifc/rte_pmd_ifc_version.map | 3 + > drivers/vdpa/meson.build | 8 + > 31 files changed, 2152 insertions(+), 1991 deletions(-) delete mode 100644 > doc/guides/nics/features/ifcvf.ini > delete mode 100644 doc/guides/nics/ifc.rst create mode 100644 > doc/guides/vdpadevs/features/default.ini > create mode 100644 doc/guides/vdpadevs/features/ifcvf.ini > create mode 100644 doc/guides/vdpadevs/features_overview.rst > create mode 100644 doc/guides/vdpadevs/ifc.rst create mode 100644 > doc/guides/vdpadevs/index.rst delete mode 100644 > drivers/net/ifc/Makefile delete mode 100644 drivers/net/ifc/base/ifcvf.c > delete mode 100644 drivers/net/ifc/base/ifcvf.h delete mode 100644 > drivers/net/ifc/base/ifcvf_osdep.h > delete mode 100644 drivers/net/ifc/ifcvf_vdpa.c delete mode 100644 > drivers/net/ifc/meson.build delete mode 100644 > drivers/net/ifc/rte_pmd_ifc_version.map > create mode 100644 drivers/vdpa/Makefile create mode 100644 > drivers/vdpa/ifc/Makefile create mode 100644 drivers/vdpa/ifc/base/ifcvf.c > create mode 100644 drivers/vdpa/ifc/base/ifcvf.h create mode 100644 > drivers/vdpa/ifc/base/ifcvf_osdep.h > create mode 100644 drivers/vdpa/ifc/ifcvf_vdpa.c create mode 100644 > drivers/vdpa/ifc/meson.build create mode 100644 > drivers/vdpa/ifc/rte_pmd_ifc_version.map > create mode 100644 drivers/vdpa/meson.build > > -- > 1.8.3.1
Hi Matan, 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. Thanks, Rosen > -----Original Message----- > From: dev <dev-bounces@dpdk.org> On Behalf Of Matan Azrad > Sent: Tuesday, January 07, 2020 15:57 > To: 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> > Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; dev@dpdk.org; Thomas Monjalon > <thomas@monjalon.net> > Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device > drivers > > Hi all > > Any comments? > > From: Matan Azrad > > As discussed and as described in RFC "[RFC] net: new vdpa PMD for > > Mellanox devices", new vDPA driver is going to be added for Mellanox > > devices - vDPA > > mlx5 and more. > > > > The only vDPA driver now is the IFC driver that is located in net directory. > > > > The IFC driver and the new vDPA mlx5 driver provide the vDPA ops > > introduced in librte_vhost and not the eth-dev ops. > > All the others drivers in net class provide the eth-dev ops. > > The set of features is also different. > > > > Create a new class for vDPA drivers and move IFC to this class. > > Later, all the new drivers that implement the vDPA ops will be added > > to the vDPA class. > > > > Also, a vDPA device driver features list was added to vDPA documentation. > > > > Please review the features list and the series. > > > > Later on, I'm going to send the vDPA mlx5 driver. > > > > Thanks. > > > > > > Matan Azrad (3): > > drivers: introduce vDPA class > > doc: add vDPA feature table > > drivers: move ifc driver to the vDPA class > > > > MAINTAINERS | 6 +- > > doc/guides/conf.py | 5 + > > doc/guides/index.rst | 1 + > > doc/guides/nics/features/ifcvf.ini | 8 - > > doc/guides/nics/ifc.rst | 106 --- > > doc/guides/nics/index.rst | 1 - > > doc/guides/vdpadevs/features/default.ini | 55 ++ > > doc/guides/vdpadevs/features/ifcvf.ini | 8 + > > doc/guides/vdpadevs/features_overview.rst | 65 ++ > > doc/guides/vdpadevs/ifc.rst | 106 +++ > > doc/guides/vdpadevs/index.rst | 15 + > > drivers/Makefile | 2 + > > drivers/meson.build | 1 + > > drivers/net/Makefile | 3 - > > drivers/net/ifc/Makefile | 34 - > > drivers/net/ifc/base/ifcvf.c | 329 -------- > > drivers/net/ifc/base/ifcvf.h | 162 ---- > > drivers/net/ifc/base/ifcvf_osdep.h | 52 -- > > drivers/net/ifc/ifcvf_vdpa.c | 1280 ----------------------------- > > drivers/net/ifc/meson.build | 9 - > > drivers/net/ifc/rte_pmd_ifc_version.map | 3 - > > drivers/net/meson.build | 1 - > > drivers/vdpa/Makefile | 14 + > > drivers/vdpa/ifc/Makefile | 34 + > > drivers/vdpa/ifc/base/ifcvf.c | 329 ++++++++ > > drivers/vdpa/ifc/base/ifcvf.h | 162 ++++ > > drivers/vdpa/ifc/base/ifcvf_osdep.h | 52 ++ > > drivers/vdpa/ifc/ifcvf_vdpa.c | 1280 > > +++++++++++++++++++++++++++++ > > drivers/vdpa/ifc/meson.build | 9 + > > drivers/vdpa/ifc/rte_pmd_ifc_version.map | 3 + > > drivers/vdpa/meson.build | 8 + > > 31 files changed, 2152 insertions(+), 1991 deletions(-) delete mode > > 100644 doc/guides/nics/features/ifcvf.ini > > delete mode 100644 doc/guides/nics/ifc.rst create mode 100644 > > doc/guides/vdpadevs/features/default.ini > > create mode 100644 doc/guides/vdpadevs/features/ifcvf.ini > > create mode 100644 doc/guides/vdpadevs/features_overview.rst > > create mode 100644 doc/guides/vdpadevs/ifc.rst create mode 100644 > > doc/guides/vdpadevs/index.rst delete mode 100644 > > drivers/net/ifc/Makefile delete mode 100644 > > drivers/net/ifc/base/ifcvf.c delete mode 100644 > > drivers/net/ifc/base/ifcvf.h delete mode 100644 > > drivers/net/ifc/base/ifcvf_osdep.h > > delete mode 100644 drivers/net/ifc/ifcvf_vdpa.c delete mode 100644 > > drivers/net/ifc/meson.build delete mode 100644 > > drivers/net/ifc/rte_pmd_ifc_version.map > > create mode 100644 drivers/vdpa/Makefile create mode 100644 > > drivers/vdpa/ifc/Makefile create mode 100644 > > drivers/vdpa/ifc/base/ifcvf.c create mode 100644 > > drivers/vdpa/ifc/base/ifcvf.h create mode 100644 > > drivers/vdpa/ifc/base/ifcvf_osdep.h > > create mode 100644 drivers/vdpa/ifc/ifcvf_vdpa.c create mode 100644 > > drivers/vdpa/ifc/meson.build create mode 100644 > > drivers/vdpa/ifc/rte_pmd_ifc_version.map > > create mode 100644 drivers/vdpa/meson.build > > > > -- > > 1.8.3.1
Hi Xu From: Xu, Rosen > Hi Matan, > > 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"? > Thanks, > Rosen > > > -----Original Message----- > > From: dev <dev-bounces@dpdk.org> On Behalf Of Matan Azrad > > Sent: Tuesday, January 07, 2020 15:57 > > To: 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> > > Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; dev@dpdk.org; Thomas > > Monjalon <thomas@monjalon.net> > > Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA > > device drivers > > > > Hi all > > > > Any comments? > > > > From: Matan Azrad > > > As discussed and as described in RFC "[RFC] net: new vdpa PMD for > > > Mellanox devices", new vDPA driver is going to be added for Mellanox > > > devices - vDPA > > > mlx5 and more. > > > > > > The only vDPA driver now is the IFC driver that is located in net directory. > > > > > > The IFC driver and the new vDPA mlx5 driver provide the vDPA ops > > > introduced in librte_vhost and not the eth-dev ops. > > > All the others drivers in net class provide the eth-dev ops. > > > The set of features is also different. > > > > > > Create a new class for vDPA drivers and move IFC to this class. > > > Later, all the new drivers that implement the vDPA ops will be added > > > to the vDPA class. > > > > > > Also, a vDPA device driver features list was added to vDPA > documentation. > > > > > > Please review the features list and the series. > > > > > > Later on, I'm going to send the vDPA mlx5 driver. > > > > > > Thanks. > > > > > > > > > Matan Azrad (3): > > > drivers: introduce vDPA class > > > doc: add vDPA feature table > > > drivers: move ifc driver to the vDPA class > > > > > > MAINTAINERS | 6 +- > > > doc/guides/conf.py | 5 + > > > doc/guides/index.rst | 1 + > > > doc/guides/nics/features/ifcvf.ini | 8 - > > > doc/guides/nics/ifc.rst | 106 --- > > > doc/guides/nics/index.rst | 1 - > > > doc/guides/vdpadevs/features/default.ini | 55 ++ > > > doc/guides/vdpadevs/features/ifcvf.ini | 8 + > > > doc/guides/vdpadevs/features_overview.rst | 65 ++ > > > doc/guides/vdpadevs/ifc.rst | 106 +++ > > > doc/guides/vdpadevs/index.rst | 15 + > > > drivers/Makefile | 2 + > > > drivers/meson.build | 1 + > > > drivers/net/Makefile | 3 - > > > drivers/net/ifc/Makefile | 34 - > > > drivers/net/ifc/base/ifcvf.c | 329 -------- > > > drivers/net/ifc/base/ifcvf.h | 162 ---- > > > drivers/net/ifc/base/ifcvf_osdep.h | 52 -- > > > drivers/net/ifc/ifcvf_vdpa.c | 1280 ----------------------------- > > > drivers/net/ifc/meson.build | 9 - > > > drivers/net/ifc/rte_pmd_ifc_version.map | 3 - > > > drivers/net/meson.build | 1 - > > > drivers/vdpa/Makefile | 14 + > > > drivers/vdpa/ifc/Makefile | 34 + > > > drivers/vdpa/ifc/base/ifcvf.c | 329 ++++++++ > > > drivers/vdpa/ifc/base/ifcvf.h | 162 ++++ > > > drivers/vdpa/ifc/base/ifcvf_osdep.h | 52 ++ > > > drivers/vdpa/ifc/ifcvf_vdpa.c | 1280 > > > +++++++++++++++++++++++++++++ > > > drivers/vdpa/ifc/meson.build | 9 + > > > drivers/vdpa/ifc/rte_pmd_ifc_version.map | 3 + > > > drivers/vdpa/meson.build | 8 + > > > 31 files changed, 2152 insertions(+), 1991 deletions(-) delete > > > mode > > > 100644 doc/guides/nics/features/ifcvf.ini > > > delete mode 100644 doc/guides/nics/ifc.rst create mode 100644 > > > doc/guides/vdpadevs/features/default.ini > > > create mode 100644 doc/guides/vdpadevs/features/ifcvf.ini > > > create mode 100644 doc/guides/vdpadevs/features_overview.rst > > > create mode 100644 doc/guides/vdpadevs/ifc.rst create mode 100644 > > > doc/guides/vdpadevs/index.rst delete mode 100644 > > > drivers/net/ifc/Makefile delete mode 100644 > > > drivers/net/ifc/base/ifcvf.c delete mode 100644 > > > drivers/net/ifc/base/ifcvf.h delete mode 100644 > > > drivers/net/ifc/base/ifcvf_osdep.h > > > delete mode 100644 drivers/net/ifc/ifcvf_vdpa.c delete mode 100644 > > > drivers/net/ifc/meson.build delete mode 100644 > > > drivers/net/ifc/rte_pmd_ifc_version.map > > > create mode 100644 drivers/vdpa/Makefile create mode 100644 > > > drivers/vdpa/ifc/Makefile create mode 100644 > > > drivers/vdpa/ifc/base/ifcvf.c create mode 100644 > > > drivers/vdpa/ifc/base/ifcvf.h create mode 100644 > > > drivers/vdpa/ifc/base/ifcvf_osdep.h > > > create mode 100644 drivers/vdpa/ifc/ifcvf_vdpa.c create mode > > > 100644 drivers/vdpa/ifc/meson.build create mode 100644 > > > drivers/vdpa/ifc/rte_pmd_ifc_version.map > > > create mode 100644 drivers/vdpa/meson.build > > > > > > -- > > > 1.8.3.1
Hi Matan, > -----Original Message----- > From: Matan Azrad <matan@mellanox.com> > Sent: Wednesday, January 08, 2020 18:46 > To: Xu, Rosen <rosen.xu@intel.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> > Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; dev@dpdk.org; Thomas Monjalon > <thomas@monjalon.net>; Pei, Andy <andy.pei@intel.com> > Subject: RE: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device > drivers > > Hi Xu > > From: Xu, Rosen > > Hi Matan, > > > > 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. > > Thanks, > > Rosen > > > > > -----Original Message----- > > > From: dev <dev-bounces@dpdk.org> On Behalf Of Matan Azrad > > > Sent: Tuesday, January 07, 2020 15:57 > > > To: 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> > > > Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; dev@dpdk.org; Thomas > > > Monjalon <thomas@monjalon.net> > > > Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA > > > device drivers > > > > > > Hi all > > > > > > Any comments? > > > > > > From: Matan Azrad > > > > As discussed and as described in RFC "[RFC] net: new vdpa PMD for > > > > Mellanox devices", new vDPA driver is going to be added for > > > > Mellanox devices - vDPA > > > > mlx5 and more. > > > > > > > > The only vDPA driver now is the IFC driver that is located in net > directory. > > > > > > > > The IFC driver and the new vDPA mlx5 driver provide the vDPA ops > > > > introduced in librte_vhost and not the eth-dev ops. > > > > All the others drivers in net class provide the eth-dev ops. > > > > The set of features is also different. > > > > > > > > Create a new class for vDPA drivers and move IFC to this class. > > > > Later, all the new drivers that implement the vDPA ops will be > > > > added to the vDPA class. > > > > > > > > Also, a vDPA device driver features list was added to vDPA > > documentation. > > > > > > > > Please review the features list and the series. > > > > > > > > Later on, I'm going to send the vDPA mlx5 driver. > > > > > > > > Thanks. > > > > > > > > > > > > Matan Azrad (3): > > > > drivers: introduce vDPA class > > > > doc: add vDPA feature table > > > > drivers: move ifc driver to the vDPA class > > > > > > > > MAINTAINERS | 6 +- > > > > doc/guides/conf.py | 5 + > > > > doc/guides/index.rst | 1 + > > > > doc/guides/nics/features/ifcvf.ini | 8 - > > > > doc/guides/nics/ifc.rst | 106 --- > > > > doc/guides/nics/index.rst | 1 - > > > > doc/guides/vdpadevs/features/default.ini | 55 ++ > > > > doc/guides/vdpadevs/features/ifcvf.ini | 8 + > > > > doc/guides/vdpadevs/features_overview.rst | 65 ++ > > > > doc/guides/vdpadevs/ifc.rst | 106 +++ > > > > doc/guides/vdpadevs/index.rst | 15 + > > > > drivers/Makefile | 2 + > > > > drivers/meson.build | 1 + > > > > drivers/net/Makefile | 3 - > > > > drivers/net/ifc/Makefile | 34 - > > > > drivers/net/ifc/base/ifcvf.c | 329 -------- > > > > drivers/net/ifc/base/ifcvf.h | 162 ---- > > > > drivers/net/ifc/base/ifcvf_osdep.h | 52 -- > > > > drivers/net/ifc/ifcvf_vdpa.c | 1280 ----------------------------- > > > > drivers/net/ifc/meson.build | 9 - > > > > drivers/net/ifc/rte_pmd_ifc_version.map | 3 - > > > > drivers/net/meson.build | 1 - > > > > drivers/vdpa/Makefile | 14 + > > > > drivers/vdpa/ifc/Makefile | 34 + > > > > drivers/vdpa/ifc/base/ifcvf.c | 329 ++++++++ > > > > drivers/vdpa/ifc/base/ifcvf.h | 162 ++++ > > > > drivers/vdpa/ifc/base/ifcvf_osdep.h | 52 ++ > > > > drivers/vdpa/ifc/ifcvf_vdpa.c | 1280 > > > > +++++++++++++++++++++++++++++ > > > > drivers/vdpa/ifc/meson.build | 9 + > > > > drivers/vdpa/ifc/rte_pmd_ifc_version.map | 3 + > > > > drivers/vdpa/meson.build | 8 + > > > > 31 files changed, 2152 insertions(+), 1991 deletions(-) delete > > > > mode > > > > 100644 doc/guides/nics/features/ifcvf.ini > > > > delete mode 100644 doc/guides/nics/ifc.rst create mode 100644 > > > > doc/guides/vdpadevs/features/default.ini > > > > create mode 100644 doc/guides/vdpadevs/features/ifcvf.ini > > > > create mode 100644 doc/guides/vdpadevs/features_overview.rst > > > > create mode 100644 doc/guides/vdpadevs/ifc.rst create mode > > > > 100644 doc/guides/vdpadevs/index.rst delete mode 100644 > > > > drivers/net/ifc/Makefile delete mode 100644 > > > > drivers/net/ifc/base/ifcvf.c delete mode 100644 > > > > drivers/net/ifc/base/ifcvf.h delete mode 100644 > > > > drivers/net/ifc/base/ifcvf_osdep.h > > > > delete mode 100644 drivers/net/ifc/ifcvf_vdpa.c delete mode > > > > 100644 drivers/net/ifc/meson.build delete mode 100644 > > > > drivers/net/ifc/rte_pmd_ifc_version.map > > > > create mode 100644 drivers/vdpa/Makefile create mode 100644 > > > > drivers/vdpa/ifc/Makefile create mode 100644 > > > > drivers/vdpa/ifc/base/ifcvf.c create mode 100644 > > > > drivers/vdpa/ifc/base/ifcvf.h create mode 100644 > > > > drivers/vdpa/ifc/base/ifcvf_osdep.h > > > > create mode 100644 drivers/vdpa/ifc/ifcvf_vdpa.c create mode > > > > 100644 drivers/vdpa/ifc/meson.build create mode 100644 > > > > drivers/vdpa/ifc/rte_pmd_ifc_version.map > > > > create mode 100644 drivers/vdpa/meson.build > > > > > > > > -- > > > > 1.8.3.1
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.
Hi, > -----Original Message----- > From: Thomas Monjalon <thomas@monjalon.net> > Sent: Wednesday, January 08, 2020 20:59 > To: 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>; Xu, Rosen <rosen.xu@intel.com> > Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; dev@dpdk.org; Pei, Andy > <andy.pei@intel.com> > Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device > drivers > > 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. 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. 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. So, it's not ok to move ifc code from drivers/net.
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.
On 1/9/20 9:41 AM, Thomas Monjalon wrote: > 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. > > I agree with Thomas, the vDPA drivers do not implement the ethdev ops. And OVS does not use the Vhost PMD for the Vhost-user ports, but directly call the librte_vhost APIs. Regards, Maxime
> -----Original Message----- > From: Maxime Coquelin <maxime.coquelin@redhat.com> > Sent: Thursday, January 09, 2020 17:24 > To: Thomas Monjalon <thomas@monjalon.net>; Xu, Rosen > <rosen.xu@intel.com> > Cc: Matan Azrad <matan@mellanox.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; Pei, Andy <andy.pei@intel.com> > Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device > drivers > > > > On 1/9/20 9:41 AM, Thomas Monjalon wrote: > > 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. > > > > > > I agree with Thomas, the vDPA drivers do not implement the ethdev ops. For OVS hasn't integrated vDPA, it doesn't implement ethdev ops, but there are many discussions in OVS community about vDPA, it seems vDPA will be supported in OVS in the near feature. > And OVS does not use the Vhost PMD for the Vhost-user ports, but directly > call the librte_vhost APIs. I'm afraid you are wrong, pls read these documents which introduce how to use vHost-user PMD in OVS: http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/ http://docs.openvswitch.org/en/latest/topics/dpdk/pmd/ > Regards, > Maxime
On 1/9/20 10:49 AM, Xu, Rosen wrote: > > >> -----Original Message----- >> From: Maxime Coquelin <maxime.coquelin@redhat.com> >> Sent: Thursday, January 09, 2020 17:24 >> To: Thomas Monjalon <thomas@monjalon.net>; Xu, Rosen >> <rosen.xu@intel.com> >> Cc: Matan Azrad <matan@mellanox.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; Pei, Andy <andy.pei@intel.com> >> Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device >> drivers >> >> >> >> On 1/9/20 9:41 AM, Thomas Monjalon wrote: >>> 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. >>> >>> >> >> I agree with Thomas, the vDPA drivers do not implement the ethdev ops. > > For OVS hasn't integrated vDPA, it doesn't implement ethdev ops, but there are many > discussions in OVS community about vDPA, it seems vDPA will be supported in OVS in > the near feature. I agree with this statement, but if you look at Mellanox series being reviewed, it is defining a new type of port and not use the regular DPDK port type. >> And OVS does not use the Vhost PMD for the Vhost-user ports, but directly >> call the librte_vhost APIs. > > I'm afraid you are wrong, pls read these documents which introduce how to use vHost-user PMD in OVS: > http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/ > http://docs.openvswitch.org/en/latest/topics/dpdk/pmd/ I can confirm that below command to add ports is not using Vhost PMD but directly the librte_vhost API: $ ovs-vsctl add-port br0 dpdkvhostclient0 \ -- set Interface dpdkvhostclient0 type=dpdkvhostuserclient \ options:vhost-server-path=/tmp/dpdkvhostclient0 Please check the OVS source code. It is possible to use the Vhost PMD as a regular DPDK port, but this is not with above command, and not the recommended way. >> Regards, >> Maxime >
On 1/9/20 10:49 AM, Xu, Rosen wrote: > > >> -----Original Message----- >> From: Maxime Coquelin <maxime.coquelin@redhat.com> >> Sent: Thursday, January 09, 2020 17:24 >> To: Thomas Monjalon <thomas@monjalon.net>; Xu, Rosen >> <rosen.xu@intel.com> >> Cc: Matan Azrad <matan@mellanox.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; Pei, Andy <andy.pei@intel.com> >> Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device >> drivers >> >> >> >> On 1/9/20 9:41 AM, Thomas Monjalon wrote: >>> 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. >>> >>> >> >> I agree with Thomas, the vDPA drivers do not implement the ethdev ops. > > For OVS hasn't integrated vDPA, it doesn't implement ethdev ops, but there are many > discussions in OVS community about vDPA, it seems vDPA will be supported in OVS in > the near feature. I agree with this statement, but if you look at Mellanox series being reviewed, it is defining a new type of port and not use the regular DPDK port type. >> And OVS does not use the Vhost PMD for the Vhost-user ports, but directly >> call the librte_vhost APIs. > > I'm afraid you are wrong, pls read these documents which introduce how to use vHost-user PMD in OVS: > http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/ > http://docs.openvswitch.org/en/latest/topics/dpdk/pmd/ I can confirm that below command to add ports is not using Vhost PMD but directly the librte_vhost API: $ ovs-vsctl add-port br0 dpdkvhostclient0 \ -- set Interface dpdkvhostclient0 type=dpdkvhostuserclient \ options:vhost-server-path=/tmp/dpdkvhostclient0 Please check the OVS source code. It is possible to use the Vhost PMD as a regular DPDK port, but this is not with above command, and not the recommended way. >> Regards, >> Maxime >
> -----Original Message----- > From: Thomas Monjalon <thomas@monjalon.net> > Sent: Thursday, January 09, 2020 16:41 > 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; Pei, Andy <andy.pei@intel.com> > 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 <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. 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=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". 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://patchwork.ozlabs.org/patch/1178474/ 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.
From: Xu, Rosen <rosen.xu@intel.com> > > -----Original Message----- > > From: Thomas Monjalon <thomas@monjalon.net> > > Sent: Thursday, January 09, 2020 16:41 > > 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; Pei, Andy <andy.pei@intel.com> > > 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 <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. > > 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=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". > > 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=https%3A%2F%2Fpatch > work.ozlabs.org%2Fpatch%2F1178474%2F&data=02%7C01%7Cmatan%4 > 0mellanox.com%7C9e84c2581e2f414e0aca08d794f22e8d%7Ca652971c7d2e4d > 9ba6a4d149256f461b%7C0%7C0%7C637141640216181763&sdata=TA%2F > 0zU495kXUqhC6eP09NDzBZfjJz1dbfkRcDpV%2BYAs%3D&reserved=0 > > 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. Hi OVS like any other application should use the current API of vDPA to attach a probed vdpa device to a vhost device. See example application /examples/vdpa. Here, we just introduce a new class to hold all the vDPA drivers, no change in the API. As I understand, no vDPA device is currently integrated in OVS. 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 queue, once it will be there, I guess the offload will be configured by the representor of the vdpa device(VF) which is managed by an ethdev device. Matan.
> -----Original Message----- > From: Matan Azrad <matan@mellanox.com> > Sent: Thursday, January 09, 2020 19:34 > To: Xu, Rosen <rosen.xu@intel.com>; Thomas Monjalon > <thomas@monjalon.net> > Cc: 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; Pei, Andy <andy.pei@intel.com>; Roni Bar Yanai > <roniba@mellanox.com> > Subject: RE: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device > drivers > > > > From: Xu, Rosen <rosen.xu@intel.com> > > > -----Original Message----- > > > From: Thomas Monjalon <thomas@monjalon.net> > > > Sent: Thursday, January 09, 2020 16:41 > > > 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; Pei, Andy <andy.pei@intel.com> > > > 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 <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. > > > > 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=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". > > > > 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=https%3A%2F%2Fpatc > > h > > > work.ozlabs.org%2Fpatch%2F1178474%2F&data=02%7C01%7Cmatan% > 4 > > > 0mellanox.com%7C9e84c2581e2f414e0aca08d794f22e8d%7Ca652971c7d2e4 > d > > > 9ba6a4d149256f461b%7C0%7C0%7C637141640216181763&sdata=TA% > 2F > > 0zU495kXUqhC6eP09NDzBZfjJz1dbfkRcDpV%2BYAs%3D&reserved=0 > > > > 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. > > > Hi > > OVS like any other application should use the current API of vDPA to attach a > probed vdpa device to a vhost device. > See example application /examples/vdpa. > > Here, we just introduce a new class to hold all the vDPA drivers, no change in > the API. > > As I understand, no vDPA device is currently integrated in OVS. > > 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 queue, > once it will be there, I guess the offload will be configured by the representor > of the vdpa device(VF) which is managed by an ethdev device. > > > Matan. > Hi, I'm still confused about your last sentence " the representor of the vdpa device(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.
> -----Original Message----- > From: Maxime Coquelin <maxime.coquelin@redhat.com> > Sent: Thursday, January 09, 2020 18:42 > To: Xu, Rosen <rosen.xu@intel.com>; Thomas Monjalon > <thomas@monjalon.net> > Cc: Matan Azrad <matan@mellanox.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; Pei, Andy <andy.pei@intel.com> > Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device > drivers > > > > On 1/9/20 10:49 AM, Xu, Rosen wrote: > > > > > >> -----Original Message----- > >> From: Maxime Coquelin <maxime.coquelin@redhat.com> > >> Sent: Thursday, January 09, 2020 17:24 > >> To: Thomas Monjalon <thomas@monjalon.net>; Xu, Rosen > >> <rosen.xu@intel.com> > >> Cc: Matan Azrad <matan@mellanox.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; Pei, Andy > >> <andy.pei@intel.com> > >> Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA > >> device drivers > >> > >> > >> > >> On 1/9/20 9:41 AM, Thomas Monjalon wrote: > >>> 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. > >>> > >>> > >> > >> I agree with Thomas, the vDPA drivers do not implement the ethdev ops. > > > > For OVS hasn't integrated vDPA, it doesn't implement ethdev ops, but > > there are many discussions in OVS community about vDPA, it seems vDPA > > will be supported in OVS in the near feature. > > I agree with this statement, but if you look at Mellanox series being reviewed, > it is defining a new type of port and not use the regular DPDK port type. > > >> And OVS does not use the Vhost PMD for the Vhost-user ports, but > >> directly call the librte_vhost APIs. > > > > I'm afraid you are wrong, pls read these documents which introduce how > to use vHost-user PMD in OVS: > > http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/ > > http://docs.openvswitch.org/en/latest/topics/dpdk/pmd/ > > I can confirm that below command to add ports is not using Vhost PMD but > directly the librte_vhost API: > > $ ovs-vsctl add-port br0 dpdkvhostclient0 \ > -- set Interface dpdkvhostclient0 type=dpdkvhostuserclient \ > options:vhost-server-path=/tmp/dpdkvhostclient0 > > Please check the OVS source code. > > It is possible to use the Vhost PMD as a regular DPDK port, but this is not > with above command, and not the recommended way. > > >> Regards, > >> Maxime > > Hi, What I mentioned and questions are in Matan's email thread. Thanks, Rosen
10/01/2020 03:38, Xu, Rosen: > From: Matan Azrad <matan@mellanox.com> > > From: Xu, Rosen <rosen.xu@intel.com> > > > From: Thomas Monjalon <thomas@monjalon.net> > > > > 09/01/2020 03:27, Xu, Rosen: > > > > > 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. > > > > > > 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=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". > > > > > > 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=https%3A%2F%2Fpatc > > > h > > > > > work.ozlabs.org%2Fpatch%2F1178474%2F&data=02%7C01%7Cmatan% > > 4 > > > > > 0mellanox.com%7C9e84c2581e2f414e0aca08d794f22e8d%7Ca652971c7d2e4 > > d > > > > > 9ba6a4d149256f461b%7C0%7C0%7C637141640216181763&sdata=TA% > > 2F > > > 0zU495kXUqhC6eP09NDzBZfjJz1dbfkRcDpV%2BYAs%3D&reserved=0 > > > > > > 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. > > > > > > Hi > > > > OVS like any other application should use the current API of vDPA to attach a > > probed vdpa device to a vhost device. > > See example application /examples/vdpa. > > > > Here, we just introduce a new class to hold all the vDPA drivers, no change in > > the API. > > > > As I understand, no vDPA device is currently integrated in OVS. > > > > 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 queue, > > once it will be there, I guess the offload will be configured by the representor > > of the vdpa device(VF) which is managed by an ethdev device. > > > > > > Matan. > > > Hi, > > I'm still confused about your last sentence " the representor of the vdpa device(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? A vDPA port does not allow any ethdev operations (like rte_flow). In order to configure some offloads on the device, OVS needs an ethdev port. In Mellanox case, an ethdev VF representor port can be instantiated. So we may have two ports for the same device: - vDPA for data path with the VM - ethdev for offloads control path
> -----Original Message----- > From: Thomas Monjalon <thomas@monjalon.net> > Sent: Friday, January 10, 2020 17:21 > To: Matan Azrad <matan@mellanox.com>; Xu, Rosen <rosen.xu@intel.com> > Cc: 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; Pei, Andy <andy.pei@intel.com>; Roni Bar Yanai > <roniba@mellanox.com> > Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device > drivers > > 10/01/2020 03:38, Xu, Rosen: > > From: Matan Azrad <matan@mellanox.com> > > > From: Xu, Rosen <rosen.xu@intel.com> > > > > From: Thomas Monjalon <thomas@monjalon.net> > > > > > 09/01/2020 03:27, Xu, Rosen: > > > > > > 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. > > > > > > > > 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=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". > > > > > > > > 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=https%3A%2F%2F > > > > patc > > > > h > > > > > > > > work.ozlabs.org%2Fpatch%2F1178474%2F&data=02%7C01%7Cmatan% > > > 4 > > > > > > > > 0mellanox.com%7C9e84c2581e2f414e0aca08d794f22e8d%7Ca652971c7d2e4 > > > d > > > > > > > 9ba6a4d149256f461b%7C0%7C0%7C637141640216181763&sdata=TA% > > > 2F > > > > > 0zU495kXUqhC6eP09NDzBZfjJz1dbfkRcDpV%2BYAs%3D&reserved=0 > > > > > > > > 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. > > > > > > > > > Hi > > > > > > OVS like any other application should use the current API of vDPA to > > > attach a probed vdpa device to a vhost device. > > > See example application /examples/vdpa. > > > > > > Here, we just introduce a new class to hold all the vDPA drivers, no > > > change in the API. > > > > > > As I understand, no vDPA device is currently integrated in OVS. > > > > > > 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 queue, once it will be there, I guess the > > > offload will be configured by the representor of the vdpa device(VF) > which is managed by an ethdev device. > > > > > > > > > Matan. > > > > > Hi, > > > > I'm still confused about your last sentence " the representor of the vdpa > device(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? > > A vDPA port does not allow any ethdev operations (like rte_flow). > In order to configure some offloads on the device, OVS needs an ethdev port. > In Mellanox case, an ethdev VF representor port can be instantiated. > So we may have two ports for the same device: > - vDPA for data path with the VM > - ethdev for offloads control path It's obviously that OVS needs these two functions of same device. In DPDK part, I have some concerns about how to scan, probe and bond these two ports of same device. Could you introduce it? As far as I know, each network device provided by DPDK is identified as a port in OVS, do you mind to take more clarification about how to connect or bond these two functions of same device in OVS part?
10/01/2020 15:18, Xu, Rosen: > From: Thomas Monjalon <thomas@monjalon.net> > > 10/01/2020 03:38, Xu, Rosen: > > > From: Matan Azrad <matan@mellanox.com> > > > > From: Xu, Rosen <rosen.xu@intel.com> > > > > > From: Thomas Monjalon <thomas@monjalon.net> > > > > > > 09/01/2020 03:27, Xu, Rosen: > > > > > > > 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. > > > > > > > > > > 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=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". > > > > > > > > > > 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=https%3A%2F%2F > > > > > patc > > > > > h > > > > > > > > > > > work.ozlabs.org%2Fpatch%2F1178474%2F&data=02%7C01%7Cmatan% > > > > 4 > > > > > > > > > > > 0mellanox.com%7C9e84c2581e2f414e0aca08d794f22e8d%7Ca652971c7d2e4 > > > > d > > > > > > > > > 9ba6a4d149256f461b%7C0%7C0%7C637141640216181763&sdata=TA% > > > > 2F > > > > > > > 0zU495kXUqhC6eP09NDzBZfjJz1dbfkRcDpV%2BYAs%3D&reserved=0 > > > > > > > > > > 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. > > > > > > > > > > > > Hi > > > > > > > > OVS like any other application should use the current API of vDPA to > > > > attach a probed vdpa device to a vhost device. > > > > See example application /examples/vdpa. > > > > > > > > Here, we just introduce a new class to hold all the vDPA drivers, no > > > > change in the API. > > > > > > > > As I understand, no vDPA device is currently integrated in OVS. > > > > > > > > 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 queue, once it will be there, I guess the > > > > offload will be configured by the representor of the vdpa device(VF) > > which is managed by an ethdev device. > > > > > > > > > > > > Matan. > > > > > > > Hi, > > > > > > I'm still confused about your last sentence " the representor of the vdpa > > device(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? > > > > A vDPA port does not allow any ethdev operations (like rte_flow). > > In order to configure some offloads on the device, OVS needs an ethdev port. > > In Mellanox case, an ethdev VF representor port can be instantiated. > > So we may have two ports for the same device: > > - vDPA for data path with the VM > > - ethdev for offloads control path > > It's obviously that OVS needs these two functions of same device. > In DPDK part, I have some concerns about how to scan, probe and bond these two ports > of same device. Could you introduce it? > As far as I know, each network device provided by DPDK is identified as a port in OVS, > do you mind to take more clarification about how to connect or bond these two > functions of same device in OVS part? This is a different discussion. You are asking a design review of vDPA integration in OVS. I think it should be discussed separately. And I have no time for such discussion currently. It will come later. As it does not block this series, I will stop here, sorry. Feel free to start a thread proposing how to integrate vDPA with offloads, either in general, or specifically for IFC.