From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by dpdk.org (Postfix) with ESMTP id 2922116829 for ; Thu, 7 Sep 2017 12:01:20 +0200 (CEST) Received: by mail-oi0-f52.google.com with SMTP id x190so40176179oix.3 for ; Thu, 07 Sep 2017 03:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rgFrIne/Psbw6/Go72xh4poSWFXR3xC0lkQbMtEjISc=; b=M+DHJRvOSkDklYWjmzEXxMu2M3QtrX8xJuF4HYr9KVQdC+si9Cf+0dTGQFaR9UXpXj C2PxmQymOdQD945iujr0OmMfKhoP0876Jghr41LGgrM6PwYZA5rSIjS3vxyPMeA9Bvl/ oEmyZ/UxOmojwnrLZQloFcfU3vYVGBXTe2eTRxN3DmIk7mpLEYHfbspUanZzVmtZno7p 8fYpiWrxmJZqnl7/UySNWD54/AzKbMezN8Ga6R4wmZmyG1L5ouMqEi1OScCZ35j5HUqK UpdtxZvVNiqe4ZNKNuMmI6qi3Ixj2DQS+HmFQbTeBAsJPcAcaMnud5GzfsDv7532ppdo frtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rgFrIne/Psbw6/Go72xh4poSWFXR3xC0lkQbMtEjISc=; b=fAYBxyTvfSE4N2u6+loye0S3UJBkpk1HRaalcuKKq2vk+7LxEwLteiaboPBbPp0Cm3 c0VG2MMd6tKF4HGWoysJWc38Tl0sDbggOCej7k0m7AR/+BP1QM7aR3PgTXMTcvciujUJ OEU2ndkutr0WSeg9D1yZdG3wLod1cS2soRjvpljZfTjJnIYWh/hkox/Dj5WGiFXPqkix 4fJ0FBdGXEF+g0PfsmGNghWp2q4RGnA0g/PtKy9X5JN4DCqAuQ2rD/9B/Z2OE2ECol7s jPJIp2lazsM2W/IQ9iYOul+qN5Tf5I3TEQg8mOIQqYFujxg18UqKRav4ASeEEJgMeBlc FCnw== X-Gm-Message-State: AHPjjUgUryRiY4pxxoluB4MNxaEJNPaEWbgB7KWvSVF0cFK5ureSHCtU GIQ9ErqRnP4efJELvtsOnAjhNDcosHST X-Google-Smtp-Source: ADKCNb6YqBR7/fWnQTQw4Q5dTw7smZBrGlSXNbOyHAdEBzzIp1+UfJs2fQHE04oO71e+7QTz4GYuPeHODKFll/KsS1w= X-Received: by 10.202.107.80 with SMTP id g77mr2484427oic.269.1504778479262; Thu, 07 Sep 2017 03:01:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.33.212 with HTTP; Thu, 7 Sep 2017 03:01:18 -0700 (PDT) In-Reply-To: <1504773339-21022-1-git-send-email-mohammad.abdul.awal@intel.com> References: <1504773339-21022-1-git-send-email-mohammad.abdul.awal@intel.com> From: Alejandro Lucero Date: Thu, 7 Sep 2017 11:01:18 +0100 Message-ID: To: Mohammad Abdul Awal Cc: dev , Remy Horton , Declan Doherty Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [RFC 0/5] Port Representor for control and monitoring of VF devices 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, 07 Sep 2017 10:01:20 -0000 I understand this is the representor idea suiting Intel cards but it does not cover other possibilities. At least, Netronome and Mellanox require a representor not just for controlling a VF, but also for sending and receiving packets through the representor PMD. I sent an abstract for a presentation in next Dublin Users meeting, and discussing the representor idea was in the agenda. By the way, I remember there was reticence about adding control plane to DPDK. What is the current official DPDK position in this regard? On Thu, Sep 7, 2017 at 9:35 AM, Mohammad Abdul Awal < mohammad.abdul.awal@intel.com> wrote: > Signed-off-by: Mohammad Abdul Awal > Signed-off-by: Remy Horton > Signed-off-by: Declan Doherty > --- > This RFC introduces a port representor based model for the control, > management > and monitoring of SR-IOV virtual function (VF) devices for control plane > applications which have bound the devices physical function. > > Port Representors are virtual poll mode drivers (PMD) which provide a > logical > representation in DPDK for VF ports for control and monitoring. Each port > representor PMD 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 | | > | +--------+ | > +--------------------------------+ > > 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. > > Mohammad Abdul Awal (5): > Implemented port representor broker infrastructure, created BDF to > port function. > added --enable-representor command line argument in EAL to load > representor broker infrastructure. > Implement port representor PMD > Enable port representor PMD and broker for fortville PMD driver > Enable port representor PMD and broker for ixgbe PMD driver. > > config/common_base | 5 + > drivers/net/Makefile | 2 + > drivers/net/i40e/Makefile | 1 + > drivers/net/i40e/i40e_ethdev.c | 17 + > drivers/net/i40e/i40e_prep_ops.c | 402 +++++++++ > drivers/net/i40e/i40e_prep_ops.h | 41 + > drivers/net/i40e/rte_pmd_i40e.c | 47 + > drivers/net/i40e/rte_pmd_i40e.h | 18 + > drivers/net/ixgbe/Makefile | 2 +- > drivers/net/ixgbe/ixgbe_ethdev.c | 33 +- > drivers/net/ixgbe/ixgbe_ethdev.h | 11 + > drivers/net/ixgbe/ixgbe_prep_ops.c | 279 ++++++ > drivers/net/ixgbe/ixgbe_prep_ops.h | 41 + > drivers/net/representor/Makefile | 51 ++ > drivers/net/representor/rte_eth_representor.c | 973 > +++++++++++++++++++++ > .../representor/rte_pmd_representor_version.map | 4 + > 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_ether/Makefile | 2 + > lib/librte_ether/rte_ethdev.c | 93 ++ > lib/librte_ether/rte_ethdev.h | 26 + > lib/librte_ether/rte_ethdev_vdev.h | 37 +- > lib/librte_ether/rte_ether_version.map | 9 + > lib/librte_ether/rte_port_representor.c | 160 ++++ > lib/librte_ether/rte_port_representor.h | 289 ++++++ > mk/rte.app.mk | 1 + > 30 files changed, 2556 insertions(+), 16 deletions(-) > 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 drivers/net/representor/Makefile > create mode 100644 drivers/net/representor/rte_eth_representor.c > create mode 100644 drivers/net/representor/rte_ > pmd_representor_version.map > create mode 100644 lib/librte_ether/rte_port_representor.c > create mode 100644 lib/librte_ether/rte_port_representor.h > > -- > 2.7.4 > >