dpdk.git
4 years agocommon/sfc_efx/base: handle normal events in extended width
Andy Moreton [Thu, 24 Sep 2020 12:12:33 +0000 (13:12 +0100)]
common/sfc_efx/base: handle normal events in extended width

Process the encasulated events as for the normal event loop. The phase
bit in the encapsulated event should be ignored, as the polling loop
uses the phase bit from the extended-width event.

Signed-off-by: Andy Moreton <amoreton@xilinx.com>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
4 years agocommon/sfc_efx/base: poll extended width event queues
Andy Moreton [Thu, 24 Sep 2020 12:12:32 +0000 (13:12 +0100)]
common/sfc_efx/base: poll extended width event queues

Extended width queues use a different layout and so require
a different polling loop.

Signed-off-by: Andy Moreton <amoreton@xilinx.com>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
4 years agocommon/sfc_efx/base: support creation of extended width EvQ
Andy Moreton [Thu, 24 Sep 2020 12:12:31 +0000 (13:12 +0100)]
common/sfc_efx/base: support creation of extended width EvQ

Add a flag to request an extended width event queue, and
check that the supplied buffer is large enough to hold the
event queue descriptors.

Signed-off-by: Andy Moreton <amoreton@xilinx.com>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
4 years agocommon/sfc_efx/base: add 256-bit type
Andy Moreton [Thu, 24 Sep 2020 12:12:30 +0000 (13:12 +0100)]
common/sfc_efx/base: add 256-bit type

EF100 requires support for extended-width event descriptors
for use with descriptor proxy queues. Extend libefx types
used for hardware access (and endian conversion) to support
a 256bit data type.

Signed-off-by: Andy Moreton <amoreton@xilinx.com>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
4 years agocommon/sfc_efx/base: add option for extended width events
Andy Moreton [Thu, 24 Sep 2020 12:12:29 +0000 (13:12 +0100)]
common/sfc_efx/base: add option for extended width events

EF100 uses event queues with 256bit extended width events to
support descriptor proxy queues.

Signed-off-by: Andy Moreton <amoreton@xilinx.com>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
4 years agocommon/sfc_efx/base: allocate vAdaptor on Riverhead
Andrew Rybchenko [Thu, 24 Sep 2020 12:12:28 +0000 (13:12 +0100)]
common/sfc_efx/base: allocate vAdaptor on Riverhead

Riverhead has EVB support similar to EF10 and NIC must allocate
its vAdaptor on init.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: use EF10 EVB methods for Riverhead
Andrew Rybchenko [Thu, 24 Sep 2020 12:12:27 +0000 (13:12 +0100)]
common/sfc_efx/base: use EF10 EVB methods for Riverhead

There is no difference yet in EVB support on EF10 and Riverhead.
So, it is better to reuse existing methods.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: replace PCI efsys macros with functions
Igor Romanov [Thu, 24 Sep 2020 12:12:26 +0000 (13:12 +0100)]
common/sfc_efx/base: replace PCI efsys macros with functions

efsys macros that manipulate PCI devices cannot be defined in
common sfc_efx DPDK driver since in DPDK build the bus drivers
that provide required functionality are built after common drivers.

Replace the macros with function callbacks to remove that build
dependency. Drivers now should pass the callbacks directly to
efx function instead of defining implementation in efsys.

Signed-off-by: Igor Romanov <igor.romanov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: support UDP tunnel operations for EF100
Igor Romanov [Thu, 24 Sep 2020 12:12:25 +0000 (13:12 +0100)]
common/sfc_efx/base: support UDP tunnel operations for EF100

EF100 uses VNIC encapsulation rule MCDI for configuring UDP
tunnels in HW individually. Use busy added and removed states
of UDP tunnel table entries for the implementation.

Signed-off-by: Igor Romanov <igor.romanov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: introduce states for UDP tunnel entries
Igor Romanov [Thu, 24 Sep 2020 12:12:24 +0000 (13:12 +0100)]
common/sfc_efx/base: introduce states for UDP tunnel entries

UDP tunnel reconfigure operation takes UDP tunnel table, which contains
entries that need to be applied to HW. This approach does not retain
information about what entries were removed or added, which is required
for Riverhead.

Add states to the table entries to indicate add or remove operations.
On tunnel reconfiguration added and removed entries become busy to
indicate that the entries are currently configured and to prevent add or
remove operations from other threads. After tunnel reconfiguration is
complete, the states are reset - added entries become applied and
removed entries are purged from the table.

Signed-off-by: Igor Romanov <igor.romanov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: introduce UDP tunnel destruct operation
Igor Romanov [Thu, 24 Sep 2020 12:12:23 +0000 (13:12 +0100)]
common/sfc_efx/base: introduce UDP tunnel destruct operation

The procedures for destroying UDP tunnels are NIC family specific,
so they should be implemented separately for each of them.

Check for supported UDP encapsulation is removed from generic
operations since it is no longer used by the generic libefx API.

Signed-off-by: Igor Romanov <igor.romanov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: add NIC magic check on BAR lookup
Igor Romanov [Thu, 24 Sep 2020 12:12:22 +0000 (13:12 +0100)]
common/sfc_efx/base: add NIC magic check on BAR lookup

Check that BAR lookup was successful by looking at the content
of signature register.

Signed-off-by: Igor Romanov <igor.romanov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: add Xilinx capabilities table lookup
Igor Romanov [Thu, 24 Sep 2020 12:12:21 +0000 (13:12 +0100)]
common/sfc_efx/base: add Xilinx capabilities table lookup

APIs for searching a capability in a Xilinx capabilities table and
reading table entries are needed for function control window lookup
to get the bar index and offset of the window.

Signed-off-by: Igor Romanov <igor.romanov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: add efsys API to find a memory BAR
Igor Romanov [Thu, 24 Sep 2020 12:12:20 +0000 (13:12 +0100)]
common/sfc_efx/base: add efsys API to find a memory BAR

Function control window lookup needs memory BARs handles to
search Xilinx capabilities tables.

Define an API to get a memory BAR handle by a PCIe device handle and
BAR index.

Signed-off-by: Igor Romanov <igor.romanov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: add function control window lookup API
Igor Romanov [Thu, 24 Sep 2020 12:12:19 +0000 (13:12 +0100)]
common/sfc_efx/base: add function control window lookup API

