From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <remy.horton@intel.com>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
 by dpdk.org (Postfix) with ESMTP id 16945728A
 for <dev@dpdk.org>; Thu, 11 Jan 2018 10:38:06 +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 fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 11 Jan 2018 01:38:06 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.46,343,1511856000"; 
   d="scan'208";a="9914384"
Received: from rhorton-mobl1.ger.corp.intel.com (HELO [163.33.230.82])
 ([163.33.230.82])
 by orsmga008.jf.intel.com with ESMTP; 11 Jan 2018 01:38:03 -0800
To: Yuanhan Liu <yliu@fridaylinux.org>
References: <20171222145221.10474-1-remy.horton@intel.com>
 <20180108143720.7994-1-remy.horton@intel.com>
 <20180111031820.GR29540@yliu-mob>
Cc: dev@dpdk.org, John McNamara <john.mcnamara@intel.com>,
 Wenzhuo Lu <wenzhuo.lu@intel.com>, Jingjing Wu <jingjing.wu@intel.com>,
 Thomas Monjalon <thomas@monjalon.net>, Shahaf Shuler <shahafs@mellanox.com>,
 Olga Shern <olgas@mellanox.com>, Alex Rosenbaum <alexr@mellanox.com>
From: Remy Horton <remy.horton@intel.com>
Organization: Intel Shannon Limited
Message-ID: <221190ed-21a7-9f40-55fb-156c4ecaf787@intel.com>
Date: Thu, 11 Jan 2018 09:38:03 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <20180111031820.GR29540@yliu-mob>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH v4 0/5] lib: add Port Representors
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: Thu, 11 Jan 2018 09:38:07 -0000


On 11/01/2018 03:18, Yuanhan Liu wrote:
[..]
> - Then inside the driver (say, i40e)
>
>   * allocate 1 DPDK ethdev port
>   * allocate 4 DPDK ethdev port, one for each VF specified by
>     the vf_ports option. And these are VF representors.
>   * link the VF representors to the right VF port
>     For example, for i40e, it should be (from patch 3):
>         vf = &pf->vfs[representor->vport_id];
>   * set the proper ethdev callbacks for the VF representors.
>
> As you can see, none of above complexity is introduced.

What springs to mind is whether this would end up delegating to the 
individual PMDs tasks that in the patchset are handled centrally in the 
library. Question is where the balance should be, and as an aside what 
should be the base-line requirements for a PMD to be "port representable".

..Remy