From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 0341A1B410 for ; Fri, 22 Dec 2017 17:37:47 +0100 (CET) Received: from cpe-2606-a000-111b-423c-e874-da8e-c543-d863.dyn6.twc.com ([2606:a000:111b:423c:e874:da8e:c543:d863] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1eSQKM-0005Fb-CI; Fri, 22 Dec 2017 11:37:44 -0500 Date: Fri, 22 Dec 2017 11:37:04 -0500 From: Neil Horman To: Remy Horton Cc: dev@dpdk.org, Wenzhuo Lu , Jingjing Wu Message-ID: <20171222163704.GB1222@hmswarspite.think-freely.org> References: <1510929733-7225-1-git-send-email-mohammad.abdul.awal@intel.com> <20171222144121.10041-1-remy.horton@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171222144121.10041-1-remy.horton@intel.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [DPDK 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: Fri, 22 Dec 2017 16:37:47 -0000 On Fri, Dec 22, 2017 at 02:41:16PM +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. > > +-----------------------------+ +---------------+ +---------------+ > | 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 | | > | +--------+ | > +--------------------------------+ > How does this mesh with the notion of port ownership that we've been discussing in other threads? In that thread, we've been discussing the need for a single execution context to have exclusive access to the hardware for the purposes of configuration and data i/o, and for the application/execution context to be responsible for co-ordination of any shared use of a device. In this feature however, the notion of a Port Representor creates an alias to the same hardware funciton (VF), where both aliases (in the control and data plan) have parallel access to the hardware, in such a way that co-ordination between the two is largely impossible (unless you want to make the data plane application explicity aware of control plane actiivy). Neil