Until now it was possible to pass a packet to a single destination such
as vport or flow table. With the new support if multiple vports or multiple
tables are provided as destinations, fs_dr will create a multiple
destination table action, this action should replace other destination
actions provided to mlx5dr_create_rule.
Each vport destination can be provided with a reformat actions which
will be done before forwarding the packet to the vport.
Signed-off-by: Alex Vesker <valex@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>

A multiple destination table action allows HW packet duplication
to multiple destinations, this is useful for multicast or mirroring
traffic for debug. Duplicating is done using a FW flow table with
multiple destinations.

The new action creation function, mlx5dr_action_create_mult_dest_tbl
will allow creating a single table to iterate over several dr actions.
Signed-off-by: Alex Vesker <valex@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>

Function prefix was changed to be similar to other action APIs.
In order to support other FW tables the mlx5_flow_table struct was
replaced with table id and type.
Signed-off-by: Alex Vesker <valex@mellanox.com>
Reviewed-by: Erez Shitrit <erezsh@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>

We need to have the flow-table flags when creation sw-steering tables,
this parameter exists in the layer between fs_core to sw_steering, this
patch gives it to the creation function.
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>

Currently SW steering doesn't have the means to access HW iterators to
support multi-destination (FTEs) flow table entries.

In order to support multi-destination FTEs for port-mirroring, SW
steering will create a dedicated multi-destination FW managed flow table
and FTEs via direct FW commands that we introduced in the previous patch.
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>

Implement the FW command to setup a FTE (Flow Table Entry) into the FW
managed flow tables.
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>

Instead of using multiple variables use a simple struct. The
number of passed argument was too high after adding the encap
decap support bits arguments used for multiple destination reformat.
Signed-off-by: Alex Vesker <valex@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>

Use helper routines to setup and teardown multiple EQs and reuse the
code in setup, cleanup and error unwinding flows.
Signed-off-by: Parav Pandit <parav@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>

In below sequence, a EQE entry arrives for a CQ which is on the path of
being destroyed.

           cpu-0               cpu-1
           ------              -----
mlx5_core_destroy_cq()      mlx5_eq_comp_int()
  mlx5_eq_del_cq()          [..]
    radix_tree_delete()     [..]
  [..]                         mlx5_eq_cq_get() /* Didn't find CQ is
                                                 * a valid case.
                                                 */
  /* destroy CQ in hw */
  mlx5_cmd_exec()

This is still a valid scenario and correct delete CQ sequence, as
mirror of the CQ create sequence.
Hence, suppress the non harmful debug message from warn to debug level.
Keep the debug log message rate limited because user application can
trigger it repeatedly.
Signed-off-by: Parav Pandit <parav@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>

Currently the max number of channels is limited to 64, which is half of
the indirection table size to allow some flexibility. But on servers
with more than 64 cores, users may want to utilize more queues.

This patch increases the advertised max number of channels to 128 by
changing the ratio between channels and indirection table slots to 1:1.
At the same time, the driver still enable no more than 64 channels at
loading. Users can change it by ethtool afterwards.
Signed-off-by: Fan Li <fanl@mellanox.com>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>

In one case, we may forward packets from one vport
to others, but only one packets flow will be accepted,
which destination ip was assign to VF.

+-----+     +-----+            +-----+
| VFn |     | VF1 |            | VF0 | accept
+--+--+     +--+--+  hairpin   +--^--+
   |           | <--------------- |
   |           |                  |
+--+-----------v-+             +--+-------------+
|   eswitch PF1  |             |   eswitch PF0  |
+----------------+             +----------------+

tc filter add dev $PF0 protocol all parent ffff: prio 1 handle 1 \
	flower skip_sw action mirred egress redirect dev $VF0_REP
tc filter add dev $VF0 protocol ip  parent ffff: prio 1 handle 1 \
	flower skip_sw dst_ip $VF0_IP action pass
tc filter add dev $VF0 protocol all parent ffff: prio 2 handle 2 \
	flower skip_sw action mirred egress redirect dev $VF1
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Reviewed-by: Mark Bloch <markb@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>

In some configurations, gcc tries too hard to optimize this code:

drivers/net/ethernet/mellanox/mlx5/core/en_stats.c: In function 'mlx5e_grp_sw_update_stats':
drivers/net/ethernet/mellanox/mlx5/core/en_stats.c:302:1: error: the frame size of 1336 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

As was stated in the bug report, the reason is that gcc runs into a corner
case in the register allocator that is rather hard to fix in a good way.

As there is an easy way to work around it, just add a comment and the
barrier that stops gcc from trying to overoptimize the function.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657
Cc: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>

The function mlx5_buf_alloc_node is only used by the function in the
local scope. So it is appropriate to limit this function in the local
scope.
Signed-off-by: Zhu Yanjun <zyjzyj2000@gmail.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>

Andrew Lunn says:

====================
Unique mv88e6xxx IRQ names

There are a few boards which have multiple mv88e6xxx switches. With
such boards, it can be hard to determine which interrupts belong to
which switches. Make the interrupt names unique by including the
device name in the interrupt name. For the SERDES interrupt, also
include the port number. As a result of these patches ZII devel C
looks like:

 50:          0  gpio-vf610  27 Level     mv88e6xxx-0.1:00
 54:          0  mv88e6xxx-g1   3 Edge      mv88e6xxx-0.1:00-g1-atu-prob
 56:          0  mv88e6xxx-g1   5 Edge      mv88e6xxx-0.1:00-g1-vtu-prob
 58:          0  mv88e6xxx-g1   7 Edge      mv88e6xxx-0.1:00-g2
 61:          0  mv88e6xxx-g2   1 Edge      !mdio-mux!mdio@1!switch@0!mdio:01
 62:          0  mv88e6xxx-g2   2 Edge      !mdio-mux!mdio@1!switch@0!mdio:02
 63:          0  mv88e6xxx-g2   3 Edge      !mdio-mux!mdio@1!switch@0!mdio:03
 64:          0  mv88e6xxx-g2   4 Edge      !mdio-mux!mdio@1!switch@0!mdio:04
 70:          0  mv88e6xxx-g2  10 Edge      mv88e6xxx-0.1:00-serdes-10
 75:          0  mv88e6xxx-g2  15 Edge      mv88e6xxx-0.1:00-watchdog
 76:          5  gpio-vf610  26 Level     mv88e6xxx-0.2:00
 80:          0  mv88e6xxx-g1   3 Edge      mv88e6xxx-0.2:00-g1-atu-prob
 82:          0  mv88e6xxx-g1   5 Edge      mv88e6xxx-0.2:00-g1-vtu-prob
 84:          4  mv88e6xxx-g1   7 Edge      mv88e6xxx-0.2:00-g2
 87:          2  mv88e6xxx-g2   1 Edge      !mdio-mux!mdio@2!switch@0!mdio:01
 88:          0  mv88e6xxx-g2   2 Edge      !mdio-mux!mdio@2!switch@0!mdio:02
 89:          0  mv88e6xxx-g2   3 Edge      !mdio-mux!mdio@2!switch@0!mdio:03
 90:          0  mv88e6xxx-g2   4 Edge      !mdio-mux!mdio@2!switch@0!mdio:04
 95:          3  mv88e6xxx-g2   9 Edge      mv88e6xxx-0.2:00-serdes-9
 96:          0  mv88e6xxx-g2  10 Edge      mv88e6xxx-0.2:00-serdes-10
101:          0  mv88e6xxx-g2  15 Edge      mv88e6xxx-0.2:00-watchdog

Interrupt names like !mdio-mux!mdio@2!switch@0!mdio:01 are created by
phylib for the integrated PHYs. The mv88e6xxx driver does not
determine these names.
====================
Tested-by: Chris Healy <cphealy@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Dynamically generate a unique interrupt name for the VTU and ATU,
based on the device name.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>

Dynamically generate a unique g2 interrupt name, based on the
device name.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>

Dynamically generate a unique watchdog interrupt name, based on the
device name.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>

Dynamically generate a unique SERDES interrupt name, based on the
device name and the port the SERDES is for. For example:

 95:          3  mv88e6xxx-g2   9 Edge      mv88e6xxx-0.2:00-serdes-9
 96:          0  mv88e6xxx-g2  10 Edge      mv88e6xxx-0.2:00-serdes-10

