From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ferruh.yigit@intel.com>
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
 by dpdk.org (Postfix) with ESMTP id 8E12C2BC8
 for <dev@dpdk.org>; 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 <remy.horton@intel.com>, dev@dpdk.org
Cc: John McNamara <john.mcnamara@intel.com>, Wenzhuo Lu
 <wenzhuo.lu@intel.com>, Jingjing Wu <jingjing.wu@intel.com>
References: <20180108143720.7994-1-remy.horton@intel.com>
 <20180108143720.7994-6-remy.horton@intel.com>
From: Ferruh Yigit <ferruh.yigit@intel.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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 <remy.horton@intel.com>

<...>

> +
> +	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 <pf_address> <vport_id>
port representor del <pf_address> <vport_id>