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

Alex Rosenbaum rosenbaumalex at gmail.com
Thu Dec 21 15:51:05 CET 2017

Declan, Mohammad,

The submission [1] 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 [2], 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
[1], port ACL's to block/allow traffic, VST/VGT modes and anti
spoofing, link trust mode [3] for promiscuous configuration, mirroring
of switch port traffic, and Tx and Rx of switch port traffic to/from
VF's port.

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
inter-port actions.

[1] http://dpdk.org/dev/patchwork/patch/32550/
[2] https://www.spinics.net/lists/netdev/msg467375.html
[2] https://www.systutorials.com/docs/linux/man/8-ip-link/


More information about the dev mailing list