Remove unused counter. Reorder fields in channel stats structure
to match the ethtool strings order and make it easier to print them
with ethtool -S.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Send frames back on the same port for XDP_TX action.
Since the frame buffers have been allocated by us, we can recycle
them directly into the Rx buffer pool instead of requesting a
confirmation frame upon transmission complete.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Instead of freeing the RX buffers, release them back into the pool.
We wait for the maximum number of buffers supported by a single
release command to accumulate before issuing the command.

Also, don't unmap the Rx buffers at the beginning of the Rx routine
anymore, since that would require remapping them before release.
Instead, just do a DMA sync at first and only unmap if the frame is
meant for the stack.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We keep one XDP program reference per channel. The only actions
supported for now are XDP_DROP and XDP_PASS.

Until now we didn't enforce a maximum size for Rx frames based
on MTU value. Change that, since for XDP mode we must ensure no
scatter-gather frames can be received.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Acked-by: NCamelia Groza <camelia.groza@nxp.com>
Reviewed-by: NDavid Ahern <dsahern@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add support for byte queue limit.

On NAPI poll, we save the total number of Tx confirmed frames/bytes
and register them with bql at the end of the poll function.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Change the frame consume callback signature:
* the entire FQ structure is passed to the callback instead
of just the queue index
* the NAPI structure can be easily obtained from the channel
it is associated to, so we don't need to pass it explicitly
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The DPNI object on which we build a network interface has a
certain number of {Rx, Tx, Tx confirmation} frame queues as
resources. The default hardware setup offers one queue of each
type, as well as one DPCON channel, for each core available
in the system.

There are however cases where the number of queues is greater
than the number of cores or channels. Until now, we configured
and used all the frame queues associated with a DPNI, even if it
meant assigning multiple queues of one type to the same channel.

Update the driver to only use a number of queues equal to the
number of channels, ensuring each channel will contain exactly
one Rx and one Tx confirmation queue.

>From the user viewpoint, this change is completely transparent.
Performance wise there is no impact in most scenarios. In case
the number of queues is larger than and not a multiple of the
number of channels, Rx hash distribution offers now better load
balancing between cores, which can have a positive impact on
overall system performance.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Until now, both Rx and Tx confirmation frames handled during
NAPI poll were counted toward the NAPI budget. However, Tx
confirmations are lighter to process than Rx frames, which can
skew the amount of work actually done inside one NAPI cycle.

Update the code to only count Rx frames toward the NAPI budget
and set a separate threshold on how many Tx conf frames can be
processed in one poll cycle.

The NAPI poll routine stops when either the budget is consumed
by Rx frames or when Tx confirmation frames reach this threshold.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add support for inserting and deleting Rx flow classification
rules through ethtool.

We support classification based on some header fields for
flow-types ether, ip4, tcp4, udp4 and sctp4.

Rx queues are core affine, so the action argument effectively
selects on which cpu the matching frame will be processed.
Discarding the frame is also supported.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For firmware versions that support it, configure an Rx flow
classification key at probe time.

Hardware expects all rules in the classification table to share
the same key. So we setup a key containing all supported fields
at driver init and when a user adds classification rules through
ethtool, we will just mask out the unused header fields.

Since the key composition process is the same for flow
classification and hashing, reuse existing code where possible.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Since the array of supported header fields will be used for
Rx flow classification as well, rename it from "hash_fields" to
the more inclusive "dist_fields".
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The Management Complex (MC) firmware initially allowed the
configuration of a single key to be used both for Rx flow hashing
and flow classification. This prevented us from supporting
Rx flow classification through ethtool.

Starting with version 10.7.0, the Management Complex(MC) offers
a new set of APIs for separate configuration of Rx hashing and
classification keys.

Update the Rx flow hashing support to use the new API, if available.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Until now, the Rx flow hash key was a 5-tuple (IP src, IP dst,
IP nextproto, L4 src port, L4 dst port) fixed value that we
configured at probe.

Add support for configuring this hash key at runtime.
We support all standard header fields configurable through ethtool,
but cannot differentiate between flow types, so the same hash key
is applied regardless of protocol.

We also don't support the discard option.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The DPAA2 Ethernet driver supports Freescale/NXP SoCs with DPAA2
(DataPath Acceleration Architecture v2). The driver manages
network objects discovered on the fsl-mc bus.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Checkpatch complains about unnamed arguments in a function
prototype, so fix it.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The DPAA2 Ethernet driver files use a GPL-2.0+ OR BSD-3-Clause
license. Add SPDX tags and delete the full license text,
keeping the existing licenses for each file.
Add a GPL-2.0 tag for the Makefile.
Signed-off-by: NIoana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We never really used the driver version, so no point
in keeping it around.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In our documentation, we claim to use a 5-tuple key for Rx hash
distribution of flows. The code however configures a key composed
of all supported header fields.