The 0.2:00 indicates the switch and -9 indicates port 9.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>

Dynamically generate a unique switch interrupt name, based on the
device name.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>

Michal Kubecek says:

====================
ethtool: allow nesting of begin() and complete() callbacks

The ethtool ioctl interface used to guarantee that ethtool_ops callbacks
were always called in a block between calls to ->begin() and ->complete()
(if these are defined) and that this whole block was executed with RTNL
lock held:

	rtnl_lock();
	ops->begin();
	/* other ethtool_ops calls */
	ops->complete();
	rtnl_unlock();

This prevented any nesting or crossing of the begin-complete blocks.
However, this is no longer guaranteed even for ioctl interface as at least
ethtool_phys_id() releases RTNL lock while waiting for a timer. With the
introduction of netlink ethtool interface, the begin-complete pairs are
naturally nested e.g. when a request triggers a netlink notification.

Fortunately, only minority of networking drivers implements begin() and
complete() callbacks and most of those that do, fall into three groups:

  - wrappers for pm_runtime_get_sync() and pm_runtime_put()
  - wrappers for clk_prepare_enable() and clk_disable_unprepare()
  - begin() checks netif_running() (fails if false), no complete()

First two have their own refcounting, third is safe w.r.t. nesting of the
blocks.

Only three in-tree networking drivers need an update to deal with nesting
of begin() and complete() calls: via-velocity and epic100 perform resume
and suspend on their own and wil6210 completely serializes the calls using
its own mutex (which would lead to a deadlock if a request request
triggered a netlink notification). The series addresses these problems.

changes between v1 and v2:
  - fix inverted condition in epic100 ethtool_begin() (thanks to Andrew
    Lunn)
====================
Reviewed-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Unlike most networking drivers using begin() and complete() ethtool_ops
callbacks to resume a device which is down and suspend it again when done,
epic100 does not use standard refcounted infrastructure but sets device
sleep state directly.

With the introduction of netlink ethtool interface, we may have nested
begin-complete blocks so that inner complete() would put the device back to
sleep for the rest of the outer block.

To avoid rewriting an old and not very actively developed driver, just add
a nesting counter and only perform resume and suspend on the outermost
level.
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>

Unlike most networking drivers using begin() and complete() ethtool_ops
callbacks to resume a device which is down and suspend it again when done,
via-velocity does not use standard refcounted infrastructure but sets
device sleep state directly.

With the introduction of netlink ethtool interface, we may have nested
begin-complete blocks so that inner complete() would put the device back to
sleep for the rest of the outer block.

To avoid rewriting an old and not very actively developed driver, just add
a nesting counter and only perform resume and suspend on the outermost
level.
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>

The wil6210 driver locks a mutex in begin() ethtool_ops callback and
unlocks it in complete() so that all ethtool requests are serialized. This
is not going to work correctly with netlink interface; e.g. when ioctl
triggers a netlink notification, netlink code would call begin() again
while the mutex taken by ioctl code is still held by the same task.

Let's get rid of the begin() and complete() callbacks and move the mutex
locking into the remaining ethtool_ops handlers except get_drvinfo which
only copies strings that are not changing so that there is no need for
serialization.
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

The recent MD5 tests added duplicate configuration in the default VRF.
This change exposed a bug in existing tests designed to verify no
connection when client and server are not in the same domain. The
server should be running bound to the vrf device with the client run
in the default VRF (the -2 option is meant for validating connection
data). Fix the option for both tests.

While technically this is a bug in previous releases, the tests are
properly failing since the default VRF does not have any routing
configuration so there really is no need to backport to prior releases.
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

'gtp_encap_disable_sock(sk)' handles the case where sk is NULL, so there
is no need to test it before calling the function.

This saves a few line of code.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Ido Schimmel says:

====================
mlxsw: Disable checks in hardware pipeline

Amit says:

The hardware pipeline contains some checks that, by default, are
configured to drop packets. Since the software data path does not drop
packets due to these reasons and since we are interested in offloading
the software data path to hardware, then these checks should be disabled
in the hardware pipeline as well.