Riverhead NIC may provide a locator of function control window
(EF100 resource locator).
The locator may be present in a Xilinx capabilities table which
itself is located by looking into extended PCI capabilities.

PCI capabilities are made possible to access by adding PCI config
space interface to efsys.

APIs are implemented to facilitate function control window lookup:
 - API to find an extended PCI capability given a capability ID;
 - API to read Xilinx PCI capability;

Signed-off-by: Igor Romanov <igor.romanov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: add function control window concept
Igor Romanov [Thu, 24 Sep 2020 12:12:18 +0000 (13:12 +0100)]
common/sfc_efx/base: add function control window concept

Function control window can be located at a different offset than
other windows on Riverhead. Meaning that the drivers must handle
accesses to the function control window differently in case of EF100.

Add accessor macros for function control window and change
EFX NIC create API to facilitate that accessors.

Signed-off-by: Igor Romanov <igor.romanov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: choose smallest Rx prefix on Riverhead
Andrew Rybchenko [Thu, 24 Sep 2020 12:12:17 +0000 (13:12 +0100)]
common/sfc_efx/base: choose smallest Rx prefix on Riverhead

Riverhead supports many Rx prefixes. The Rx prefix may be chosen
based on which information is required.

To have better performance choose the smallest Rx prefix which
meets our requirements.

Right now there is no way to specify requirements on Rx queue
creation, but it could be added in the future.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: group RxQ parameters into a structure
Andrew Rybchenko [Thu, 24 Sep 2020 12:12:16 +0000 (13:12 +0100)]
common/sfc_efx/base: group RxQ parameters into a structure

Make number of efx_mcdi_init_rxq() arguments reasonable before
addition of one more argument.
Non essential parameters not supported in some cases are moved
into helper structure.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: add API to get Rx prefix information
Andrew Rybchenko [Thu, 24 Sep 2020 12:12:15 +0000 (13:12 +0100)]
common/sfc_efx/base: add API to get Rx prefix information

Define default Siena, EF10 default, packed stream, equal-stride
superbuffer and Riverhead default prefixes in order to make an API
to get Rx prefix layout information generic and usable on all NICs.

Riverhead supports many Rx prefixes. Riverhead FW supports MCDI to
choose Rx prefix based on required Rx prefix fields and allows to
query the prefix layout using MCDI. The patch prepares to introduce
the support in libefx and provides fallback for NICs and FW which
lacks the support.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx: do not include libefx headers from efsys.h
Andrew Rybchenko [Thu, 24 Sep 2020 12:12:14 +0000 (13:12 +0100)]
common/sfc_efx: do not include libefx headers from efsys.h

efsys.h may depends on target system headers only. Otherwise, it could
result in cross-dependency when libefx header depends on efsys.h and
efsys.h depends on the libefx header.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andrew Lee <andrewle@xilinx.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: report restrictions for TSO version 3
Ivan Malov [Thu, 24 Sep 2020 12:12:13 +0000 (13:12 +0100)]
common/sfc_efx/base: report restrictions for TSO version 3

Riverhead puts a number of restrictions on TSO transactions.
Reflect some of them in the NIC configuration structure.

Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andrew Lee <andrewle@xilinx.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: indicate support for TSO version 3
Ivan Malov [Thu, 24 Sep 2020 12:12:12 +0000 (13:12 +0100)]
common/sfc_efx/base: indicate support for TSO version 3

Riverhead boards support TSO version 3.

Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andrew Lee <andrewle@xilinx.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: handle Tx complete on Riverhead
Andrew Rybchenko [Thu, 24 Sep 2020 12:12:11 +0000 (13:12 +0100)]
common/sfc_efx/base: handle Tx complete on Riverhead

Introduce a new event callback which has the same prototype, but
provides number of completed descriptors instead of the last
completed descriptor index.

When all libefx-based drivers implement the new callback, libefx
may be updated to use it for Siena and EF10 family NICs and
the old one may be removed.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: handle Rx events for Riverhead
Andrew Rybchenko [Thu, 24 Sep 2020 12:12:10 +0000 (13:12 +0100)]
common/sfc_efx/base: handle Rx events for Riverhead

Rx event on Riverhead provides a number of received packets and
no classification/offloads information is available Rx event.

Introduce a new event callback to be implemented by drivers.
The callback provides information about the number of completed
packets. libefx-based drivers should implement the new callback
for Riverhead and keep the old one for Siena and EF10 NICs.
The new callback may be used for Medford2 NO_CONT_EV Rx mode
support.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: fix Tx descriptor DMA sync on Riverhead
Andrew Rybchenko [Thu, 24 Sep 2020 12:12:09 +0000 (13:12 +0100)]
common/sfc_efx/base: fix Tx descriptor DMA sync on Riverhead

Rx/Tx queue DMA sync should not assume descriptor size to be the same
for all NIC familties since it Tx descritor size is 16 on Riverhead.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: implement Tx control path for Riverhead
Andrew Rybchenko [Thu, 24 Sep 2020 12:12:08 +0000 (13:12 +0100)]
common/sfc_efx/base: implement Tx control path for Riverhead

Tx control path on Riverhead is very similar to EF10, but datapath
differs a lot since Tx descriptor size is 16 bytes (vs 8 bytes on EF10).

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: implement Rx control path for Riverhead
Andrew Rybchenko [Thu, 24 Sep 2020 12:12:07 +0000 (13:12 +0100)]
common/sfc_efx/base: implement Rx control path for Riverhead

Reuse EF10 RSS-related functions since current version of the RSS
interface is compatible with EF10.

Implement own functions to create and destroy Rx queues which reuse
MCDI wrappers which are shared with EF10.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: move Rx index check to generic code
Andrew Rybchenko [Thu, 24 Sep 2020 12:12:06 +0000 (13:12 +0100)]
common/sfc_efx/base: move Rx index check to generic code

Make NIC family specific functions a bit shorter and reduce
code duplication.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: free Rx queue structure in generic code
Andrew Rybchenko [Thu, 24 Sep 2020 12:12:05 +0000 (13:12 +0100)]
common/sfc_efx/base: free Rx queue structure in generic code

Rx queue structure is allocated in generic code, but was freed in NIC
family specific callbacks. Move free to generic function makes NIC
family specific callbacks shorter and reduces code duplication.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: maintain RxQ counter in generic code
Andrew Rybchenko [Thu, 24 Sep 2020 12:12:04 +0000 (13:12 +0100)]
common/sfc_efx/base: maintain RxQ counter in generic code

