Re: [dpdk-dev] [PATCH 0/2] net/softnic: sw fall-back for traffic management

[Stephen Hemminger <stephen@networkplumber.org>]

On Fri, 26 May 2017 19:11:47 +0100
Jasvinder Singh <jasvinder.singh@intel.com> 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?