Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH net 1/2] geneve: should not call rt6_lookup() when ipv6 was disabled
From: Eric Dumazet @ 2019-02-06 19:08 UTC (permalink / raw)
  To: David Ahern, Hangbin Liu, netdev; +Cc: Stefano Brivio, David Miller
In-Reply-To: <9b7585c2-bab6-1c6c-7bab-9542406acf1a@gmail.com>



On 02/06/2019 10:54 AM, David Ahern wrote:
> On 2/6/19 4:51 AM, Hangbin Liu wrote:
>> When we add a new GENEVE device with IPv6 remote, checking only for
>> IS_ENABLED(CONFIG_IPV6) is not enough as we may disable IPv6 in kernel
>> cmd(ipv6.disable=1), which will cause a NULL pointer dereference.
>>
>> Reported-by: Jianlin Shi <jishi@redhat.com>
>> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
>> ---
>>  drivers/net/geneve.c | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
>> index 58bbba8582b0..0658715581e3 100644
>> --- a/drivers/net/geneve.c
>> +++ b/drivers/net/geneve.c
>> @@ -1512,6 +1512,10 @@ static void geneve_link_config(struct net_device *dev,
>>  	}
>>  #if IS_ENABLED(CONFIG_IPV6)
>>  	case AF_INET6: {
>> +		struct inet6_dev *idev = in6_dev_get(dev);
>> +		if (!idev)
>> +			break;
> 
> Since you don't need an idev reference rcu_access_pointer should be
> enough to say v6 is enabled on this device. ie., add a helper to check
> that rcu_access_pointer(dev->ip6_ptr) is non-NULL
> 

I guess RTNL is held at this point, so we can use a lockdep enabled
accessor : __in6_dev_get()


^ permalink raw reply

* Re: [B.A.T.M.A.N.] [RFC v4 00/19] batman-adv: netlink restructuring, part 2
From: Linus Lüssing @ 2019-02-06 19:08 UTC (permalink / raw)
  To: The list for a Better Approach To Mobile Ad-hoc Networking
  Cc: netdev, Jiri Pirko
In-Reply-To: <3348534.ntHJrxh9jc@sven-edge>

On Wed, Feb 06, 2019 at 07:20:25PM +0100, Sven Eckelmann wrote:
> On Tuesday, 5 February 2019 20.24.10 CET Linus Lüssing wrote:
> [...]
> > Another thought, if all this is too vague for now... 
> 
> Yes, it is to vague for the integration in netlink :D
> 
> > what about
> > ommiting the BATADV_ATTR_MULTICAST_(MODE)_ENABLED for now and use
> > a reverse logic instead? Like
> > BATADV_ATTR_MULTICAST_FORCEFLOOD_ENABLED, defaulting to false.
> 
> Would be fine for me. But it is rather odd to map this to the batctl 
> multicast_mode. But the name is explaining quite well what it does
> and you can later rewrite the batctl part.

Ok, will rewrite the batctl part later then. And probably keep "batctl
mm" as a (hidden?) option for compatibility reasons?

Regards, Linus

^ permalink raw reply

* Re: [PATCH net 1/2] geneve: should not call rt6_lookup() when ipv6 was disabled
From: Eric Dumazet @ 2019-02-06 19:09 UTC (permalink / raw)
  To: Stefano Brivio, David Ahern; +Cc: Hangbin Liu, netdev, David Miller
In-Reply-To: <20190206200417.2c1b1e78@redhat.com>



On 02/06/2019 11:04 AM, Stefano Brivio wrote:

> I guess if (__in6_dev_get(dev)) is already good, no? This is called
> under RTNL.
> 

Exactly ;)

^ permalink raw reply

* Re: [PATCH net-next v4 12/12] net: Get rid of SWITCHDEV_ATTR_ID_PORT_PARENT_ID
From: Ido Schimmel @ 2019-02-06 19:10 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: netdev@vger.kernel.org, David S. Miller, open list,
	open list:MELLANOX MLX5 core VPI driver,
	open list:NETRONOME ETHERNET DRIVERS, open list:STAGING SUBSYSTEM,
	moderated list:ETHERNET BRIDGE
In-Reply-To: <20190206174546.23597-13-f.fainelli@gmail.com>

On Wed, Feb 06, 2019 at 09:45:46AM -0800, Florian Fainelli wrote:
> Now that we have a dedicated NDO for getting a port's parent ID, get rid
> of SWITCHDEV_ATTR_ID_PORT_PARENT_ID and convert all callers to use the
> NDO exclusively. This is a preliminary change to getting rid of
> switchdev_ops eventually.
> 
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

Reviewed-by: Ido Schimmel <idosch@mellanox.com>

^ permalink raw reply

* Re: [PATCH net-next v4 01/12] net: Introduce ndo_get_port_parent_id()
From: Ido Schimmel @ 2019-02-06 19:10 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: netdev@vger.kernel.org, David S. Miller, open list,
	open list:MELLANOX MLX5 core VPI driver,
	open list:NETRONOME ETHERNET DRIVERS, open list:STAGING SUBSYSTEM,
	moderated list:ETHERNET BRIDGE
In-Reply-To: <20190206174546.23597-2-f.fainelli@gmail.com>

On Wed, Feb 06, 2019 at 09:45:35AM -0800, Florian Fainelli wrote:
> In preparation for getting rid of switchdev_ops, create a dedicated NDO
> operation for getting the port's parent identifier. There are
> essentially two classes of drivers that need to implement getting the
> port's parent ID which are VF/PF drivers with a built-in switch, and
> pure switchdev drivers such as mlxsw, ocelot, dsa etc.
> 
> We introduce a helper function: dev_get_port_parent_id() which supports
> recursion into the lower devices to obtain the first port's parent ID.
> 
> Convert the bridge, core and ipv4 multicast routing code to check for
> such ndo_get_port_parent_id() and call the helper function when valid
> before falling back to switchdev_port_attr_get(). This will allow us to
> convert all relevant drivers in one go instead of having to implement
> both switchdev_port_attr_get() and ndo_get_port_parent_id() operations,
> then get rid of switchdev_port_attr_get().
> 
> Acked-by: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

Reviewed-by: Ido Schimmel <idosch@mellanox.com>

^ permalink raw reply

* Re: [PATCH net-next 0/2] mlxsw: core: Trace EMAD errors
From: David Miller @ 2019-02-06 19:26 UTC (permalink / raw)
  To: idosch; +Cc: netdev, jiri, nird, mlxsw
In-Reply-To: <20190204184649.5292-1-idosch@mellanox.com>

From: Ido Schimmel <idosch@mellanox.com>
Date: Mon, 4 Feb 2019 18:47:44 +0000

> Nir says:
> 
> This patchset adds a trace for EMAD errors to the existing EMAD payload
> traces. This tracepoint is useful to track user or firmware errors during
> tests execution.
> 
> Patch #1 defines the devlink tracepoint.
> Patch #2 uses it for reporting mlxsw EMAD errors.

Series applied, thanks.

^ permalink raw reply

* [PULL] virtio: fixes
From: Michael S. Tsirkin @ 2019-02-06 19:32 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: kvm, virtualization, netdev, linux-kernel, mst, tiwei.bie

The following changes since commit 49a57857aeea06ca831043acbb0fa5e0f50602fd:

  Linux 5.0-rc3 (2019-01-21 13:14:44 +1300)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus

for you to fetch changes up to 9c0644ee4aa8792f1e60a2b014b4710faaddafeb:

  virtio: drop internal struct from UAPI (2019-02-05 15:29:48 -0500)

----------------------------------------------------------------
virtio: fixes

A small fix for a uapi header, and a fix for VDPA for non-x86 guests.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

----------------------------------------------------------------
Michael S. Tsirkin (1):
      virtio: drop internal struct from UAPI

Tiwei Bie (1):
      virtio: support VIRTIO_F_ORDER_PLATFORM

 drivers/virtio/virtio_ring.c       | 15 ++++++++++++++-
 include/uapi/linux/virtio_config.h |  6 ++++++
 include/uapi/linux/virtio_ring.h   | 10 ----------
 3 files changed, 20 insertions(+), 11 deletions(-)

^ permalink raw reply

* [PATCH net-next 1/2] mlxsw: spectrum_router: Offload blackhole routes
From: Ido Schimmel @ 2019-02-06 19:42 UTC (permalink / raw)
  To: netdev@vger.kernel.org
  Cc: davem@davemloft.net, Jiri Pirko, Alexander Petrovskiy,
	dsahern@gmail.com, mlxsw, Ido Schimmel
In-Reply-To: <20190206194140.18606-1-idosch@mellanox.com>

Create a new FIB entry type for blackhole routes and set it in case the
type of the notified route is 'RTN_BLACKHOLE'.