Update the Rx hash key to contain only the documented fields:
{IP src, IP dst, IP nextproto, L4 src, L4 dst}, which was the
original intention and makes most sense as a default.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move the NXP DPIO (Datapath I/O Driver) out of the
drivers/staging directory and into the drivers/soc/fsl directory.

The DPIO driver enables access to Queue and Buffer Manager (QBMAN)
hardware on NXP DPAA2 devices. This is a prerequisite to moving the
DPAA2 Ethernet driver out of staging.
Signed-off-by: NRoy Pledge <roy.pledge@nxp.com>
Reviewed-by: NHoria Geantă <horia.geanta@nxp.com>
Reviewed-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NLi Yang <leoyang.li@nxp.com>

Previous commits:
commit 6e2387e8 ("staging: fsl-dpaa2/eth: Add Freescale DPAA2
Ethernet driver")
commit 39163c0c ("staging: fsl-dpaa2/eth: Errors checking update")

have added bits that are not specific to the WRIOP accelerator.

Move these where they belong (in DPIO) such that other accelerators
can make use of them.
Signed-off-by: NHoria Geantă <horia.geanta@nxp.com>
Acked-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NLi Yang <leoyang.li@nxp.com>

Since hardware timestmaping has been supported in driver, this
patch is to add the get_ts_info interface for ethtool to show
timestamping capability.
Signed-off-by: NYangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Hardware timestamping is supported both on Rx and Tx paths.
On Rx, timestamping is enabled for all frames. On Tx, we
only instruct the hardware to timestamp the frames marked
accordingly by the stack.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NYangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We use DPAA2_ETH_MAX_TX_QUEUES to dimension the array holding
information on Tx queues. At most, we can have one queue per cpu.

Until now we used the NR_CPUS macro to set the upper limit on number
of Tx queues. However, the platforms that the DPAA2 Ethernet driver
supports have at most 16 cores, whereas NR_CPUS is Kconfigurable and
can be much higher.

Avoid allocating memory we'll never use, by setting
DPAA2_ETH_MAX_TX_QUEUES to 16. Same for DPAA2_ETH_MAX_DPCONS.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Cleanup code in free_tx_fd() that deals with S/G frames:
- remove local variables that aren't really needed
- in the frame sw annotation area, store the actual SG table
buffer size, which is needed on free, rather then recompute
it based on number of S/G entries
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The DPAA2 Ethernet driver assumes the DPNI objects that it
uses to build network interfaces have a minimum supported
API version, but until now it did nothing to enforce this
requirement.

Add a check at probe time to make sure the DPNI object is
compatible with the set of MC commands we intend to use
on it.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Structure dpaa2_fas is naturally aligned, so no need to use
the __packed attribute explicitly.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove dpio_id field in struct dpaa2_eth_channel, which wasn't
used anywhere in the code.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move the source files out of staging into their final locations:
- dpcon.c goes to drivers/bus/fsl-mc/, next to the core infrastructure
- dpcon-cmd.h gets merged into drivers/bus/fsl-mc/fsl-mc-private.h, next
  to the other internally used APIs
- dpcon.h gets merged into include/linux/fsl/mc.h, exposing the public
  API

Update references in the dpaa2-eth staging driver.

DPCON stands for Data Path Concentrator - an interface between DPIO
(Data Path IO) and its users (e.g. dpaa2-eth). You can read more about
DPIO in Documentation/networking/dpaa2/overview.rst
Signed-off-by: NBogdan Purcareata <bogdan.purcareata@nxp.com>
Reviewed-by: NLaurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move the source files out of staging into their final locations:
- dpbp.c goes to drivers/bus/fsl-mc/, next to the core infrastructure
- dpbp-cmd.h gets merged into drivers/bus/fsl-mc/fsl-mc-private.h, next
  to the other internally used APIs
- dpbp.h gets merged into include/linux/fsl/mc.h, exposing the public
  API

Update references in the dpaa2-eth staging driver.

DPBP stands for Data Path Buffer Pool - you can read more about the
object in Documentation/networking/dpaa2/overview.rst
Signed-off-by: NBogdan Purcareata <bogdan.purcareata@nxp.com>
Reviewed-by: NLaurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the newly added DPIO service API to map cpu-affine DPIO services
to channels.

The DPAA2 Ethernet driver already had mappings of frame queues and
channels to cpus, but had no control over the DPIOs used. We can
now ensure full affinity of hotpath hardware resources to cores,
which improves performance and almost eliminates some resource
contentions (e.g. enqueue/dequeue busy counters should be close to
zero from now on).

Making the pull channel operation core affine brings the most
significant benefits. This ensures the same DPIO service will be
used for all dequeue commands issued for a certain frame queue,
which is in line with the way hardware is optimized.

Additionally, we also use affine DPIOs for the frame enqueue and
buffer release operations in order to avoid resource contention.
dpaa2_io_service_register() and dpaa2_io_service_rearm()
functions receive an affine DPIO as argument mostly for uniformity,
but this doesn't change the previous functionality.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The driver xmit function chooses an egress FQ based on the current
core id. The network stack itself sets a mapping field in the skb
based on many things - the default one being a hash on packet fields,
which the current driver ignores.

This patch saves the ingress frame flow affinity information in the
skb. In case of forwarded frames, this info will then be used for Tx
and Tx confirmation hardware queue selection, ensuring all processing
of the given frame is done on a single core.
Signed-off-by: NBogdan Purcareata <bogdan.purcareata@nxp.com>
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Aligning the Tx buffers at 64B is a performance optimization
recommendation, not a hard requirement.

Make optional the alignment of Tx FD buffers, without enforcing
a reallocation in case there is not enough headroom for it.

On Rx, we keep allocating buffers with enough headroom to allow
Tx alignment of forwarded frames.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For non-linear skbs we build scatter-gather frames and allocate
a new buffer for the S/G table in which we reserve the required
headroom, so the actual skb headroom size doesn't matter.

Rather than use a one-size-fits-all approach, decide when to
enforce headroom requirements on a frame by frame basis.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For Tx confirmed frames that have an error indication in the frame
descriptor, we look at the Frame Annotation Status field (in the
buffer headroom) for details on the root cause and then print
a debug message with that information.

While useful in initial development stages, it doesn't bring
enough added value to justify reserving 64B of headroom for all
Tx frames (FAS is only 8B long, but we must reserve chunks of 64B
from the hardware annotation area).

If we remove the need for FAS field from egress frames, we can
renounce hardware annotation completely, since FAS is the only
HWA field we currently use.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add a counter for the number of egress frames that need to be
realloc'ed due to insufficient headroom space.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 4b2d9fe8 ("staging: fsl-dpaa2/eth: Extra headroom in RX
buffers") tried to avoid the performance penalty of doing skb
reallocations in the network stack for IP forwarded frames between
two DPAA2 Ethernet interfaces. This led to a (too) complicated
formula that relies on the stack's internal implementation.

Instead, it's safer and easier to just not request any guarantee
from the stack. We already double check in the driver the required
headroom size of egress frames and realloc the skb if needed, so
we don't need to add any extra code.

On forwarding between two of our own interfaces, there is no
functional change; for traffic forwarded from a different device or
generated on the core, skb realloc operations are moved from the stack
to our driver, with no visible impact on performance.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 4b2d9fe8 ("staging: fsl-dpaa2/eth: Extra headroom in RX
buffers") removes the software annotation (SWA) area from the RX
buffer layout, as it's not used by anyone, but fails to update the
macros for accessing hardware annotation (HWA) fields, which is
right after the SWA in the buffer headroom.

This may lead to some frame annotation status fields (e.g. indication
if L3/L4 checksum is valid) to be read incorrectly.

Turn the accessor macros into inline functions and add a bool param
to specify if SWA is present or not.

Fixes: 4b2d9fe8 ("staging: fsl-dpaa2/eth: Extra headroom in RX buffers")
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The needed headroom that we ask the stack to reserve for us in TX
skbs is larger than the headroom available in RX frames, which
leads to skb reallocations in forwarding scenarios involving two
DPNI interfaces.

Configure the hardware to reserve some extra space in the RX
frame headroom to avoid this situation. The value is chosen based
on the Tx frame data offset, the Rx buffer alignment value and the
netdevice required headroom.

The network stack will take care to reserve space for HH_DATA_MOD when
building the skb, so there's no need to account for it in the netdevice
needed headroom.
Signed-off-by: NBogdan Purcareata <bogdan.purcareata@nxp.com>
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The WRIOP hardware block v1.0.0 (found on LS2080A board)
requires data in RX buffers to be aligned to 256B, but
newer revisions (e.g. on LS2088A, LS1088A) only require
64B alignment.

Check WRIOP version and decide at runtime which alignment
requirement to configure for ingress buffers.
Signed-off-by: NBogdan Purcareata <bogdan.purcareata@nxp.com>
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix the values of DPAA2_FD_CTRL_FSE and DPAA2_FD_CTRL_FAERR,
which are shifted off by one bit.

Fixes: 39163c0c ("staging: fsl-dpaa2/eth: Errors checking update")
Cc: <stable@vger.kernel.org>
Signed-off-by: NHoria Geantă <horia.geanta@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>