From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id D9FFD1B010 for ; Thu, 11 Jan 2018 04:18:24 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 60FF42096D; Wed, 10 Jan 2018 22:18:24 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 10 Jan 2018 22:18:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fridaylinux.org; h=cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=IP5PtVecgzAiLEHpMkZU/b0RllwJOfoagaJQiTZrcT4=; b=NKQD9pt7 uf/41pkTbC/uBUGtmTub12HCoSOk8nbrUxU/WYyVo/RZaxE4btJX1GFZiVOqHQ5W 5mGM6vetyjZ+6ghAqn4l399Mmd8mTOjhWDDWu5FDa8uWgqq4FNJL7HGcAlis8j9+ PGwD0i0GMzgRvVOD9k8o5ZohraT9LBonOSO7fcDyG4aEfL7UJpp9SOCXZ8uI1jIP TJD4YzEudhML4ZR8mxG7xToq7/s2HlO3a+WMh6Wol9o3WgqrpyWtPiWVsUGcSnwU dLG5GkvJnSRh9VmsUviA96gr6YGTNyK212c5Fx9Y1RjotXiPB6nRRfDLpwN+x9zQ okeTWkZ2EofArw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=IP5PtVecgzAiLEHpMkZU/b0RllwJO foagaJQiTZrcT4=; b=NCM85ioa/je4lyk3s/LitVD6XD67fwDWB5FL03vnaM6BL 1EE90AkHwMsz7jC7EDZU0TsVpKY22XdvdsjV2R8hwId1GtCkK5WwFVLYZSgQ6Vc2 nCfDhwxTCSbqJTSu0NL2UvBJ5zqog0kiNzvmIA9ixzrKz26BqD7NuZ5+X3lVRYPt wLFxICL9scJCw3pKQXLauuW+G6OSYrr4AJ2IP3upUI8tD802381MZAJ0EsWgk9ut iuKHBTeTa1ca/XNyTtWL3WVIyoxflGtYn6wLvVG3hIgv1/V8rGJGsl2oGGVf1VQv 8F0Z7mfxPiDtYTv319PjLdibCx1fvmrqOmoC54kuQ== X-ME-Sender: Received: from yliu-mob (unknown [115.148.91.233]) by mail.messagingengine.com (Postfix) with ESMTPA id 4BC187E34B; Wed, 10 Jan 2018 22:18:22 -0500 (EST) Date: Thu, 11 Jan 2018 11:18:20 +0800 From: Yuanhan Liu To: Remy Horton Cc: dev@dpdk.org, John McNamara , Wenzhuo Lu , Jingjing Wu , Thomas Monjalon , Shahaf Shuler , Olga Shern , Alex Rosenbaum Message-ID: <20180111031820.GR29540@yliu-mob> References: <20171222145221.10474-1-remy.horton@intel.com> <20180108143720.7994-1-remy.horton@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180108143720.7994-1-remy.horton@intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 03:18:25 -0000 On Mon, Jan 08, 2018 at 02:37:15PM +0000, 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. Firstly, I don't object this model. More precisely, I don't object for introducing a port to control the VFs. I even like this idea a bit, for at least it could get rid of some PMD specific APIs, say rte_pmd_i40e_set_vf_mac_addr, etc. However, I don't quite like this design, for a simple reason, it makes things way more complex: - new APIs are introduced. - new virtual PMD is required - broker concept I was thinking below should work: - Use the devargs for enabling the port (or VF) representor model. For example: -w 04:00.0,vf_ports=0-3 The vf_ports is for telling the driver we are going to create VF representors for VF 0 to VF 3. It could be a port mask like what this patchset does. - 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. Probably you might find something are missing: - to identify the vf rep port for a specific VF. Which could be addressed by the new devargs syntax we are proposing: http://dpdk.org/ml/archives/dev/2017-December/084234.html For example, the right VF rep port could be identified by below devarg: bus=pci,id=04:00.0/class=eth,vf_id=0 - the ability of hotplug I think it could also be addressed by the new devargs syntax, also by re-using the rte_eth_dev_attach() function: rte_eth_dev_attach("bus=pci,id=04:00.0/class=eth,vf_id=4", &port_id); Thoughts? --yliu > > +-----------------------------+ +---------------+ +---------------+ > | Control Plane | | Data Plane | | Data Plane | > | Application | | Application | | Application | > +-----------------------------+ +---------------+ +---------------+ > | eth dev api | | eth dev api | | eth dev api | > +-----------------------------+ +---------------+ +---------------+ > +-------+ +-------+ +-------+ +---------------+ +---------------+ > | PF0 | | Port | | Port | | VF0 PMD | | VF0 PMD | > | PMD <--+ Rep 0 | | Rep 1 | +---------------+ +------+--------+ > | | | PMD | | PMD | | > +---+--^+ +-------+ +-+-----+ | > | | | | | > | +----------------+ | | > | | | > | | | > +--------------------------------+ | > | | HW (logical view) | | | > | --+------+ +-------+ +---+---+ | | > | | PF | | VF0 | | VF1 | | | > | | | | | | +----------------------------+ > | +--------+ +-------+ +-------+ | > | +----------------------------+ | > | | VEB | | > | +----------------------------+ | > | +--------+ | > | | Port | | > | | 0 | | > | +--------+ | > +--------------------------------+ > > The figure above shows a deployment where the PF is bound to a DPDK control > plane application which uses representor ports to manage the configuration and > monitoring of it's VF ports. Each virtual function is represented in the > application by a representor port PMD which enables control of the corresponding > VF through eth dev APIs on the representor PMD such as: > > - void rte_eth_promiscuous_enable(uint8_t port_id); > - void rte_eth_promiscuous_disable(uint8_t port_id); > - void rte_eth_allmulticast_enable(uint8_t port_id); > - void rte_eth_allmulticast_disable(uint8_t port_id); > - int rte_eth_dev_mac_addr_add(uint8_t port, struct ether_addr *mac_addr, > uint32_t pool); > - int rte_eth_dev_set_vlan_offload(uint8_t port_id, int offload_mask); > > as well as monitoring through API's like > > - void rte_eth_link_get(uint8_t port_id, struct rte_eth_link *link); > - int rte_eth_stats_get(uint8_t port_id, struct rte_eth_stats *stats); > > The port representor infrastructure is enabled through a single common, device > independent, virtual PMD whos context is initialized and enabled through a > broker instance running within the context of the physical function device > driver. > > +-------------------------+ +-------------------------+ > | rte_ethdev | | rte_ethdev | > +-------------------------+ +-------------------------+ > | Physical Function PMD | | Port Reperesentor PMD | > | +-------------+ | | +---------+ +---------+ | > | | Representor | | | | dev_data| | dev_ops | | > | | Broker | | | +----+----+ +----+----+ | > | | +---------+ | | +------|-----------|------+ > | | | VF Port | | | | | > | | | Context +------------------+ | > | | +---------+ | | | > | | +---------+ | | | > | | | Handler +------------------------------+ > | | | Ops | | | > | | +---------+ | | > | +-------------+ | > +-------------------------+ > > Creation of representor ports can be achieved either through the --vdev EAL > option or through the rte_vdev_init() API. Each port representor requires the > BDF of it's parent PF and the Virtual Function ID of the port which the > representor will support. During initialization of the representor PMD, it calls > the broker API to register itself with the PF PMD and to get it's context > configured which includes the setting up of it's context and ops function > handlers. > > As the port representor model is based around the paradigm of using standard > port based APIs, it will allow future expansion of functionality without the > need to add new APIs. For example it should be possible to support configuration > of egress QoS parameters using existing TM APIs by extending the port > representor PMD/broker infrastructure. > > Changes in v2: > * Rebased to DPDK 17.11 > > Changes in v3: > * Removed RTE_ETH_DEV_REPRESENTOR_PORT define > * Removed switch_domain from struct rte_eth_dev_info > (to be reintroduced seperately when required). > * Port Representor PMD functionality merged into main library > * Removed functions from .map file that are not for use by applications > * Some minor bugfixes (uninitalised variables & NULL terminators) > * Use of SPDX licence headers in new files > * Seperate headers for PMD and application > * SPDX-License-Identifier in new files > * Added test-pmd representor add/del commands > > Changes in v4: > * Added documentation > * Rebased to a12f22678915 > > > Remy Horton (5): > lib: add Port Representor library > eal: add Port Representor command-line option > drivers/net/i40e: add Port Representor functionality > drivers/net/ixgbe: add Port Representor functionality > app/test-pmd: add Port Representor commands > > MAINTAINERS | 12 +- > app/test-pmd/cmdline.c | 88 ++++ > config/common_base | 5 + > doc/api/doxy-api-index.md | 3 +- > 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 | 9 + > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 25 ++ > drivers/net/i40e/Makefile | 1 + > drivers/net/i40e/i40e_ethdev.c | 16 + > drivers/net/i40e/i40e_ethdev.h | 1 + > drivers/net/i40e/i40e_prep_ops.c | 495 +++++++++++++++++++++ > drivers/net/i40e/i40e_prep_ops.h | 15 + > drivers/net/i40e/rte_pmd_i40e.c | 47 ++ > drivers/net/i40e/rte_pmd_i40e.h | 18 + > drivers/net/ixgbe/Makefile | 1 + > drivers/net/ixgbe/ixgbe_ethdev.c | 22 +- > drivers/net/ixgbe/ixgbe_ethdev.h | 5 + > drivers/net/ixgbe/ixgbe_prep_ops.c | 259 +++++++++++ > drivers/net/ixgbe/ixgbe_prep_ops.h | 15 + > lib/Makefile | 3 + > lib/librte_eal/bsdapp/eal/eal.c | 6 + > lib/librte_eal/common/eal_common_options.c | 1 + > lib/librte_eal/common/eal_internal_cfg.h | 2 + > lib/librte_eal/common/eal_options.h | 2 + > lib/librte_eal/common/include/rte_eal.h | 8 + > lib/librte_eal/linuxapp/eal/eal.c | 9 + > lib/librte_representor/Makefile | 26 ++ > lib/librte_representor/rte_port_representor.c | 326 ++++++++++++++ > lib/librte_representor/rte_port_representor.h | 60 +++ > .../rte_port_representor_driver.h | 138 ++++++ > .../rte_port_representor_version.map | 8 + > mk/rte.app.mk | 1 + > 34 files changed, 1688 insertions(+), 3 deletions(-) > create mode 100644 doc/guides/prog_guide/representor_lib.rst > create mode 100644 drivers/net/i40e/i40e_prep_ops.c > create mode 100644 drivers/net/i40e/i40e_prep_ops.h > create mode 100644 drivers/net/ixgbe/ixgbe_prep_ops.c > create mode 100644 drivers/net/ixgbe/ixgbe_prep_ops.h > 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 > > -- > 2.9.5