From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 4A9661B2FE for ; Tue, 30 Jan 2018 10:23:40 +0100 (CET) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id A70B64C0073; Tue, 30 Jan 2018 09:23:38 +0000 (UTC) Received: from [192.168.38.17] (84.52.114.114) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 30 Jan 2018 09:23:32 +0000 To: Remy Horton , CC: John McNamara , Declan Doherty , Mohammad Abdul Awal References: <20180110155406.17428-1-remy.horton@intel.com> <20180110155406.17428-2-remy.horton@intel.com> From: Andrew Rybchenko Message-ID: Date: Tue, 30 Jan 2018 12:23:28 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180110155406.17428-2-remy.horton@intel.com> Content-Language: en-GB X-Originating-IP: [84.52.114.114] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23628.003 X-TM-AS-Result: No--14.345500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1517304219-TIvt5GdAHjVu Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v5 1/5] lib: add Port Representor library 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: , X-List-Received-Date: Tue, 30 Jan 2018 09:23:40 -0000 On 01/10/2018 06:54 PM, Remy Horton wrote: > Port Representors provide a logical presentation in DPDK of VF (virtual > function) ports for the purposes of control and monitoring. Each port > representor device represents a single VF and is associated with it's > parent physical function (PF) PMD which provides the back-end hooks for > the representor device ops and defines the control domain to which that > port belongs. This allows to use existing DPDK APIs to monitor and control > the port without the need to create and maintain VF specific APIs. > > The library provides the broker infrastructure to be instantiated by > base driver and corresponding methods to manage the broker > infrastructure. The broker keeps records of list of representor PMDs. > The library also provides methods to manage the representor PMDs by the > broker. > > Signed-off-by: Declan Doherty > Signed-off-by: Mohammad Abdul Awal > Signed-off-by: Remy Horton > --- > MAINTAINERS | 9 +- > config/common_base | 5 + > doc/api/doxy-api-index.md | 1 + > doc/api/doxy-api.conf | 1 + > doc/guides/prog_guide/index.rst | 1 + > doc/guides/prog_guide/representor_lib.rst | 62 ++++ > doc/guides/rel_notes/release_18_02.rst | 10 + > lib/Makefile | 3 + > lib/librte_eal/common/eal_common_log.c | 1 + > lib/librte_eal/common/include/rte_log.h | 1 + > lib/librte_representor/Makefile | 26 ++ > lib/librte_representor/rte_port_representor.c | 345 +++++++++++++++++++++ > lib/librte_representor/rte_port_representor.h | 60 ++++ > .../rte_port_representor_driver.h | 140 +++++++++ > .../rte_port_representor_version.map | 8 + > mk/rte.app.mk | 1 + > 16 files changed, 673 insertions(+), 1 deletion(-) > create mode 100644 doc/guides/prog_guide/representor_lib.rst > create mode 100644 lib/librte_representor/Makefile > create mode 100644 lib/librte_representor/rte_port_representor.c > create mode 100644 lib/librte_representor/rte_port_representor.h > create mode 100644 lib/librte_representor/rte_port_representor_driver.h > create mode 100644 lib/librte_representor/rte_port_representor_version.map It look like it deserves an entry in the doc/guides/nics/features. Also right now it is bound to rte_eth_dev inside, but does not bound to ethdev outside (API, naming).  May be it is really good since it could be useful to other cases of VFs (not networking). Ideally it should use dynamic logging from the very beginning. Also there is a work to standardize device identification in current release cycle. I think it would be good if the first argument of rte_representor_register/unregister() follow it (right now it is something like pci_0000:01:00.1). May be it is not a problem to change it in the next release cycle if the API is EXPERIMENTAL. Wouldn't it be easier for user if register/unregister gets VFs device string on input (not PF string plus VF number). It is just a question and I'd like to know your thoughts on it. <...> > diff --git a/lib/librte_representor/rte_port_representor_version.map b/lib/librte_representor/rte_port_representor_version.map > new file mode 100644 > index 0000000..b26600c > --- /dev/null > +++ b/lib/librte_representor/rte_port_representor_version.map > @@ -0,0 +1,8 @@ > +DPDK_18.02 { > + global: > + > + rte_representor_port_register; > + rte_representor_port_unregister; > + > + local: *; > +}; As I understand it should be EXPERIMENTAL (with __rte_experimental and EXPERIMENTAL marks in the doxygen documentation as well). <...> Acked-by: Andrew Rybchenko