Program such routes with a discard action and mark them as offloaded
since the device is dropping the packets instead of the kernel.

Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
---
 .../ethernet/mellanox/mlxsw/spectrum_router.c | 27 +++++++++++++++++--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 230e1f6e192b..6754061d9b72 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -364,6 +364,7 @@ enum mlxsw_sp_fib_entry_type {
 	MLXSW_SP_FIB_ENTRY_TYPE_REMOTE,
 	MLXSW_SP_FIB_ENTRY_TYPE_LOCAL,
 	MLXSW_SP_FIB_ENTRY_TYPE_TRAP,
+	MLXSW_SP_FIB_ENTRY_TYPE_BLACKHOLE,
 
 	/* This is a special case of local delivery, where a packet should be
 	 * decapsulated on reception. Note that there is no corresponding ENCAP,
@@ -3928,6 +3929,7 @@ mlxsw_sp_fib_entry_should_offload(const struct mlxsw_sp_fib_entry *fib_entry)
 		return !!nh_group->adj_index_valid;
 	case MLXSW_SP_FIB_ENTRY_TYPE_LOCAL:
 		return !!nh_group->nh_rif;
+	case MLXSW_SP_FIB_ENTRY_TYPE_BLACKHOLE:
 	case MLXSW_SP_FIB_ENTRY_TYPE_IPIP_DECAP:
 	case MLXSW_SP_FIB_ENTRY_TYPE_NVE_DECAP:
 		return true;
@@ -3963,6 +3965,7 @@ mlxsw_sp_fib4_entry_offload_set(struct mlxsw_sp_fib_entry *fib_entry)
 	int i;
 
 	if (fib_entry->type == MLXSW_SP_FIB_ENTRY_TYPE_LOCAL ||
+	    fib_entry->type == MLXSW_SP_FIB_ENTRY_TYPE_BLACKHOLE ||
 	    fib_entry->type == MLXSW_SP_FIB_ENTRY_TYPE_IPIP_DECAP ||
 	    fib_entry->type == MLXSW_SP_FIB_ENTRY_TYPE_NVE_DECAP) {
 		nh_grp->nexthops->key.fib_nh->nh_flags |= RTNH_F_OFFLOAD;
@@ -4004,7 +4007,8 @@ mlxsw_sp_fib6_entry_offload_set(struct mlxsw_sp_fib_entry *fib_entry)
 	fib6_entry = container_of(fib_entry, struct mlxsw_sp_fib6_entry,
 				  common);
 
-	if (fib_entry->type == MLXSW_SP_FIB_ENTRY_TYPE_LOCAL) {
+	if (fib_entry->type == MLXSW_SP_FIB_ENTRY_TYPE_LOCAL ||
+	    fib_entry->type == MLXSW_SP_FIB_ENTRY_TYPE_BLACKHOLE) {
 		list_first_entry(&fib6_entry->rt6_list, struct mlxsw_sp_rt6,
 				 list)->rt->fib6_nh.nh_flags |= RTNH_F_OFFLOAD;
 		return;
@@ -4172,6 +4176,19 @@ static int mlxsw_sp_fib_entry_op_trap(struct mlxsw_sp *mlxsw_sp,
 	return mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(ralue), ralue_pl);
 }
 
+static int mlxsw_sp_fib_entry_op_blackhole(struct mlxsw_sp *mlxsw_sp,
+					   struct mlxsw_sp_fib_entry *fib_entry,
+					   enum mlxsw_reg_ralue_op op)
+{
+	enum mlxsw_reg_ralue_trap_action trap_action;
+	char ralue_pl[MLXSW_REG_RALUE_LEN];
+
+	trap_action = MLXSW_REG_RALUE_TRAP_ACTION_DISCARD_ERROR;
+	mlxsw_sp_fib_entry_ralue_pack(ralue_pl, fib_entry, op);
+	mlxsw_reg_ralue_act_local_pack(ralue_pl, trap_action, 0, 0);
+	return mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(ralue), ralue_pl);
+}
+
 static int
 mlxsw_sp_fib_entry_op_ipip_decap(struct mlxsw_sp *mlxsw_sp,
 				 struct mlxsw_sp_fib_entry *fib_entry,
@@ -4211,6 +4228,8 @@ static int __mlxsw_sp_fib_entry_op(struct mlxsw_sp *mlxsw_sp,
 		return mlxsw_sp_fib_entry_op_local(mlxsw_sp, fib_entry, op);
 	case MLXSW_SP_FIB_ENTRY_TYPE_TRAP:
 		return mlxsw_sp_fib_entry_op_trap(mlxsw_sp, fib_entry, op);
+	case MLXSW_SP_FIB_ENTRY_TYPE_BLACKHOLE:
+		return mlxsw_sp_fib_entry_op_blackhole(mlxsw_sp, fib_entry, op);
 	case MLXSW_SP_FIB_ENTRY_TYPE_IPIP_DECAP:
 		return mlxsw_sp_fib_entry_op_ipip_decap(mlxsw_sp,
 							fib_entry, op);
@@ -4279,8 +4298,10 @@ mlxsw_sp_fib4_entry_type_set(struct mlxsw_sp *mlxsw_sp,
 	case RTN_BROADCAST:
 		fib_entry->type = MLXSW_SP_FIB_ENTRY_TYPE_TRAP;
 		return 0;
+	case RTN_BLACKHOLE:
+		fib_entry->type = MLXSW_SP_FIB_ENTRY_TYPE_BLACKHOLE;
+		return 0;
 	case RTN_UNREACHABLE: /* fall through */
-	case RTN_BLACKHOLE: /* fall through */
 	case RTN_PROHIBIT:
 		/* Packets hitting these routes need to be trapped, but
 		 * can do so with a lower priority than packets directed
@@ -5229,6 +5250,8 @@ static void mlxsw_sp_fib6_entry_type_set(struct mlxsw_sp *mlxsw_sp,
 	 */
 	if (rt->fib6_flags & (RTF_LOCAL | RTF_ANYCAST))
 		fib_entry->type = MLXSW_SP_FIB_ENTRY_TYPE_TRAP;
+	else if (rt->fib6_type == RTN_BLACKHOLE)
+		fib_entry->type = MLXSW_SP_FIB_ENTRY_TYPE_BLACKHOLE;
 	else if (rt->fib6_flags & RTF_REJECT)
 		fib_entry->type = MLXSW_SP_FIB_ENTRY_TYPE_LOCAL;
 	else if (mlxsw_sp_rt6_is_gateway(mlxsw_sp, rt))
-- 
2.20.1


^ permalink raw reply related

* [PATCH net-next 0/2] mlxsw: Offload blackhole routes
From: Ido Schimmel @ 2019-02-06 19:42 UTC (permalink / raw)
  To: netdev@vger.kernel.org
  Cc: davem@davemloft.net, Jiri Pirko, Alexander Petrovskiy,
	dsahern@gmail.com, mlxsw, Ido Schimmel

Blackhole routes are routes that cause matching packets to be silently
dropped. This is in contrast to unreachable routes that generate an ICMP
host unreachable packet in response.

The driver currently programs both route types with a trap action and
lets the kernel drop matching packets. This is sub-optimal as packets
routed using a blackhole route can be directly dropped by the ASIC.

Patch #1 alters mlxsw to program blackhole routes with a discard action.

Patch #2 adds a matching test.

Ido Schimmel (2):
  mlxsw: spectrum_router: Offload blackhole routes
  selftests: mlxsw: Add a test for blackhole routes

 .../ethernet/mellanox/mlxsw/spectrum_router.c |  27 ++-
 .../drivers/net/mlxsw/blackhole_routes.sh     | 200 ++++++++++++++++++
 2 files changed, 225 insertions(+), 2 deletions(-)
 create mode 100755 tools/testing/selftests/drivers/net/mlxsw/blackhole_routes.sh

-- 
2.20.1


^ permalink raw reply

* [PATCH net-next 2/2] selftests: mlxsw: Add a test for blackhole routes
From: Ido Schimmel @ 2019-02-06 19:42 UTC (permalink / raw)
  To: netdev@vger.kernel.org
  Cc: davem@davemloft.net, Jiri Pirko, Alexander Petrovskiy,
	dsahern@gmail.com, mlxsw, Ido Schimmel
In-Reply-To: <20190206194140.18606-1-idosch@mellanox.com>

Use a simple topology consisting of two hosts directly connected to a
router. Make sure IPv4/IPv6 ping works and then add blackhole routes.
Test that ping fails and that the routes are marked as offloaded. Use a
simple tc filter to test that packets were dropped by the ASIC and not
trapped to the CPU.

Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
 .../drivers/net/mlxsw/blackhole_routes.sh     | 200 ++++++++++++++++++
 1 file changed, 200 insertions(+)
 create mode 100755 tools/testing/selftests/drivers/net/mlxsw/blackhole_routes.sh

diff --git a/tools/testing/selftests/drivers/net/mlxsw/blackhole_routes.sh b/tools/testing/selftests/drivers/net/mlxsw/blackhole_routes.sh
new file mode 100755
index 000000000000..5ba5bef44d5b
--- /dev/null
+++ b/tools/testing/selftests/drivers/net/mlxsw/blackhole_routes.sh
@@ -0,0 +1,200 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+#
+# Test that blackhole routes are marked as offloaded and that packets hitting
+# them are dropped by the ASIC and not by the kernel.
+#
+# +---------------------------------+
+# | H1 (vrf)                        |
+# |    + $h1                        |
+# |    | 192.0.2.1/24               |
+# |    | 2001:db8:1::1/64           |
+# |    |                            |
+# |    |  default via 192.0.2.2     |
+# |    |  default via 2001:db8:1::2 |
+# +----|----------------------------+
+#      |
+# +----|----------------------------------------------------------------------+
+# | SW |                                                                      |
+# |    + $rp1                                                                 |
+# |        192.0.2.2/24                                                       |
+# |        2001:db8:1::2/64                                                   |
+# |                                                                           |
+# |        2001:db8:2::2/64                                                   |
+# |        198.51.100.2/24                                                    |
+# |    + $rp2                                                                 |
+# |    |                                                                      |
+# +----|----------------------------------------------------------------------+
+#      |
+# +----|----------------------------+
+# |    |  default via 198.51.100.2  |
+# |    |  default via 2001:db8:2::2 |
+# |    |                            |
+# |    | 2001:db8:2::1/64           |
+# |    | 198.51.100.1/24            |
+# |    + $h2                        |
+# | H2 (vrf)                        |
+# +---------------------------------+
+
+lib_dir=$(dirname $0)/../../../net/forwarding
+
+ALL_TESTS="
+	ping_ipv4
+	ping_ipv6
+	blackhole_ipv4
+	blackhole_ipv6
+"
+NUM_NETIFS=4
+source $lib_dir/tc_common.sh
+source $lib_dir/lib.sh
+
+h1_create()
+{
+	simple_if_init $h1 192.0.2.1/24 2001:db8:1::1/64
+
+	ip -4 route add default vrf v$h1 nexthop via 192.0.2.2
+	ip -6 route add default vrf v$h1 nexthop via 2001:db8:1::2
+}
+
+h1_destroy()
+{
+	ip -6 route del default vrf v$h1 nexthop via 2001:db8:1::2
+	ip -4 route del default vrf v$h1 nexthop via 192.0.2.2
+
+	simple_if_fini $h1 192.0.2.1/24 2001:db8:1::1/64
+}
+
+h2_create()
+{
+	simple_if_init $h2 198.51.100.1/24 2001:db8:2::1/64
+
+	ip -4 route add default vrf v$h2 nexthop via 198.51.100.2
+	ip -6 route add default vrf v$h2 nexthop via 2001:db8:2::2
+}
+
+h2_destroy()
+{
+	ip -6 route del default vrf v$h2 nexthop via 2001:db8:2::2
+	ip -4 route del default vrf v$h2 nexthop via 198.51.100.2
+
+	simple_if_fini $h2 198.51.100.1/24 2001:db8:2::1/64
+}
+
+router_create()
+{
+	ip link set dev $rp1 up
+	ip link set dev $rp2 up
+
+	tc qdisc add dev $rp1 clsact
+
+	__addr_add_del $rp1 add 192.0.2.2/24 2001:db8:1::2/64
+	__addr_add_del $rp2 add 198.51.100.2/24 2001:db8:2::2/64
+}
+
+router_destroy()
+{
+	__addr_add_del $rp2 del 198.51.100.2/24 2001:db8:2::2/64
+	__addr_add_del $rp1 del 192.0.2.2/24 2001:db8:1::2/64
+
+	tc qdisc del dev $rp1 clsact
+
+	ip link set dev $rp2 down
+	ip link set dev $rp1 down
+}
+
+ping_ipv4()
+{
+	ping_test $h1 198.51.100.1 ": h1->h2"
+}
+
+ping_ipv6()
+{
+	ping6_test $h1 2001:db8:2::1 ": h1->h2"
+}
+
+blackhole_ipv4()
+{
+	# Transmit packets from H1 to H2 and make sure they are dropped by the
+	# ASIC and not by the kernel
+	RET=0
+
+	ip -4 route add blackhole 198.51.100.0/30
+	tc filter add dev $rp1 ingress protocol ip pref 1 handle 101 flower \
+		skip_hw dst_ip 198.51.100.1 src_ip 192.0.2.1 ip_proto icmp \
+		action pass
+
+	ip -4 route show 198.51.100.0/30 | grep -q offload
+	check_err $? "route not marked as offloaded when should"
+
+	ping_do $h1 198.51.100.1
+	check_fail $? "ping passed when should not"
+
+	tc_check_packets "dev $rp1 ingress" 101 0
+	check_err $? "packets trapped and not dropped by ASIC"
+
+	log_test "IPv4 blackhole route"
+
+	tc filter del dev $rp1 ingress protocol ip pref 1 handle 101 flower
+	ip -4 route del blackhole 198.51.100.0/30
+}
+
+blackhole_ipv6()
+{
+	RET=0
+
+	ip -6 route add blackhole 2001:db8:2::/120
+	tc filter add dev $rp1 ingress protocol ipv6 pref 1 handle 101 flower \
+		skip_hw dst_ip 2001:db8:2::1 src_ip 2001:db8:1::1 \
+		ip_proto icmpv6 action pass
+
+	ip -6 route show 2001:db8:2::/120 | grep -q offload
+	check_err $? "route not marked as offloaded when should"
+
+	ping6_do $h1 2001:db8:2::1
+	check_fail $? "ping passed when should not"
+
+	tc_check_packets "dev $rp1 ingress" 101 0
+	check_err $? "packets trapped and not dropped by ASIC"
+
+	log_test "IPv6 blackhole route"
+
+	tc filter del dev $rp1 ingress protocol ipv6 pref 1 handle 101 flower
+	ip -6 route del blackhole 2001:db8:2::/120
+}
+
+setup_prepare()
+{
+	h1=${NETIFS[p1]}
+	rp1=${NETIFS[p2]}
+
+	rp2=${NETIFS[p3]}
+	h2=${NETIFS[p4]}
+
+	vrf_prepare
+	forwarding_enable
+
+	h1_create
+	h2_create
+	router_create
+}
+
+cleanup()
+{
+	pre_cleanup
+
+	router_destroy
+	h2_destroy
+	h1_destroy
+
+	forwarding_restore
+	vrf_cleanup
+}
+
+trap cleanup EXIT
+
+setup_prepare
+setup_wait
+
+tests_run
+
+exit $EXIT_STATUS
-- 
2.20.1


^ permalink raw reply related

* Re: [PATCH net-next 1/4] dpaa2-eth: Use a single page per Rx buffer
From: Jesper Dangaard Brouer @ 2019-02-06 19:49 UTC (permalink / raw)
  To: Ioana Ciocoi Radulescu
  Cc: Ilias Apalodimas, netdev@vger.kernel.org, davem@davemloft.net,
	Ioana Ciornei, brouer
In-Reply-To: <AM0PR04MB49941DCEB3094958E371F960946F0@AM0PR04MB4994.eurprd04.prod.outlook.com>


On Wed, 6 Feb 2019 15:36:33 +0000 Ioana Ciocoi Radulescu <ruxandra.radulescu@nxp.com> wrote:

> > From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> >
> > Can you share any results on XDP (XDP_DROP is usually useful for the
> > hardware capabilities).  
> 
> XDP numbers are pretty much the same as before this patch:
> 
> On a LS2088A with A72 cores @2GHz (numbers in Mpps):
> 				1core		8cores
> -------------------------------------------------------------------------
> XDP_DROP (no touching data)	5.37		29.6 (linerate)
> XDP_DROP (xdp1 sample)	3.14		24.22

It is interesting/problematic to see that the cost of touching the data
is so high 5.37Mpps -> 3.14Mpps.  The Intel CPUs have solved this in
hardware with DDIO, which delivers frame in L3-cache. I have some ideas
on how to improve this on ARM (or CPUs without DDIO).  I've previous
implemented this as RFC on mlx4 tested on a CPU without DDIO, with
great success 10mpps -> 20Mpps (but it was shutdown, as newer Intel
HW solved the issue).  The basic idea is to have an array of frames,
that you start an L2/L3-prefetch on, before going "back" and process
them for XDP or netstack. (p.s. this is the same DPDK does)

--Jesper

^ permalink raw reply

* Re: [PATCH] net: sxgbe: fix unintended sign extension
From: David Miller @ 2019-02-06 19:52 UTC (permalink / raw)
  To: colin.king
  Cc: bh74.an, ks.giri, vipul.pandya, netdev, kernel-janitors,
	linux-kernel
In-Reply-To: <20190206102503.16929-1-colin.king@canonical.com>

From: Colin King <colin.king@canonical.com>
Date: Wed,  6 Feb 2019 10:25:03 +0000

> From: Colin Ian King <colin.king@canonical.com>
> 
> Shifting a u8 by 24 will cause the value to be promoted to an integer. If
> the top bit of the u8 is set then the following conversion to an unsigned
> long will sign extend the value causing the upper 32 bits to be set in
> the result.

We feed this into a writel() which truncates to a 32-bit value, so nothing
bad can happen here.

This is a very canonical way to code up something like this, it works
properly in all situations, and therefore I'd rather not add all of
these fat ugly looking casts.

Thank you.


^ permalink raw reply

* Re: [PATCH] MAINTAINERS: add maintainer for SFF/SFP/SFP+ support
From: David Miller @ 2019-02-06 19:54 UTC (permalink / raw)
  To: rmk+kernel; +Cc: netdev, andrew, f.fainelli, hkallweit1
In-Reply-To: <E1grKr0-0004j4-2O@rmk-PC.armlinux.org.uk>

From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Wed, 06 Feb 2019 10:54:54 +0000

> Add maintainer entry for SFF/SFP/SFP+ support.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

Applied.

^ permalink raw reply

* Re: [PATCH net-next 2/6] phy: armada38x: add common phy support
From: David Miller @ 2019-02-06 19:59 UTC (permalink / raw)
  To: rmk+kernel
  Cc: andrew, gregory.clement, jason, kishon, sebastian.hesselbarth,
	thomas.petazzoni, devicetree, linux-arm-kernel, netdev
In-Reply-To: <E1grLTg-00061F-Hc@rmk-PC.armlinux.org.uk>

From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Wed, 06 Feb 2019 11:34:52 +0000

> +static int a38x_comphy_probe(struct platform_device *pdev)
> +{
> +	struct a38x_comphy *priv;
> +	struct phy_provider *provider;
> +	struct device_node *child;
> +	struct resource *res;
> +	void __iomem *base;

Reverse christmas tree here please.

Thanks.

^ permalink raw reply

* Re: [RFC 00/14] netlink/hierarchical stats
From: Florian Fainelli @ 2019-02-06 20:12 UTC (permalink / raw)
  To: Jakub Kicinski, davem
  Cc: oss-drivers, netdev, jiri, andrew, mkubecek, dsahern,
	simon.horman, jesse.brandeburg, maciejromanfijalkowski,
	vasundhara-v.volam, michael.chan, shalomt, idosch
In-Reply-To: <20190128234507.32028-1-jakub.kicinski@netronome.com>

On 1/28/19 3:44 PM, Jakub Kicinski wrote:
> Hi!
> 
> As I tried to explain in my slides at netconf 2018 we are lacking
> an expressive, standard API to report device statistics.
> 
> Networking silicon generally maintains some IEEE 802.3 and/or RMON
> statistics.  Today those all end up in ethtool -S.  Here is a simple
> attempt (admittedly very imprecise) of counting how many names driver
> authors invented for IETF RFC2819 etherStatsPkts512to1023Octets
> statistics (RX and TX):
> 
> $ git grep '".*512.*1023.*"' -- drivers/net/ | \
>     sed -e 's/.*"\(.*\)".*/\1/' | sort | uniq | wc -l
> 63
> 
> Interestingly only two drivers in the tree use the name the standard
> gave us (etherStatsPkts512to1023, modulo case).
> 
> I set out to working on this set in an attempt to give drivers a way
> to express clearly to user space standard-compliant counters.
> 
> Second most common use for custom statistics is per-queue counters.
> This is where the "hierarchical" part of this set comes in, as
> groups can be nested, and user space tools can handle the aggregation
> inside the groups if needed.
> 
> This set also tries to address the problem of users not knowing if
> a statistic is reported by hardware or the driver.  Many modern drivers
> use some prefix in ethtool -S to indicate MAC/PHY stats.  At a quick
> glance: Netronome uses "mac.", Intel "port." and Mellanox "_phy".
> In this set, netlink attributes describe whether a group of statistics
> is RX or TX, maintained by device or driver.
> 
> The purpose of this patch set is _not_ to replace ethtool -S.  It is
> an incredibly useful tool, and we will certainly continue using it.
> However, for standard-based and commonly maintained statistics a more
> structured API seems warranted.
> 
> There are two things missing from these patches, which I initially
> planned to address as well: filtering, and refresh rate control.
> 
> Filtering doesn't need much explanation, users should be able to request
> only a subset of statistics (like only SW stats or only given ID).  The
> bitmap of statistics in each group is there for filtering later on.
> 
> By refresh control I mean the ability for user space to indicate how
> "fresh" values it expects.  Sometimes reading the HW counters requires
> slow register reads or FW communication, in such cases drivers may cache
> the result.  (Privileged) user space should be able to add a "not older
> than" timestamp to indicate how fresh statistics it expects.  And vice
> versa, drivers can then also put the timestamp of when the statistics
> were last refreshed in the dump for more precise bandwidth estimation.

Another thing that we cannot quite do with ethtool right now, at least
not easily, is something like the following use case.

You have some filtering/classification capable hardware, and the HW can
count the number of times a rule has been hit/missed. The number of
rules programmed into the HW is dynamic and depends on use case so
dumping them all is not convenient for e.g.: hundreds/thousands of rules.

You would want to return only the rules that are active/enabled, and not
the full possible range of rules. With ethtool, this is not possible
because you have to define the strings first, and in a second call, you
are going to get the dump and fill in the data returned to user-space...

I will review more in depth, but the idea looks great so far.

> 
> Jakub Kicinski (14):
>   nfp: remove unused structure
>   nfp: constify parameter to nfp_port_from_netdev()
>   net: hstats: add basic/core functionality
>   net: hstats: allow hierarchies to be built
>   nfp: very basic hstat support
>   net: hstats: allow iterators
>   net: hstats: help in iteration over directions
>   nfp: hstats: make use of iteration for direction
>   nfp: hstats: add driver and device per queue statistics
>   net: hstats: add IEEE 802.3 and common IETF MIB/RMON stats
>   nfp: hstats: add IEEE/RMON ethernet port/MAC stats
>   net: hstats: add markers for partial groups
>   nfp: hstats: add a partial group of per-8021Q prio stats
>   Documentation: networking: describe new hstat API
> 
>  Documentation/networking/hstats.rst           | 590 +++++++++++++++
>  .../networking/hstats_flow_example.dot        |  11 +
>  Documentation/networking/index.rst            |   1 +
>  drivers/net/ethernet/netronome/nfp/Makefile   |   1 +
>  .../net/ethernet/netronome/nfp/nfp_hstat.c    | 474 ++++++++++++
>  drivers/net/ethernet/netronome/nfp/nfp_main.c |   1 +
>  drivers/net/ethernet/netronome/nfp/nfp_main.h |   2 +
>  drivers/net/ethernet/netronome/nfp/nfp_net.h  |  10 +-
>  .../ethernet/netronome/nfp/nfp_net_common.c   |   1 +
>  .../net/ethernet/netronome/nfp/nfp_net_repr.h |   2 +-
>  drivers/net/ethernet/netronome/nfp/nfp_port.c |   2 +-
>  drivers/net/ethernet/netronome/nfp/nfp_port.h |   2 +-
>  include/linux/netdevice.h                     |   9 +
>  include/net/hstats.h                          | 176 +++++
>  include/uapi/linux/if_link.h                  | 107 +++
>  net/core/Makefile                             |   2 +-
>  net/core/hstats.c                             | 682 ++++++++++++++++++
>  net/core/rtnetlink.c                          |  21 +
>  18 files changed, 2084 insertions(+), 10 deletions(-)
>  create mode 100644 Documentation/networking/hstats.rst
>  create mode 100644 Documentation/networking/hstats_flow_example.dot
>  create mode 100644 drivers/net/ethernet/netronome/nfp/nfp_hstat.c
>  create mode 100644 include/net/hstats.h
>  create mode 100644 net/core/hstats.c
> 


-- 
Florian

^ permalink raw reply

* Re: [PATCH net] net/mlx4_en: Force CHECKSUM_NONE for short ethernet frames
From: Saeed Mahameed @ 2019-02-06 20:15 UTC (permalink / raw)
  To: Saeed Mahameed
  Cc: edumazet@google.com, Eran Ben Elisha, davem@davemloft.net,
	netdev@vger.kernel.org, Tariq Toukan
In-Reply-To: <977402a5a51b3977fde53d0e8c336f5a8217337e.camel@mellanox.com>

On Thu, Jan 31, 2019 at 4:06 PM Saeed Mahameed <saeedm@mellanox.com> wrote:
>
> On Thu, 2019-01-31 at 11:42 -0800, Eric Dumazet wrote:
> > On Thu, Jan 31, 2019 at 11:27 AM Saeed Mahameed <saeedm@mellanox.com>
> > wrote:
> > > Are you sure ? you are claiming that the hardware will skip csum
> > > complete i.e cqe->checksum will be 0xffff for padded short IP
> > > frames.
> > > i don't think this is the case, the whole bug is that the hw does
> > > provide a partial cqe->checksum (i.e doesn't included the padding
> > > bytes) even for short eth frames.
> >
> > If the padding is not included, then cqe->checksum is 0xFFFF for
> > correctly received frames.
> >
> > Otherwise, what would be cqe->checksum in this case ? A random value
> > ?
>
> the actual checksum of IP headers+IP payload, while ignoring the
> padding bytes, which is the bug, let me double check..
>
>

Ok, just verified, csum complete (cqe->checksum) is provided and valid
for non-TCP/UDP ip packets, (on specific ConnectX3 HWs)
e.g. ICMP packets or IP fragments go through csum complete,  that
being said, looking at the code before my patch.
when cqe->checksum complete is not valid a IP non-TCP/UDP packet will
report csum NONE, which means my
TODO comment is valid even without my patch :).

We can remove the TODO, although i am fine with it if it kept there,
since it is valid,
but we must add a future optimization task (to tariq's backlog ;)) for
IP non-TCP/UDP traffic to check for
csum unnecessary when csum complete is not an option.

Thanks,
Saeed.

^ permalink raw reply

* Re: [PATCH net] net/mlx4_en: Force CHECKSUM_NONE for short ethernet frames
From: Eric Dumazet @ 2019-02-06 20:17 UTC (permalink / raw)
  To: Saeed Mahameed
  Cc: Saeed Mahameed, Eran Ben Elisha, davem@davemloft.net,
	netdev@vger.kernel.org, Tariq Toukan
In-Reply-To: <CALzJLG-H+4rjoRBWumK9RToqG9RPX1LT4S3Tf=hc+k5Vx1-b=Q@mail.gmail.com>

On Wed, Feb 6, 2019 at 12:15 PM Saeed Mahameed
<saeedm@dev.mellanox.co.il> wrote:
>
> Ok, just verified, csum complete (cqe->checksum) is provided and valid
> for non-TCP/UDP ip packets, (on specific ConnectX3 HWs)
> e.g. ICMP packets or IP fragments go through csum complete,  that
> being said, looking at the code before my patch.
> when cqe->checksum complete is not valid a IP non-TCP/UDP packet will
> report csum NONE, which means my
> TODO comment is valid even without my patch :).
>
> We can remove the TODO, although i am fine with it if it kept there,
> since it is valid,
> but we must add a future optimization task (to tariq's backlog ;)) for
> IP non-TCP/UDP traffic to check for
> csum unnecessary when csum complete is not an option.
>
>

Thanks for double checking.
You might add more details in the changelog for future generations ;)

^ permalink raw reply

* Re: [PATCH net] net/mlx4_en: Force CHECKSUM_NONE for short ethernet frames
From: Saeed Mahameed @ 2019-02-06 20:23 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: Saeed Mahameed, Eran Ben Elisha, davem@davemloft.net,
	netdev@vger.kernel.org, Tariq Toukan
In-Reply-To: <CANn89iJD3cuzMcue9rKCt6TBxM3OXd8+5YvSe=pb_22m5L_4aw@mail.gmail.com>

On Wed, Feb 6, 2019 at 12:17 PM Eric Dumazet <edumazet@google.com> wrote:
>
> On Wed, Feb 6, 2019 at 12:15 PM Saeed Mahameed
> <saeedm@dev.mellanox.co.il> wrote:
> >
> > Ok, just verified, csum complete (cqe->checksum) is provided and valid
> > for non-TCP/UDP ip packets, (on specific ConnectX3 HWs)
> > e.g. ICMP packets or IP fragments go through csum complete,  that
> > being said, looking at the code before my patch.
> > when cqe->checksum complete is not valid a IP non-TCP/UDP packet will
> > report csum NONE, which means my
> > TODO comment is valid even without my patch :).
> >
> > We can remove the TODO, although i am fine with it if it kept there,
> > since it is valid,
> > but we must add a future optimization task (to tariq's backlog ;)) for
> > IP non-TCP/UDP traffic to check for
> > csum unnecessary when csum complete is not an option.
> >
> >
>
> Thanks for double checking.
> You might add more details in the changelog for future generations ;)

