From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 8E12C2BC8 for ; Tue, 9 Jan 2018 23:10:25 +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 orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2018 14:10:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,337,1511856000"; d="scan'208";a="9471472" 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:10:23 -0800 To: Remy Horton , dev@dpdk.org Cc: John McNamara , Wenzhuo Lu , Jingjing Wu References: <20180108143720.7994-1-remy.horton@intel.com> <20180108143720.7994-6-remy.horton@intel.com> From: Ferruh Yigit Message-ID: <117e871e-faf8-a38e-8baa-59c01bc00ba4@intel.com> Date: Tue, 9 Jan 2018 22:10:22 +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-6-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 5/5] app/test-pmd: add Port Representor commands 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:10:26 -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. > > This patch adds the 'add representor' and 'del representor' commands > to test-pmd, which respectively allow the adding and removing of > port representors. > > Signed-off-by: Remy Horton <...> > + > + rte_log(RTE_LOG_INFO, RTE_LOGTYPE_USER1, "%s(): addr:%s vport:%i\n", > + __func__, res->pf, res->vport); this file tends to use printf for logs. <...> > @@ -15576,6 +15662,8 @@ cmdline_parse_ctx_t main_ctx[] = { > (cmdline_parse_inst_t *) &cmd_show_bonding_config, > (cmdline_parse_inst_t *) &cmd_set_bonding_primary, > (cmdline_parse_inst_t *) &cmd_add_bonding_slave, > + (cmdline_parse_inst_t *) &cmd_add_representor, > + (cmdline_parse_inst_t *) &cmd_del_representor, Please update cmd_help_long_parsed() to add new commands. <...> > +Adding a representor for a VF requires specifying the PF in > +``Bus_DomBDF`` format alongside the index number of the VF:: > + > + testpmd> add representor pci_0000:81:00.0 0 I am for grouping port related commands under "port" command, these are all OK in their context, but when you look into all testpmd command it turns into mess. What do you think for: port representor add port representor del