The counter is incremented in generic efx_rx_qcreate(), but was
asserted and decremented in NIC family specific queue create and
destroy callbacks.  Move assert and decrement to generic functions
as well to make NIC family specific callbacks shorter.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: switch TxQ init to extended version
Andrew Rybchenko [Thu, 24 Sep 2020 12:12:03 +0000 (13:12 +0100)]
common/sfc_efx/base: switch TxQ init to extended version

Extended version of MCDI allows up to 64 DMA addresses which are
required for Riverhead.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: move TxQ init/fini wrappers to generic
Andrew Rybchenko [Thu, 24 Sep 2020 12:12:02 +0000 (13:12 +0100)]
common/sfc_efx/base: move TxQ init/fini wrappers to generic

TxQ init/fini MCDI is similar on Riverhead and these
functions should be reused to implement TxQ creation and
destruction on Riverhead.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
Reviewed-by: Vijay Kumar Srivastava <vsrivast@xilinx.com>
4 years agocommon/sfc_efx/base: move RxQ init/fini wrappers to generic
Andrew Rybchenko [Thu, 24 Sep 2020 12:12:01 +0000 (13:12 +0100)]
common/sfc_efx/base: move RxQ init/fini wrappers to generic

RxQ init/fini MCDI is similar on Riverhead and these
functions should be reused to implement RxQ creation and
destruction on Riverhead.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: handle MCDI events on Riverhead
Andrew Rybchenko [Thu, 24 Sep 2020 12:12:00 +0000 (13:12 +0100)]
common/sfc_efx/base: handle MCDI events on Riverhead

EF100 MCDI event layout is same as on EF10 except added QDMA phase
bit which is unused on EF10.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: complete EvQ creation on Riverhead
Ivan Malov [Thu, 24 Sep 2020 12:11:59 +0000 (13:11 +0100)]
common/sfc_efx/base: complete EvQ creation on Riverhead

Client drivers relying on interrupts will fail to complete event
queue creation on Riverhead boards as the latter have no support
for INIT_DONE events which means that it's useless to wait until
initialisation callback is triggered by interrupt-driven polling.

Client drivers which avoid interrupt-driven polling still handle
INIT_DONE events by direct polling and will fail to do so.

Solve this problem by adding an extra poll-once method which
will be called by client drivers after queue creation (probably,
with driver-specific lock being held). The method will invoke
initialisation callback on Riverhead and do nothing on the other
boards. Then the drivers will proceed with normal waiting which
will complete immediately in the case of Riverhead.

Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: add event queue module for Riverhead
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:58 +0000 (13:11 +0100)]
common/sfc_efx/base: add event queue module for Riverhead

Events are significantly reworked on Riverhead, so it is better
to implement own set of callbacks to simplify future development
and avoid inheritance of legacy code.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: merge versions of init EvQ wrappers
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:57 +0000 (13:11 +0100)]
common/sfc_efx/base: merge versions of init EvQ wrappers

The decision on which version of the INIT_EVQ command to use may
be done inside the function itself. Caller should just provide
enough information sufficient in both cases. It avoids code
duplication and simplifies maintenance.

If v2 is not supported, keep decision about low-latency hint outside
the MCDI helper function since it will differ on Riverhead (there is
no EVB yet, but still want merging for better throughput).

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: prepare to merge EvQ init functions
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:56 +0000 (13:11 +0100)]
common/sfc_efx/base: prepare to merge EvQ init functions

v1 and v2 defines are the same except output length.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: move EvQ create generic checks
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:55 +0000 (13:11 +0100)]
common/sfc_efx/base: move EvQ create generic checks

There is no point to duplicate these generic checks in NIC family
specific handlers.

As the side effect it fixes bug with incorrect interrupt moderation
settings silently ignored on event queue create on Siena.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
Reviewed-by: Vijay Kumar Srivastava <vsrivast@xilinx.com>
4 years agocommon/sfc_efx/base: move EvQ init/fini wrappers to generic
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:54 +0000 (13:11 +0100)]
common/sfc_efx/base: move EvQ init/fini wrappers to generic

EvQ init/fini MCDI is similar on Riverhead and these
functions should be reused to implement EvQ creation and
destruction on Riverhead.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
Reviewed-by: Vijay Kumar Srivastava <vsrivast@xilinx.com>
4 years agocommon/sfc_efx/base: add interrupts module for Riverhead
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:53 +0000 (13:11 +0100)]
common/sfc_efx/base: add interrupts module for Riverhead

Riverhead supports interrupt aggregation rings. Right now there
are no plans to support it in libefx, but it is better to have
own set of callbacks to easier handle EF10 and Riverhead
differences in the future.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: use EF10 MAC methods for Riverhead
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:52 +0000 (13:11 +0100)]
common/sfc_efx/base: use EF10 MAC methods for Riverhead

There is no difference yet in MAC support on EF10 and Riverhead.
So, it is better to reuse existing methods.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
Reviewed-by: Vijay Kumar Srivastava <vsrivast@xilinx.com>
4 years agocommon/sfc_efx/base: use EF10 filter methods for Riverhead
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:51 +0000 (13:11 +0100)]
common/sfc_efx/base: use EF10 filter methods for Riverhead

Filtering MCDI on Riverhead are the same as on EF10.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
Reviewed-by: Vijay Kumar Srivastava <vsrivast@xilinx.com>
4 years agocommon/sfc_efx/base: use dummy tunnel ops for Riverhead
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:50 +0000 (13:11 +0100)]
common/sfc_efx/base: use dummy tunnel ops for Riverhead

Riverhead does not support tunnels yet.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: add Riverhead support to NIC module
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:49 +0000 (13:11 +0100)]
common/sfc_efx/base: add Riverhead support to NIC module

Define basic NIC features and limitations.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
Reviewed-by: Vijay Kumar Srivastava <vsrivast@xilinx.com>
4 years agocommon/sfc_efx/base: factor out MCDI entity reset helper
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:48 +0000 (13:11 +0100)]
common/sfc_efx/base: factor out MCDI entity reset helper

The helper will be reused on Riverhead.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: set NIC features in generic place
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:47 +0000 (13:11 +0100)]
common/sfc_efx/base: set NIC features in generic place

There is no point to duplicate it NIC family specific probe handlers.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: factor out helper to get board config
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:46 +0000 (13:11 +0100)]
common/sfc_efx/base: factor out helper to get board config

The helper will be used on Riverhead.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: remove PF count get from caps get
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:45 +0000 (13:11 +0100)]
common/sfc_efx/base: remove PF count get from caps get

ef10_get_datapath_caps() should simply fill in NIC configuration
based MC_CMD_GET_CAPABILITIES output.

Number of PFs is a part of board configuration should be obtained
in corresponding function.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: move 14b prefix check out of caps get
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:44 +0000 (13:11 +0100)]
common/sfc_efx/base: move 14b prefix check out of caps get

The function which gets capabilities from MC should simply fill in
NIC configuration. Caller should decide if the configuration is
supported or not.

The change is required to prepare the function to be reused on
Riverhead.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: use EF10 PHY methods for Riverhead
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:43 +0000 (13:11 +0100)]
common/sfc_efx/base: use EF10 PHY methods for Riverhead

There is no difference yet in PHY support on EF10 and Riverhead.
So, it is better to reuse existing methods.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
Reviewed-by: Vijay Kumar Srivastava <vsrivast@xilinx.com>
4 years agocommon/sfc_efx/base: use EF10 MCDI methods for Riverhead
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:42 +0000 (13:11 +0100)]
common/sfc_efx/base: use EF10 MCDI methods for Riverhead

MCDI on Riverhead is very close to the EF10 and there is no
point to duplicate the code.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: update registers check for Riverhead
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:41 +0000 (13:11 +0100)]
common/sfc_efx/base: update registers check for Riverhead

Riverhead family got letter 'G' for registers definition.
Registers used for Riverhead should have the letter in the
specification range.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
Reviewed-by: Vijay Kumar Srivastava <vsrivast@xilinx.com>
4 years agocommon/sfc_efx/base: add Riverhead NIC family
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:40 +0000 (13:11 +0100)]
common/sfc_efx/base: add Riverhead NIC family

Riverhead is the first NIC family of the EF100 architecture.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
Reviewed-by: Vijay Kumar Srivastava <vsrivast@xilinx.com>
4 years agocommon/sfc_efx/base: add efsys option for Riverhead
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:39 +0000 (13:11 +0100)]
common/sfc_efx/base: add efsys option for Riverhead

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
Reviewed-by: Vijay Kumar Srivastava <vsrivast@xilinx.com>
4 years agocommon/sfc_efx/base: add event queue operation to do polling
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:38 +0000 (13:11 +0100)]
common/sfc_efx/base: add event queue operation to do polling

Event queue host interface differ on Riverhead and implementation
will be different.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
4 years agocommon/sfc_efx/base: update MCDI headers
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:37 +0000 (13:11 +0100)]
common/sfc_efx/base: update MCDI headers

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
4 years agocommon/sfc_efx/base: add EF100 registers definitions
Andrew Rybchenko [Thu, 24 Sep 2020 12:11:36 +0000 (13:11 +0100)]
common/sfc_efx/base: add EF100 registers definitions

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
4 years agonet/octeontx2: support VLAN insert and strip actions
Kiran Kumar K [Mon, 24 Aug 2020 07:04:24 +0000 (12:34 +0530)]
net/octeontx2: support VLAN insert and strip actions

Adding support for RTE Flow VLAN insert and strip actions.

Signed-off-by: Kiran Kumar K <kirankumark@marvell.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
4 years agonet/octeontx2: set max VTAG insertion size
Kiran Kumar K [Fri, 21 Aug 2020 06:59:30 +0000 (12:29 +0530)]
net/octeontx2: set max VTAG insertion size

When TX side VTAG insertion is enabled, SMQ should be configured with
the maximum VTAG insertion size to avoid generating NIX_SQINT_SEND_ERR
interrupt. Since the default value is zero, This patch configures the
VTAG insertion size to the max supported value.

Signed-off-by: Kiran Kumar K <kirankumark@marvell.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
4 years agonet/qede: support VF FLR
Manish Chopra [Fri, 25 Sep 2020 11:55:08 +0000 (04:55 -0700)]
net/qede: support VF FLR

This patch adds required bit to handle VF FLR
indication from Management FW (MFW) of the device

With that VFs were able to load in VM (VF attached as PCI
passthrough to the guest VM) followed by FLR successfully

Updated the docs/guides with the feature support

Signed-off-by: Manish Chopra <manishc@marvell.com>
Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
Signed-off-by: Rasesh Mody <rmody@marvell.com>
4 years agonet/qede: initialize VF MAC and link
Manish Chopra [Fri, 25 Sep 2020 11:55:07 +0000 (04:55 -0700)]
net/qede: initialize VF MAC and link

This patch configures VFs with random mac if no MAC is
provided by the PF/bulletin. This also adds required bulletin
APIs by PF-PMD driver to communicate LINK properties/changes to
the VFs through bulletin update mechanism.

With these changes, VF-PMD instance is able to run
fastpath over PF-PMD driver instance.

Signed-off-by: Manish Chopra <manishc@marvell.com>
Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
Signed-off-by: Rasesh Mody <rmody@marvell.com>
4 years agonet/qede: add infrastructure support for VF load
Manish Chopra [Fri, 25 Sep 2020 11:55:06 +0000 (04:55 -0700)]
net/qede: add infrastructure support for VF load

This patch adds necessary infrastructure support (required to handle
messages from VF and sending ramrod on behalf of VF's configuration
request from alarm handler context) to start/load the VF-PMD driver
instance on top of PF-PMD driver instance.

Signed-off-by: Manish Chopra <manishc@marvell.com>
Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
Signed-off-by: Rasesh Mody <rmody@marvell.com>
4 years agonet/qede: configure VFs on hardware
Manish Chopra [Fri, 25 Sep 2020 11:55:05 +0000 (04:55 -0700)]
net/qede: configure VFs on hardware

Based on number of VFs enabled at PCI, PF-PMD driver instance
enables/configures those VFs from hardware perspective, such
that in later patches they could get required HW access to
communicate with PFs for slowpath configuration and run the
fastpath themselves.

This patch also add two new qede IOV files [qede_sriov(.c|.h)]
under qede directory to add non-base driver IOV APIs/contents there.

Signed-off-by: Manish Chopra <manishc@marvell.com>
Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
Signed-off-by: Rasesh Mody <rmody@marvell.com>
4 years agonet/qede: define PCI config space specific osals
Manish Chopra [Fri, 25 Sep 2020 11:55:04 +0000 (04:55 -0700)]
net/qede: define PCI config space specific osals

