On Fri, 26 May 2017 19:11:47 +0100
Jasvinder Singh [off-list ref] wrote:

The SoftNIC PMD provides SW fall-back option for the NICs not supporting
the Traffic Management (TM) features. 

SoftNIC PMD overview:
- The SW fall-back is based on the existing librte_sched DPDK library.
- The TM-agnostic port (the underlay device) is wrapped into a TM-aware
  softnic port (the overlay device).
- Once the overlay device (virtual device) is created, the configuration of
  the underlay device is taking place through the overlay device.
- The SoftNIC PMD is generic, i.e. it works for any underlay device PMD that
  implements the ethdev API.

  Similarly to Ring PMD, the SoftNIC virtual device can be created in two
different ways:
1. Through EAL command line (--vdev option)_
2._Through the rte_eth_softnic_create() API function called by the application

SoftNIC PMD params:
- iface (mandatory): the ethdev port name (i.e. PCI address or vdev name) for
the underlay device
- txq_id (optional, default = 0): tx queue id of the underlay device
- deq_bsz (optional, default = 24): traffic manager dequeue burst size
- Example:_ --vdev 'net_softnic0,iface=0000:04:00.1,txq_id=0,deq_bsz=28'

SoftNIC PMD build instructions:
- To build SoftNIC PMD, the following parameter needs to be set on
config/common_base file: CONFIG_RTE_LIBRTE_PMD_SOFTNIC=y
- The SoftNIC PMD depends on the TM API [1] and therefore is initially
targeted for the tm-next repository


Patch 1 adds softnic device PMD for traffic management.
Patch 2 adds traffic management ops to the softnic device suggested in
generic ethdev API for traffic management[1].

[1] TM API version 4:_ 
http://www.dpdk.org/dev/patchwork/patch/24411/,
http://www.dpdk.org/dev/patchwork/patch/24412/


Jasvinder Singh (2):
  net/softnic: add softnic PMD for traffic management
  net/softnic: add traffic management ops

 MAINTAINERS                                     |    5 +
 config/common_base                              |    5 +
 drivers/net/Makefile                            |    5 +
 drivers/net/softnic/Makefile                    |   58 ++
 drivers/net/softnic/rte_eth_softnic.c           |  578 ++++++++++++
 drivers/net/softnic/rte_eth_softnic.h           |   99 ++
 drivers/net/softnic/rte_eth_softnic_default.c   | 1104 +++++++++++++++++++++++
 drivers/net/softnic/rte_eth_softnic_internals.h |   93 ++
 drivers/net/softnic/rte_eth_softnic_tm.c        |  235 +++++
 drivers/net/softnic/rte_eth_softnic_version.map |    7 +
 mk/rte.app.mk                                   |    5 +-
 11 files changed, 2193 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/softnic/Makefile
 create mode 100644 drivers/net/softnic/rte_eth_softnic.c
 create mode 100644 drivers/net/softnic/rte_eth_softnic.h
 create mode 100644 drivers/net/softnic/rte_eth_softnic_default.c
 create mode 100644 drivers/net/softnic/rte_eth_softnic_internals.h
 create mode 100644 drivers/net/softnic/rte_eth_softnic_tm.c
 create mode 100644 drivers/net/softnic/rte_eth_softnic_version.map

Setting up a softnic plus hardware NIC is significantly more effort for applications
than just using ethdev. Also, it puts the burden on the application to decide which
hardware device needs softnic and which does not; putting hardware knowledge in the
application is the wrong architectural direction.

Why not just the simple method of putting an new field in ethdev_ops for TM.
If it is NULL, then rte_ethdev TM would just fallback to doing the SoftNIC processing?

Also, eth_dev_ops doesn't always have to be const. Aren't there some PMD's that
insert different values based on configuration or CPU?