From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id F129D2BC8 for ; Tue, 9 Jan 2018 23:07:47 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2018 14:07:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,337,1511856000"; d="scan'208";a="9470775" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.48]) ([10.237.220.48]) by orsmga008.jf.intel.com with ESMTP; 09 Jan 2018 14:07:44 -0800 To: Remy Horton , dev@dpdk.org Cc: John McNamara , Wenzhuo Lu , Jingjing Wu , Declan Doherty , Mohammad Abdul Awal References: <20180108143720.7994-1-remy.horton@intel.com> <20180108143720.7994-3-remy.horton@intel.com> From: Ferruh Yigit Message-ID: Date: Tue, 9 Jan 2018 22:07:43 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180108143720.7994-3-remy.horton@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v4 2/5] eal: add Port Representor command-line option 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, 09 Jan 2018 22:07:48 -0000 On 1/8/2018 2:37 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. > > By default the Port Representor infrastructure is not enabled. This > patch implements the --enable-representor EAL command-line parameter > that activates representation functionality.> > Signed-off-by: Declan Doherty > Signed-off-by: Mohammad Abdul Awal > Signed-off-by: Remy Horton <...> > @@ -78,6 +78,7 @@ const struct option > eal_long_options[] = { > {OPT_BASE_VIRTADDR, 1, NULL, OPT_BASE_VIRTADDR_NUM }, > {OPT_CREATE_UIO_DEV, 0, NULL, OPT_CREATE_UIO_DEV_NUM }, > + {OPT_ENABLE_REPRESENTOR, 0, NULL, OPT_ENABLE_REPRESENTOR_NUM }, There must be some kind of documentation to document new eal option. <...> > @@ -83,6 +83,8 @@ enum { > OPT_VFIO_INTR_NUM, > #define OPT_VMWARE_TSC_MAP "vmware-tsc-map" > OPT_VMWARE_TSC_MAP_NUM, > +#define OPT_ENABLE_REPRESENTOR "enable-representor" > + OPT_ENABLE_REPRESENTOR_NUM, In this context the meaning is clear. But when a newcomer checking the source code from scratch I believe it may not be very clear what "enable-representor" does, what is represented etc. What do you think? Overall there are mixed usage, but I would vote for using port-representor everywhere just representor used, will it be too long? Also I have seen this shorten as "prep" which where looks like short of "prepare", what do you think about another keyword? <...> > + > +int rte_representor_enabled(void) > +{ > + return internal_config.enable_representor; > +} Isn't this need to be in .map file. I didn't test but will it work when build for shared library?