This patch defines various PCI config space access APIs
in order to read and find IOV specific PCI capabilities.

With these definitions implemented, it enables the base
driver to do SR-IOV specific initialization and HW specific
configuration required from PF-PMD driver instance.

Signed-off-by: Manish Chopra <manishc@marvell.com>
Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
Signed-off-by: Rasesh Mody <rmody@marvell.com>
4 years agobus/pci: query PCI extended capabilities
Manish Chopra [Fri, 25 Sep 2020 11:55:03 +0000 (04:55 -0700)]
bus/pci: query PCI extended capabilities

By adding generic API, this patch removes individual
functions/defines implemented by drivers to find extended
PCI capabilities.

Signed-off-by: Manish Chopra <manishc@marvell.com>
Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
Reviewed-by: Gaetan Rivet <grive@u256.net>
Reviewed-by: Jerin Jacob <jerinj@marvell.com>
4 years agonet/fm10k: fix memory leak when thresh check fails
Yunjian Wang [Mon, 28 Sep 2020 12:44:42 +0000 (20:44 +0800)]
net/fm10k: fix memory leak when thresh check fails

In fm10k_rx_queue_setup(), we allocate memory for the queue
structure but not released when thresh check fails.

Fixes: 6cfe8969c969 ("fm10k: add Rx queue setup/release")
Cc: stable@dpdk.org
Signed-off-by: Yunjian Wang <wangyunjian@huawei.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
4 years agonet/bnxt: fix vector mode for 32-bit x86
Lance Richardson [Fri, 25 Sep 2020 21:40:19 +0000 (17:40 -0400)]
net/bnxt: fix vector mode for 32-bit x86

Descriptor valid mask should be 64-bit all ones, use
appropriate initializer type (unsigned long long) to
obtain correct value in 32-bit mode.

Fixes: deae85145c64 ("net/bnxt: handle multiple packets per loop in vector Rx")

Signed-off-by: Lance Richardson <lance.richardson@broadcom.com>
Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
4 years agonet/octeontx2: support VLAN based RSS hash
Kiran Kumar K [Thu, 13 Aug 2020 07:22:49 +0000 (12:52 +0530)]
net/octeontx2: support VLAN based RSS hash

Adding support for VLAN based RSS hash. Two bytes of TCI field
will be considered for hashing.

Signed-off-by: Kiran Kumar K <kirankumark@marvell.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
4 years agocommon/octeontx2: fix memory mapping API usage
Sarosh Arif [Thu, 24 Sep 2020 10:39:32 +0000 (15:39 +0500)]
common/octeontx2: fix memory mapping API usage

Replace mmap() and munmap() APIs with EAL abstraction for the same.

Fixes: e1d9a02ad8f0 ("common/octeontx2: introduce common device class")
Cc: stable@dpdk.org
Signed-off-by: Sarosh Arif <sarosh.arif@emumba.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
4 years agonet/octeontx2: fix multi segment mode for jumbo packets
Harman Kalra [Mon, 10 Aug 2020 10:55:45 +0000 (16:25 +0530)]
net/octeontx2: fix multi segment mode for jumbo packets

Scatter gather mode should get enabled:
 - If mbuf size is less than max received packet length.
 - MTU is reconfigured greater than mbuf size.

Fixes: 0e2efd02db58 ("net/octeontx2: add MTU set operation")
Cc: stable@dpdk.org
Signed-off-by: Harman Kalra <hkalra@marvell.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
4 years agonet/octeontx: fix Tx preparation
Pavan Nikhilesh [Tue, 28 Jul 2020 18:43:46 +0000 (00:13 +0530)]
net/octeontx: fix Tx preparation

When building send command for a given descriptor it expects
it to contain the AURA identifier of the pool that it belongs
to rather than the pool identifier itself.

Fixes: 7f4116bdbb1c ("net/octeontx: add framework for Rx/Tx offloads")
Cc: stable@dpdk.org
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
4 years agomempool/octeontx: fix aura to pool mapping
Pavan Nikhilesh [Tue, 28 Jul 2020 18:43:45 +0000 (00:13 +0530)]
mempool/octeontx: fix aura to pool mapping

When sending commands to Kernel FPA PF driver, it expects the
aura to be in the range of 0 to 16 for a given FPA pool.
In OCTEON TX we map a pool,aura pair as single mempool handle,
always set the aura id to 0 for a given FPA pool.

Fixes: 179c7e893f64 ("mempool/octeontx: fix pool to aura mapping")
Cc: stable@dpdk.org
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
4 years agonet/hns3: fix storing RSS info when creating flow action
Wei Hu (Xavier) [Tue, 22 Sep 2020 12:03:29 +0000 (20:03 +0800)]
net/hns3: fix storing RSS info when creating flow action

Currently, when calling the rte_flow_query API function to query the RSS
information, the queue related information is not as expected.

The root cause is that when application call the rte_flow_create API
function to create RSS action, the operation of storing the data whose typs
is struct rte_flow_action_rss is incorrect in the '.create' ops
implementation function named hns3_flow_create.

This patch fixes it by replacing memcpy with hns3_rss_conf_copy function to
store the RSS information in the hns3_flow_create.

Fixes: c37ca66f2b27 ("net/hns3: support RSS")
Cc: stable@dpdk.org
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
4 years agonet/hns3: fix configuring device with RSS enabled
Wei Hu (Xavier) [Tue, 22 Sep 2020 12:03:28 +0000 (20:03 +0800)]
net/hns3: fix configuring device with RSS enabled

Currently, when running the following commands in the CLI of testpmd
application, the driver reports an -EINVAL error when performing the No.3
step.
1) flow create 0 ingress pattern end actions rss key <key> func simple_xor
     types all end / end
2) flow flush 0
3) port config dcb vt off pfc off

The root cause as below:
In the No.2 step, when RSS rules is flushed, we set the the flag
hw->rss_dis_flag with true to indicate RSS id disabled. And in the No.3
step, calling rte_eth_dev_configure API function, the internal function
named hns3_dev_rss_hash_update check hw->rss_dis_flag is true and return
-EINVAL.