Great, I will do that, we will post V2,

Thank you Eric.

^ permalink raw reply

* [PATCH net] sctp: make sctp_setsockopt_events() less strict about the option length
From: Julien Gomes @ 2019-02-06 20:14 UTC (permalink / raw)
  To: netdev, linux-sctp, linux-kernel
  Cc: davem, marcelo.leitner, nhorman, vyasevich, lucien.xin,
	Julien Gomes

Make sctp_setsockopt_events() able to accept sctp_event_subscribe
structures longer than the current definitions.

This should prevent unjustified setsockopt() failures due to struct
sctp_event_subscribe extensions (as in 4.11 and 4.12) when using
binaries that should be compatible, but were built with later kernel
uapi headers.

Signed-off-by: Julien Gomes <julien@arista.com>
---
 net/sctp/socket.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 9644bdc8e85c..f9717e2789da 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -2311,7 +2311,7 @@ static int sctp_setsockopt_events(struct sock *sk, char __user *optval,
 	int i;
 
 	if (optlen > sizeof(struct sctp_event_subscribe))
-		return -EINVAL;
+		optlen = sizeof(struct sctp_event_subscribe);
 
 	if (copy_from_user(&subscribe, optval, optlen))
 		return -EFAULT;
-- 
2.20.1


^ permalink raw reply related

* Re: [PATCH net] sctp: make sctp_setsockopt_events() less strict about the option length
From: Marcelo Ricardo Leitner @ 2019-02-06 20:37 UTC (permalink / raw)
  To: Julien Gomes
  Cc: netdev, linux-sctp, linux-kernel, davem, nhorman, vyasevich,
	lucien.xin
In-Reply-To: <20190206201430.18830-1-julien@arista.com>

On Wed, Feb 06, 2019 at 12:14:30PM -0800, Julien Gomes wrote:
> Make sctp_setsockopt_events() able to accept sctp_event_subscribe
> structures longer than the current definitions.
> 
> This should prevent unjustified setsockopt() failures due to struct
> sctp_event_subscribe extensions (as in 4.11 and 4.12) when using
> binaries that should be compatible, but were built with later kernel
> uapi headers.

Not sure if we support backwards compatibility like this?

My issue with this change is that by doing this, application will have
no clue if the new bits were ignored or not and it may think that an
event is enabled while it is not.

A workaround would be to do a getsockopt and check the size that was
returned. But then, it might as well use the right struct here in the
first place.

I'm seeing current implementation as an implicitly versioned argument:
it will always accept setsockopt calls with an old struct (v4.11 or
v4.12), but if the user tries to use v3 on a v1-only system, it will
be rejected. Pretty much like using a newer setsockopt on an old
system.

> 
> Signed-off-by: Julien Gomes <julien@arista.com>
> ---
>  net/sctp/socket.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 9644bdc8e85c..f9717e2789da 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -2311,7 +2311,7 @@ static int sctp_setsockopt_events(struct sock *sk, char __user *optval,
>  	int i;
>  
>  	if (optlen > sizeof(struct sctp_event_subscribe))
> -		return -EINVAL;
> +		optlen = sizeof(struct sctp_event_subscribe);
>  
>  	if (copy_from_user(&subscribe, optval, optlen))
>  		return -EFAULT;
> -- 
> 2.20.1
> 

^ permalink raw reply

* Re: [PATCH 00/12 net-next,v7] add flow_rule infrastructure
From: Florian Fainelli @ 2019-02-06 20:44 UTC (permalink / raw)
  To: David Miller, pablo
  Cc: netdev, thomas.lendacky, ariel.elior, michael.chan, santosh,
	madalin.bucur, yisen.zhuang, salil.mehta, jeffrey.t.kirsher,
	tariqt, saeedm, jiri, idosch, jakub.kicinski, peppe.cavallaro,
	grygorii.strashko, andrew, vivien.didelot, alexandre.torgue,
	joabreu, linux-net-drivers, ganeshgr, ogerlitz, Manish.Chopra,
	marcelo.leitner, mkubecek, venkatkumar.duvvuru, julia.lawall,
	john.fastabend, netfilter-devel, cphealy
In-Reply-To: <20190206.103911.39041593306699812.davem@davemloft.net>

On 2/6/19 10:39 AM, David Miller wrote:
> From: Pablo Neira Ayuso <pablo@netfilter.org>
> Date: Sat,  2 Feb 2019 12:50:42 +0100
> 
>> This patchset, as is, allows us to reuse the driver codebase to
>> configure ACL hardware offloads for the ethtool_rxnfc and the TC flower
>> interfaces. A few clients for this infrastructure are presented, such as
>> the bcm_sf2 and the qede drivers, for reference. Moreover all of the
>> existing drivers in the tree are converted to use this infrastructure.
>>
>> This patchset is re-using the existing flow dissector infrastructure
>> that was introduced by Jiri Pirko et al. so the amount of abstractions
>> that this patchset adds are minimal. Well, just a few wrapper structures
>> for the selector side of the rules. And, in order to express actions,
>> this patchset exposes an action API that is based on the existing TC
>> action infrastructure and what existing drivers already support on that
>> front.
>>
>> v7: This patchset is a rebase on top of the net-next tree, after
>>     addressing questions and feedback from driver developers in the
>>     last batch.
> 
> Ok, I've thought long and hard about this.
> 
> Applied to net-next, let's see where this goes.
> 
> I'll push this out after my build testing completes.

Great! Thanks. FWIW, I just ran basic testing on bcm_sf2 with this
series applied and have not had regressions, so this is good.
-- 
Florian

^ permalink raw reply

* [PATCH net-next 0/4] net: dsa: bcm_sf2: Add support for CFP statistics
From: Florian Fainelli @ 2019-02-06 20:45 UTC (permalink / raw)
  To: netdev; +Cc: davem, cphealy, vivien.didelot, Florian Fainelli

Hi all,

The Broadcom SF2 switch has a Compact Field Processor (CFP) which not
only can perform matching + action, but also counts the number of times
a rule has been hit. This is invaluable while debugging when/if rules
are not matched.

Florian Fainelli (4):
  net: dsa: bcm_sf2: Remove stats mutex
  net: dsa: bcm_sf2: Prepare for adding CFP statistics
  net: dsa: bcm_sf2: Add support for CFP statistics
  net: dsa: bcm_sf2: Allow looping back CFP rules

 drivers/net/dsa/bcm_sf2.c      | 39 ++++++++++++--
 drivers/net/dsa/bcm_sf2.h      |  8 +--
 drivers/net/dsa/bcm_sf2_cfp.c  | 99 ++++++++++++++++++++++++++++++++--
 drivers/net/dsa/bcm_sf2_regs.h |  4 ++
 4 files changed, 140 insertions(+), 10 deletions(-)

-- 
2.17.1


^ permalink raw reply

* [PATCH net-next 1/4] net: dsa: bcm_sf2: Remove stats mutex
From: Florian Fainelli @ 2019-02-06 20:45 UTC (permalink / raw)
  To: netdev; +Cc: davem, cphealy, vivien.didelot, Florian Fainelli
In-Reply-To: <20190206204600.24109-1-f.fainelli@gmail.com>

We no longer need a dedicated statistics mutex since we leverage
b53_common for statistics now.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 drivers/net/dsa/bcm_sf2.c | 1 -
 drivers/net/dsa/bcm_sf2.h | 3 ---
 2 files changed, 4 deletions(-)

diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 361fbde76654..a97b18595be9 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -1062,7 +1062,6 @@ static int bcm_sf2_sw_probe(struct platform_device *pdev)
 	dev_set_drvdata(&pdev->dev, priv);
 
 	spin_lock_init(&priv->indir_lock);
-	mutex_init(&priv->stats_mutex);
 	mutex_init(&priv->cfp.lock);
 	INIT_LIST_HEAD(&priv->cfp.rules_list);
 
diff --git a/drivers/net/dsa/bcm_sf2.h b/drivers/net/dsa/bcm_sf2.h
index faaef320ec48..83e1d8001447 100644
--- a/drivers/net/dsa/bcm_sf2.h
+++ b/drivers/net/dsa/bcm_sf2.h
@@ -87,9 +87,6 @@ struct bcm_sf2_priv {
 	/* Backing b53_device */
 	struct b53_device		*dev;
 
-	/* Mutex protecting access to the MIB counters */
-	struct mutex			stats_mutex;
-
 	struct bcm_sf2_hw_params	hw_params;
 
 	struct bcm_sf2_port_status	port_sts[DSA_MAX_PORTS];
-- 
2.17.1


^ permalink raw reply related

* [PATCH net-next 2/4] net: dsa: bcm_sf2: Prepare for adding CFP statistics
From: Florian Fainelli @ 2019-02-06 20:45 UTC (permalink / raw)
  To: netdev; +Cc: davem, cphealy, vivien.didelot, Florian Fainelli
In-Reply-To: <20190206204600.24109-1-f.fainelli@gmail.com>

In preparation for adding CFP statistics, we will need to overlay the
standard B53 statistics, so create specific bcm_sf2_sw_* functions to
call into their b53_common.c counterpart.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 drivers/net/dsa/bcm_sf2.c | 24 +++++++++++++++++++++---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index a97b18595be9..ce5f4260ea1a 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -894,12 +894,30 @@ static const struct b53_io_ops bcm_sf2_io_ops = {
 	.write64 = bcm_sf2_core_write64,
 };
 
+static void bcm_sf2_sw_get_strings(struct dsa_switch *ds, int port,
+				   u32 stringset, uint8_t *data)
+{
+	b53_get_strings(ds, port, stringset, data);
+}
+
+static void bcm_sf2_sw_get_ethtool_stats(struct dsa_switch *ds, int port,
+					 uint64_t *data)
+{
+	b53_get_ethtool_stats(ds, port, data);
+}
+
+static int bcm_sf2_sw_get_sset_count(struct dsa_switch *ds, int port,
+				     int sset)
+{
+	return b53_get_sset_count(ds, port, sset);
+}
+
 static const struct dsa_switch_ops bcm_sf2_ops = {
 	.get_tag_protocol	= b53_get_tag_protocol,
 	.setup			= bcm_sf2_sw_setup,
-	.get_strings		= b53_get_strings,
-	.get_ethtool_stats	= b53_get_ethtool_stats,
-	.get_sset_count		= b53_get_sset_count,
+	.get_strings		= bcm_sf2_sw_get_strings,
+	.get_ethtool_stats	= bcm_sf2_sw_get_ethtool_stats,
+	.get_sset_count		= bcm_sf2_sw_get_sset_count,
 	.get_ethtool_phy_stats	= b53_get_ethtool_phy_stats,
 	.get_phy_flags		= bcm_sf2_sw_get_phy_flags,
 	.phylink_validate	= bcm_sf2_sw_validate,
-- 
2.17.1


^ permalink raw reply related

* [PATCH net-next 3/4] net: dsa: bcm_sf2: Add support for CFP statistics
From: Florian Fainelli @ 2019-02-06 20:45 UTC (permalink / raw)
  To: netdev; +Cc: davem, cphealy, vivien.didelot, Florian Fainelli
In-Reply-To: <20190206204600.24109-1-f.fainelli@gmail.com>

Return CFP policer statistics (Green, Yellow or Red) as part of the
standard ethtool statistics. This helps debug when CFP rules may not be
hit (0 counter).

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 drivers/net/dsa/bcm_sf2.c      | 16 ++++++-
 drivers/net/dsa/bcm_sf2.h      |  5 ++
 drivers/net/dsa/bcm_sf2_cfp.c  | 88 ++++++++++++++++++++++++++++++++++
 drivers/net/dsa/bcm_sf2_regs.h |  4 ++
 4 files changed, 112 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index ce5f4260ea1a..5193da67dcdc 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -897,19 +897,33 @@ static const struct b53_io_ops bcm_sf2_io_ops = {
 static void bcm_sf2_sw_get_strings(struct dsa_switch *ds, int port,
 				   u32 stringset, uint8_t *data)
 {
+	int cnt = b53_get_sset_count(ds, port, stringset);
+
 	b53_get_strings(ds, port, stringset, data);
+	bcm_sf2_cfp_get_strings(ds, port, stringset,
+				data + cnt * ETH_GSTRING_LEN);
 }
 
 static void bcm_sf2_sw_get_ethtool_stats(struct dsa_switch *ds, int port,
 					 uint64_t *data)
 {
+	int cnt = b53_get_sset_count(ds, port, ETH_SS_STATS);
+
 	b53_get_ethtool_stats(ds, port, data);
+	bcm_sf2_cfp_get_ethtool_stats(ds, port, data + cnt);
 }
 
 static int bcm_sf2_sw_get_sset_count(struct dsa_switch *ds, int port,
 				     int sset)
 {
-	return b53_get_sset_count(ds, port, sset);
+	int cnt = b53_get_sset_count(ds, port, sset);
+
+	if (cnt < 0)
+		return cnt;
+
+	cnt += bcm_sf2_cfp_get_sset_count(ds, port, sset);
+
+	return cnt;
 }
 
 static const struct dsa_switch_ops bcm_sf2_ops = {
diff --git a/drivers/net/dsa/bcm_sf2.h b/drivers/net/dsa/bcm_sf2.h
index 83e1d8001447..eb3655bea467 100644
--- a/drivers/net/dsa/bcm_sf2.h
+++ b/drivers/net/dsa/bcm_sf2.h
@@ -213,5 +213,10 @@ int bcm_sf2_set_rxnfc(struct dsa_switch *ds, int port,
 int bcm_sf2_cfp_rst(struct bcm_sf2_priv *priv);
 void bcm_sf2_cfp_exit(struct dsa_switch *ds);
 int bcm_sf2_cfp_resume(struct dsa_switch *ds);
+void bcm_sf2_cfp_get_strings(struct dsa_switch *ds, int port,
+			     u32 stringset, uint8_t *data);
+void bcm_sf2_cfp_get_ethtool_stats(struct dsa_switch *ds, int port,
+				   uint64_t *data);
+int bcm_sf2_cfp_get_sset_count(struct dsa_switch *ds, int port, int sset);
 
 #endif /* __BCM_SF2_H */
diff --git a/drivers/net/dsa/bcm_sf2_cfp.c b/drivers/net/dsa/bcm_sf2_cfp.c
index 6d8059dc77b7..8747d18297fa 100644
--- a/drivers/net/dsa/bcm_sf2_cfp.c
+++ b/drivers/net/dsa/bcm_sf2_cfp.c
@@ -1201,3 +1201,91 @@ int bcm_sf2_cfp_resume(struct dsa_switch *ds)
 
 	return ret;
 }
+
+static const struct bcm_sf2_cfp_stat {
+	unsigned int offset;
+	unsigned int ram_loc;
+	const char *name;
+} bcm_sf2_cfp_stats[] = {
+	{
+		.offset = CORE_STAT_GREEN_CNTR,
+		.ram_loc = GREEN_STAT_RAM,
+		.name = "Green"
+	},
+	{
+		.offset = CORE_STAT_YELLOW_CNTR,
+		.ram_loc = YELLOW_STAT_RAM,
+		.name = "Yellow"
+	},
+	{
+		.offset = CORE_STAT_RED_CNTR,
+		.ram_loc = RED_STAT_RAM,
+		.name = "Red"
+	},
+};
+
+void bcm_sf2_cfp_get_strings(struct dsa_switch *ds, int port,
+			     u32 stringset, uint8_t *data)
+{
+	struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
+	unsigned int s = ARRAY_SIZE(bcm_sf2_cfp_stats);
+	char buf[ETH_GSTRING_LEN];
+	unsigned int i, j, iter;
+
+	if (stringset != ETH_SS_STATS)
+		return;
+
+	for (i = 1; i < priv->num_cfp_rules; i++) {
+		for (j = 0; j < s; j++) {
+			snprintf(buf, sizeof(buf),
+				 "CFP%03d_%sCntr",
+				 i, bcm_sf2_cfp_stats[j].name);
+			iter = (i - 1) * s + j;
+			strlcpy(data + iter * ETH_GSTRING_LEN,
+				buf, ETH_GSTRING_LEN);
+		}
+	}
+}
+
+void bcm_sf2_cfp_get_ethtool_stats(struct dsa_switch *ds, int port,
+				   uint64_t *data)
+{
+	struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
+	unsigned int s = ARRAY_SIZE(bcm_sf2_cfp_stats);
+	const struct bcm_sf2_cfp_stat *stat;
+	unsigned int i, j, iter;
+	struct cfp_rule *rule;
+	int ret;
+
+	mutex_lock(&priv->cfp.lock);
+	for (i = 1; i < priv->num_cfp_rules; i++) {
+		rule = bcm_sf2_cfp_rule_find(priv, port, i);
+		if (!rule)
+			continue;
+
+		for (j = 0; j < s; j++) {
+			stat = &bcm_sf2_cfp_stats[j];
+
+			bcm_sf2_cfp_rule_addr_set(priv, i);
+			ret = bcm_sf2_cfp_op(priv, stat->ram_loc | OP_SEL_READ);
+			if (ret)
+				continue;
+
+			iter = (i - 1) * s + j;
+			data[iter] = core_readl(priv, stat->offset);
+		}
+
+	}
+	mutex_unlock(&priv->cfp.lock);
+}
+
+int bcm_sf2_cfp_get_sset_count(struct dsa_switch *ds, int port, int sset)
+{
+	struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
+
+	if (sset != ETH_SS_STATS)
+		return 0;
+
+	/* 3 counters per CFP rules */
+	return (priv->num_cfp_rules - 1) * ARRAY_SIZE(bcm_sf2_cfp_stats);
+}
diff --git a/drivers/net/dsa/bcm_sf2_regs.h b/drivers/net/dsa/bcm_sf2_regs.h
index 0a1e530d52b7..67f056206f37 100644
--- a/drivers/net/dsa/bcm_sf2_regs.h
+++ b/drivers/net/dsa/bcm_sf2_regs.h
@@ -400,6 +400,10 @@ enum bcm_sf2_reg_offs {
 #define CORE_RATE_METER6		0x281e0
 #define  CIR_REF_CNT_MASK		0x7ffff
 
+#define CORE_STAT_GREEN_CNTR		0x28200
+#define CORE_STAT_YELLOW_CNTR		0x28210
+#define CORE_STAT_RED_CNTR		0x28220
+
 #define CORE_CFP_CTL_REG		0x28400
 #define  CFP_EN_MAP_MASK		0x1ff
 
-- 
2.17.1


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox