Re: [dpdk-dev] [RFC 0/5] Port Representor for control and monitoring of VF devices

[Alejandro Lucero <alejandro.lucero@netronome.com>]

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 <mohammad.abdul.awal@intel.com>
> Signed-off-by: Remy Horton <remy.horton@intel.com>
> Signed-off-by: Declan Doherty <declan.doherty@intel.com>
> ---
> 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
>
>