[dpdk-dev] [RFC 0/5] Port Representor for control and monitoring of VF devices
rosenbaumalex at gmail.com
Thu Dec 21 15:51:05 CET 2017
The submission  of steering action between switch ports clearly
requires a switch model in DPDK.
The Port Representor based on a virtual PMD broker on NIC ops
(rte_dev_ops) does not provide the required functionality. Using NIC
terminology and not Switch API's will lead to a dead-end. Moreover, it
does not fit the Kernel design. We need to be careful from this ending
up as two different deployment models for users, which is very bad.
There was a long discussion about this in netdev ML , including the
VEPA mode support.
As described in the links Alejandro referenced earlier, each of the
switch ports should be a real PMD, and switch operations should be
applied on these PMD ports.
This includes the steering redirection of traffic between switch ports
, port ACL's to block/allow traffic, VST/VGT modes and anti
spoofing, link trust mode  for promiscuous configuration, mirroring
of switch port traffic, and Tx and Rx of switch port traffic to/from
More over, building this as real PMD ports of a switch device removes
the need to add a new broker framework all together.
Each vendor just needs to map additional PMD ports during the probing
stage. By adding a switchdev_id we can define these are ports
associated to the same switching device, and can allow new port and
More information about the dev