When user calls the rte_eth_dev_configure API function with the input
parameter dev_conf->rxmode.mq_mode having ETH_MQ_RX_RSS_FLAG to enable RSS,
driver should set internal flag hw->rss_dis_flag with false to indicate RSS
is enabled in the '.dev_configure' ops implementation function named
hns3_dev_configure and hns3vf_dev_configure.

Fixes: 5e782bc2570c ("net/hns3: fix configuring RSS hash when rules are flushed")
Cc: stable@dpdk.org
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
4 years agonet/hns3: fix flushing RSS rule
Lijun Ou [Tue, 22 Sep 2020 12:03:27 +0000 (20:03 +0800)]
net/hns3: fix flushing RSS rule

When user create a flow without RSS by calling rte_flow_create API and then
destroy it by calling rte_flow_flush API, driver should not clear RSS rule.

A reasonable handling method is that when user creates an RSS rule, the
driver should clear the created RSS rule when flushing destroy all flow
rules. Also, hw->rss_info should save the RSS config of the last success
RSS rule. When create n RSS rules, the RSS should not be disabled before
the last RSS rule destroyed.

Fixes: c37ca66f2b27 ("net/hns3: support RSS")
Cc: stable@dpdk.org
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
4 years agonet/hns3: fix flow RSS queue number 0
Wei Hu (Xavier) [Tue, 22 Sep 2020 12:03:26 +0000 (20:03 +0800)]
net/hns3: fix flow RSS queue number 0

When user specifies RSS queue num for 0 in action list by flow create API,
it should create a valid flow rule. The following flow rule should be
success in the command line of the testpmd application:
flow create 0 <pattern> actions rss queues  / end

Fixes: c37ca66f2b27 ("net/hns3: support RSS")
Cc: stable@dpdk.org
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
4 years agonet/hns3: fix config when creating RSS rule after flush
Lijun Ou [Tue, 22 Sep 2020 12:03:25 +0000 (20:03 +0800)]
net/hns3: fix config when creating RSS rule after flush

Currnetly, when user create a flow RSS rule and then flush the rule, driver
will set 0 for the internal structure of hw->rss_info maintained in driver.
And then user create a flow RSS rule without specified RSS hash key, driver
configure a validate RSS hash key into hardware network engine and will
cause an RSS error. The related steps when using testpmd as
follows:
  flow 0 <pattern> action rss xx end / end
  flow flush 0
  flow 0 <pattern> action rss queues 0 1 end / end

To slove the preceding problem, the flow flush processing is modified.
it don't clear all RSS configurations for hw->rss_info. Actually the RSS
key information in the hardware is not cleared, therefore, the
hw->rss_info.key is kept consistent with the value in the hardware. In
addition, because reset the redirection table, we need to set queues NULL
and queue_num for zero that indicate the corresponding parameters in the
hardware is unavailable. Also we set hw->rss_info.func to
RTE_ETH_HASH_FUNCTION_MAX that indicate it is invalid.

Fixes: c37ca66f2b27 ("net/hns3: support RSS")
Cc: stable@dpdk.org
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
4 years agonet/hns3: set RSS hash type input configuration
Lijun Ou [Tue, 22 Sep 2020 12:03:24 +0000 (20:03 +0800)]
net/hns3: set RSS hash type input configuration

This patch support for hash type input set configuration. That is, upper
level application can call the rte_flow_create or
rte_eth_dev_rss_hash_update API to set the specified tuples by RSS types.
As a result, the hardware can selectively use the tuples to perform hash
calculation based on the specific tuple to enable the fields.
The following uses the RSS flow as an example:

When application calls the rte_flow_create API to select tuple input for
ipv4-tcp l3-src-only, the driver can enable the ipv4-tcp src field of the
hardware register by calling the internal function named
hns3_set_rss_tuple_by_rss_hf according to the RSS types in actions list.
In testpmd application, the command as follows:
testpmd> flow create 0 ingress pattern end actions rss types \
ipv4-tcp l3-src-only end queues 1 3 end / end

The following use the rte_eth_dev_rss_hash_update as an example:
if the user set the select tuple input for ipv4-tcp l3-src-only by
rte_eth_rss_conf structure in rte_eth_dev_rss_hash_update. the next
flow is the same as that of the RSS flow. In testpmd application,
the command as follows:
testpmd> port config all rss ipv4-tcp l3-src-only

Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
4 years agonet/hns3: check input RSS type when creating flow with RSS
Lijun Ou [Tue, 22 Sep 2020 12:03:23 +0000 (20:03 +0800)]
net/hns3: check input RSS type when creating flow with RSS

This patch adds checking the input RSS type when creating a flow with RSS.
If the input RSS type are not supported based on hns3 network engine, an
error is returned.

Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
4 years agonet/hns3: support querying RSS flow rule
Lijun Ou [Tue, 22 Sep 2020 12:03:22 +0000 (20:03 +0800)]
net/hns3: support querying RSS flow rule

This patch enables to query some RSS configurations of the specified
rule. For example, show RSS hash function and rss types.

Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
4 years agonet/hns3: support flow action of queue region
Chengwen Feng [Tue, 22 Sep 2020 12:03:21 +0000 (20:03 +0800)]
net/hns3: support flow action of queue region

Kunpeng 930 hardware support spread packets to region of queues which can
be configured by FDIR rule, it means user can create one FDIR rule which
action is one region of queues, and then RSS use the region info to spread
packets.

As we know, RTE_FLOW_ACTION_TYPE_RSS is used to spread packets among
several queues, user could config such as func/level/types/key/queue
parameter to control RSS function, so we provide this feature under the
RTE_FLOW_ACTION_TYPE_RSS framework.

Consider RSS input tuple don't have eth header, we use the following
rule to distinguish them (whether it's queue region configuration or
rss general configuration):
Case 1: pattern have ETH and action's queue_num > 0, indicate it is
queue region configuration.
Case other: rss general configuration.

So if user want to configure one flow which ipv4=192.168.1.192 spread to
queue region of queue 0/1/2/3, the patter should:
  RTE_FLOW_ITEM_TYPE_ETH with spec=last=mask=NULL
  RTE_FLOW_ITEM_TYPE_IPV4 with spec=192.168.1.192 last=mask=NULL
  RTE_FLOW_ITEM_TYPE_END
the action should:
  RTE_FLOW_ACTION_TYPE_RSS with queue_num=4 queue=0/1/2/3
  RTE_FLOW_ACTION_TYPE_END
