Thread (75 messages) 75 messages, 10 authors, 2018-01-30

Re: [DPDK 0/5] lib: add Port Representors

From: Neil Horman <nhorman@tuxdriver.com>
Date: 2017-12-22 16:37:47

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help