This patch set changes mlxsw to disable four of these checks and adds
corresponding selftests. The tests pass both when the software data path
is exercised (using veth pair) and when the hardware data path is
exercised (using mlxsw ports in loopback).
====================
Signed-off-by: David S. Miller <davem@davemloft.net>

Add test case to check that packets are not dropped when they need to be
routed and their destination is link-local, i.e., 169.254.0.0/16.
Signed-off-by: Amit Cohen <amitc@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

The check drops packets if they need to be routed and their destination
IP is link-local, i.e., belongs to 169.254.0.0/16 address range.

Disable the check since the kernel forwards such packets and does not
drop them.
Signed-off-by: Amit Cohen <amitc@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Add test case to check that packets are not dropped when they need to be
routed and their source IP equals to their destination IP.
Signed-off-by: Amit Cohen <amitc@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

The check drops packets if they need to be routed and their source IP
equals to their destination IP.

Disable the check since the kernel forwards such packets and does not
drop them.
Signed-off-by: Amit Cohen <amitc@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Add test case to check that packets are not dropped when they need to be
routed and their multicast MAC mismatched to their multicast destination
IP.

i.e., destination IP is multicast and
	* for IPV4: DMAC !=  {01-00-5E-0 (25 bits), DIP[22:0]}
	* for IPV6: DMAC !=  {33-33-0 (16 bits), DIP[31:0]}
Signed-off-by: Amit Cohen <amitc@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

The check drops packets if they need to be routed and their multicast
MAC mismatched to their multicast destination IP.

For IPV4:
DMAC is mismatched if it is different from {01-00-5E-0 (25 bits),
DIP[22:0]}

For IPV6:
DMAC is mismatched if it is different from {33-33-0 (16 bits),
DIP[31:0]}

Disable the check since the kernel forwards such packets and does not
drop them.
Signed-off-by: Amit Cohen <amitc@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Add test case to check that packets are not dropped when they need to be
routed and their source IP in class E, (i.e., 240.0.0.0 –
255.255.255.254).
Signed-off-by: Amit Cohen <amitc@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

The check drops packets if they need to be routed and their source IP is
from class E, i.e., belongs to 240.0.0.0/4 address range, but different
from 255.255.255.255.

Disable the check since the kernel forwards such packets and does not
drop them.
Signed-off-by: Amit Cohen <amitc@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Huazhong Tan says:

====================
net: hns3: misc updates for -net-next

This series includes some misc updates for the HNS3 ethernet driver.

[patch 1] adds trace events support.
[patch 2] re-organizes TQP's vector handling.
[patch 3] renames the name of TQP vector.
[patch 4] rewrites a log in the hclge_map_ring_to_vector().
[patch 5] modifies the name of misc IRQ vector.
[patch 6] handles the unexpected speed 0 return from HW.
[patch 7] replaces an unsuitable variable type.
[patch 8] modifies an unsuitable reset level for HW error.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>

According to hardware user manual, when hardware reports error
'roc_pkt_without_key_port', the driver should assert function
reset to do the recovery.

So this patch uses HNAE3_FUNC_RESET to replace HNAE3_GLOBAL_RESET.
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

In hclge_inform_reset_assert_to_vf(), variable reset_type(enum type)
will be copied into msg_data whose size is 2 bytes. Currently, hip08
is a little-endian machine, so the lower two bytes of reset_type will
be copied to msg_data. But when running on a big-endian machine,
msg_data will have a wrong value(the higher two bytes of reset_type).

So this patch modifies the type of reset_type to u16, and adds a
build check in case enum hnae3_reset_type has value larger than
U16_MAX.
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

In some case, the MAC speed get from hardware maybe 0, it should
not be set to mac->speed.
Signed-off-by: Guojia Liao <liaoguojia@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

The misc IRQ of all the devices have the same name, so it's
hard to find the right misc IRQ of the device.

This patch modifies the misc IRQ names as "hclge/hclgevf"-misc-
"pci name". And now the IRQ name is not related to net device
name anymore, so change the HNAE3_INT_NAME_LEN to 32 bytes, and
that is enough.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

When the returned vector_id less than 0, the message should print
out the vector who is getting vector index fail.

So this patch replaces vector_id with vector, and re-format the
message.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>