after calling rte_flow_create, one FDIR rule will be created.

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
4 years agonet/hns3: break loop in adding error stats
Hongbo Zheng [Tue, 22 Sep 2020 12:03:20 +0000 (20:03 +0800)]
net/hns3: break loop in adding error stats

This patch solves the redundant operation during traversal. In the internal
function named hns3_error_int_stats_add for adding error statistics,
because only one statistical item will be found in the for loop statement,
a break can be executed after finding the error statistical item without
traversing the remaining table entries.

Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
4 years agonet/hns3: add default to switch when parsing fd tuple
Wei Hu (Xavier) [Tue, 22 Sep 2020 12:03:19 +0000 (20:03 +0800)]
net/hns3: add default to switch when parsing fd tuple

This patch solves the static check warning in the internal function named
hns3_fd_convert_tuple as follow:
    "The switch statement must have a 'default' branch".

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
4 years agonet/hns3: skip VF register access when PF in FLR
Hongbo Zheng [Tue, 22 Sep 2020 12:03:18 +0000 (20:03 +0800)]
net/hns3: skip VF register access when PF in FLR

According to the protocol of PCIe, FLR to a PF device resets the PF state
as well as the SR-IOV extended capability including VF Enable which means
that VFs no longer exist.

When PF device is in FLR reset stage, at this time, the register state
of VF device is not reliable, so VF device's register state detection
is not carried out in PF FLR.

In this case, we just ignore the register states to avoid accessing
nonexistent register and return false in the internal function named
hns3vf_is_reset_pending to indicate that there are no other reset states
that need to be processed by PMD driver.

Fixes: 2790c6464725 ("net/hns3: support device reset")
Cc: stable@dpdk.org
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
4 years agonet/hns3: add TSO pseudo header calculation compatibility
Wei Hu (Xavier) [Tue, 22 Sep 2020 12:03:17 +0000 (20:03 +0800)]
net/hns3: add TSO pseudo header calculation compatibility

In kunpeng 920, when process pkts which need TSO, the network driver
need to erase the L4 len value of the TCP TSO pseudo header and
recalculate the pseudo header checksum. kunpeng930 support not need
to erase the L4 len value of the TCP TSO pseudo header.

Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
4 years agonet/hns3: add max number of segments compatibility
Hongbo Zheng [Tue, 22 Sep 2020 12:03:16 +0000 (20:03 +0800)]
net/hns3: add max number of segments compatibility

Kunpeng 920 supports the maximum nb_segs of non-tso packet is 8 in Tx
direction, kunpeng 930 expands this limit value to 18, this patch sets
the corresponding value by querying the maximum number of non-tso nb_segs
supported by the device during initialization.

Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
4 years agonet/hns3: add default case to switch in Rx VLAN processing
Chengchang Tang [Tue, 22 Sep 2020 12:03:15 +0000 (20:03 +0800)]
net/hns3: add default case to switch in Rx VLAN processing

This patch solves the static check warning as follow:
"The switch statement must have a 'default' branch".

Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
4 years agonet/hns3: fix deleting default VLAN from PF
Chengchang Tang [Tue, 22 Sep 2020 12:03:14 +0000 (20:03 +0800)]
net/hns3: fix deleting default VLAN from PF

Currently, the default VLAN (vlan id 0) will never be deleted from the
hardware VLAN table based on hns3 PF device. As a result, even a
non-zero PVID is set by calling rte_eth_dev_set_vlan_pvid based on hns3
PF device, packets with VLAN 0 and without VLAN are still received by PF
driver in Rx direction.

This patch deletes the restriction that VLAN 0 cannot be removed in PVID
configuration to ensure packets without PVID will be filtered when PVID
is set. And the patch adds VLAN 0 to the soft list when initializing
vlan configuration to ensure that VLAN 0 will be deleted from the
hardware VLAN table when device is closed.

Fixes: 411d23b9eafb ("net/hns3: support VLAN")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
4 years agonet/hns3: add VLAN configuration compatibility
Wei Hu (Xavier) [Tue, 22 Sep 2020 12:03:13 +0000 (20:03 +0800)]
net/hns3: add VLAN configuration compatibility

Because of hardware limitation based on the old version of hns3 network
engine, there are some restrictions:
a) HNS3 PMD driver needs select different processing mode for VLAN based
   on whether PVID is set which means our driver need sense the PVID
   states.
b) For packets transmitting process, only two layer of VLAN tag is
   supported. If the total number of VLAN tags in mbuf and VLAN offload
   by hardware (VLAN insert by descriptor) exceeds two, the VLAN in mbuf
   will be overwritten by VLAN in the descriptor.
c) If port based VLAN is set, only one VLAN header is allowed in mbuf or
   it will be discard by hardware.

In order to solve these restriction, two change is implemented on the
new versions of network engine.
1) add a new VLAN tagged insertion mode, named tag shift mode;
2) add a new VLAN strip control bit, named strip hide enable;

The tag shift mode means that VLAN tag will shift automatically when the
inserted place has a tag. For PMD driver, the VLAN tag1 and tag2
configurations in Tx side do not need to be considered because the
hardware completes it. However, the related configuration will still be
retained to be compatible with the old version of network engine.

The VLAN strip hide means that hardware will strip the VLAN tag and hide
VLAN in descriptor (VLAN ID exposed as zero and related STRIP_TAGP is
off).

These changes make it no longer necessary for the hns3 PMD driver to be
aware of the PVID status and have the ability to send mult-layer (more
than two) VLANs packets. Therefore, hns3 PMD driver introduces the
concept of VLAN mode and adds a new VLAN mode named HNS3_PVID_MODE to
indicate that PVID-related IO process can be implemented by the
hardware. And VF driver does not need to be modified because the related
mailbox messages will not be sent by PF kernel mode netdev driver under
new network engine and all the related hardware configuration is on the
PF side.

Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
4 years agonet/bnxt: check representors devargs before probe
Somnath Kotur [Fri, 25 Sep 2020 10:40:44 +0000 (16:10 +0530)]
net/bnxt: check representors devargs before probe

Check for num_rep before invoking rep port probe. num_rep should be !=0
if representor devargs provided.

Fixes: 6dc83230b43b ("net/bnxt: support port representor data path")
Cc: stable@dpdk.org
Signed-off-by: Somnath Kotur <somnath.kotur@broadcom.com>
Reviewed-by: Venkat Duvvuru <venkatkumar.duvvuru@broadcom.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
4 years agonet/bnxt: support 200G PAM4 link
Ajit Khaparde [Thu, 20 Aug 2020 03:51:02 +0000 (20:51 -0700)]
net/bnxt: support 200G PAM4 link

Thor based NICs can support PAM4 as wells as NRZ link negotiation.
With this patch we are adding support for 200G link speeds based on
PAM4 signaling. While PAM4 can negotiate speeds for 50G and 100G as
well, the PMD will use NRZ signalling for these speeds.

Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
4 years agoapp/testpmd: add EEPROM command
David Liu [Tue, 15 Sep 2020 17:27:40 +0000 (13:27 -0400)]
app/testpmd: add EEPROM command

Add module EEPROM/EEPROM dump command
   "show port <port_id> (module_eeprom|eeprom)"
Commands will dump the content of the EEPROM/module
EEPROM for the selected port.

Signed-off-by: David Liu <dliu@iol.unh.edu>
Reviewed-by: Phil Yang <phil.yang@arm.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
4 years agonet/bnxt: fix queue get info
Lance Richardson [Tue, 22 Sep 2020 17:30:35 +0000 (13:30 -0400)]
net/bnxt: fix queue get info

Return current offloads in rxq_info_get()/txq_info_get().

Fixes: 2fc201884be8 ("net/bnxt: support rxq/txq get information")
Cc: stable@dpdk.org
Signed-off-by: Lance Richardson <lance.richardson@broadcom.com>
Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
4 years agonet/bnxt: fix drop enable in get Rx queue info
Lance Richardson [Tue, 22 Sep 2020 17:30:34 +0000 (13:30 -0400)]
net/bnxt: fix drop enable in get Rx queue info

Return correct value for rx_drop_en. Add per-queue field to
track rx_drop_en configuration.

Fixes: 2fc201884be8 ("net/bnxt: support rxq/txq get information")
Cc: stable@dpdk.org
Signed-off-by: Lance Richardson <lance.richardson@broadcom.com>
Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
4 years agonet/bnxt: fix crash during NAT configuration
Kishore Padmanabha [Tue, 22 Sep 2020 07:06:32 +0000 (12:36 +0530)]
net/bnxt: fix crash during NAT configuration

Initialize the global parameters structure to avoid segmentation fault
in the TRUFLOW global configuration set API.

Fixes: 0a58be6f7c1e ("net/bnxt: add access to NAT global register")
Cc: stable@dpdk.org
Signed-off-by: Kishore Padmanabha <kishore.padmanabha@broadcom.com>
Reviewed-by: Mike Baucom <michael.baucom@broadcom.com>
Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
4 years agonet/bnxt: fix flow match to ignore packet type
Kishore Padmanabha [Tue, 22 Sep 2020 07:06:31 +0000 (12:36 +0530)]
net/bnxt: fix flow match to ignore packet type

The pkt_type field in the profile TCAM table needs to be ignored and
should not be set to normal packet type. The pkt_type for the packets
that are segmented due to transmit segment offload feature in the driver
are not marked as normal pkt_type and this shall result in profile TCAM
table miss and flow not being offloaded hence resulting in the reduction
of the throughput.

Fixes: fe82f3e02701 ("net/bnxt: support exact match templates")
Cc: stable@dpdk.org
Signed-off-by: Kishore Padmanabha <kishore.padmanabha@broadcom.com>
Reviewed-by: Mike Baucom <michael.baucom@broadcom.com>
Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
4 years agonet/bnxt: support representors on remote host domain
Somnath Kotur [Tue, 22 Sep 2020 07:06:30 +0000 (12:36 +0530)]
net/bnxt: support representors on remote host domain

In the Stingray use case, representors are conventionally run
inside the SoC domain representing functions that are on the
X86 domain. In order to support this mechanism of building
representors for endpoints that are not in the same host domain,
additional dev args have been in the PMD like so:
rep-based-pf=<physical index> rep-is-pf=<VF=0 or PF=1>
where `rep-based-pf` specifies the physical index of the base PF
that the representor is derived off of.
Since representor(s) can be created for endpoint PFs as well,
rename struct bnxt_vf_representor to bnxt_representor and other such
dev_ops and function names.
devargs have also been extended to specify the exact CoS queue along
with flow control enablement to be used for the conduit between the
representor and the endpoint function.
This is how a sample devargs would look with all the extended devargs

-w 0000:06:02.0,host-based-truflow=1,representor=[1],rep-based-pf=8,
rep-is-pf=1,rep-q-r2f=1,rep-fc-r2f=0,rep-q-f2r=1,rep-fc-f2r=1

Call CFA_PAIR_ALLOC only in case of Stingray instead of CFA_VFR_ALLOC.

Signed-off-by: Somnath Kotur <somnath.kotur@broadcom.com>
Reviewed-by: Mike Baucom <michael.baucom@broadcom.com>
Reviewed-by: Venkat Duvvuru <venkatkumar.duvvuru@broadcom.com>
Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
4 years agonet/bnxt: fix TruFlow devarg handling
Somnath Kotur [Tue, 22 Sep 2020 07:06:28 +0000 (12:36 +0530)]
net/bnxt: fix TruFlow devarg handling

Set the TRUFLOW Enable bit in bp->flags only if the value passed in
devargs was 1. Otherwise set it to 0.

Fixes: 313ac35ac701 ("net/bnxt: support ULP session manager init")
Cc: stable@dpdk.org
Signed-off-by: Somnath Kotur <somnath.kotur@broadcom.com>
Reviewed-by: Venkat Duvvuru <venkatkumar.duvvuru@broadcom.com>
Reviewed-by: Mike Baucom <michael.baucom@broadcom.com>
Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
4 years agonet/bnxt: fix shift operation
Somnath Kotur [Tue, 22 Sep 2020 07:06:27 +0000 (12:36 +0530)]
net/bnxt: fix shift operation

In page_roundup() left shifting by more than 31 bits could have
undefined behavior as the return value is int and in page_getenum()
it is possible to return a value as high as 63.
Fix that to cap the return value to less than 32.

Coverity issue: 343463
Fixes: b7778e8a1c00 ("net/bnxt: refactor to properly allocate resources for PF/VF")
Cc: stable@dpdk.org
Signed-off-by: Somnath Kotur <somnath.kotur@broadcom.com>
Reviewed-by: Venkat Duvvuru <venkatkumar.duvvuru@broadcom.com>
Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com>