* [PATCH mlx5-next v1] net/mlx5: Factor out HCA capabilities functions
From: Leon Romanovsky @ 2019-02-17 11:11 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, Saeed Mahameed, linux-netdev
From: Leon Romanovsky <leonro@mellanox.com>
Combine all HCA capabilities setters under one function
and compile out the ODP related function in case kernel
was compiled without ODP support.
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
...
Changelog v0->v1:
* Embedded config option check into ODP capability function flow
---
.../net/ethernet/mellanox/mlx5/core/main.c | 46 +++++++++++++------
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 6d45518edbdc..025dfaf3466b 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -466,7 +466,8 @@ static int handle_hca_cap_odp(struct mlx5_core_dev *dev)
int set_sz;
int err;
- if (!MLX5_CAP_GEN(dev, pg))
+ if (!IS_ENABLED(CONFIG_INFINIBAND_ON_DEMAND_PAGING) ||
+ !MLX5_CAP_GEN(dev, pg))
return 0;
err = mlx5_core_get_caps(dev, MLX5_CAP_ODP);
@@ -576,6 +577,33 @@ static int handle_hca_cap(struct mlx5_core_dev *dev)
return err;
}
+static int set_hca_cap(struct mlx5_core_dev *dev)
+{
+ struct pci_dev *pdev = dev->pdev;
+ int err;
+
+ err = handle_hca_cap(dev);
+ if (err) {
+ dev_err(&pdev->dev, "handle_hca_cap failed\n");
+ goto out;
+ }
+
+ err = handle_hca_cap_atomic(dev);
+ if (err) {
+ dev_err(&pdev->dev, "handle_hca_cap_atomic failed\n");
+ goto out;
+ }
+
+ err = handle_hca_cap_odp(dev);
+ if (err) {
+ dev_err(&pdev->dev, "handle_hca_cap_odp failed\n");
+ goto out;
+ }
+
+out:
+ return err;
+}
+
static int set_hca_ctrl(struct mlx5_core_dev *dev)
{
struct mlx5_reg_host_endianness he_in;
@@ -963,21 +991,9 @@ static int mlx5_load_one(struct mlx5_core_dev *dev, struct mlx5_priv *priv,
goto reclaim_boot_pages;
}
- err = handle_hca_cap(dev);
- if (err) {
- dev_err(&pdev->dev, "handle_hca_cap failed\n");
- goto reclaim_boot_pages;
- }
-
- err = handle_hca_cap_atomic(dev);
- if (err) {
- dev_err(&pdev->dev, "handle_hca_cap_atomic failed\n");
- goto reclaim_boot_pages;
- }
-
- err = handle_hca_cap_odp(dev);
+ err = set_hca_cap(dev);
if (err) {
- dev_err(&pdev->dev, "handle_hca_cap_odp failed\n");
+ dev_err(&pdev->dev, "set_hca_cap failed\n");
goto reclaim_boot_pages;
}
--
2.19.1
^ permalink raw reply related
* Re: [PATCH v2 net-next 2/2] net: sock: undefine SOCK_DEBUGGING
From: Joe Perches @ 2019-02-17 11:58 UTC (permalink / raw)
To: Yafang Shao, davem; +Cc: daniel, edumazet, xiyou.wangcong, netdev, shaoyafang
In-Reply-To: <1550334537-380-3-git-send-email-laoar.shao@gmail.com>
On Sun, 2019-02-17 at 00:28 +0800, Yafang Shao wrote:
> SOCK_DEBUG() is a old facility for debugging.
> If the user want to use it for debugging, the user must modify the
> application first, that doesn't seem like a good way.
> Now we have more powerful facilities, i.e. bpf or tracepoint, for this kind
> of debugging purpose.
> So we'd better disable it by default.
> The reason why I don't remove it comepletely is that someone may still
> would like to use it for debugging.
>
> Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
> Suggested-by: Joe Perches <joe@perches.com>
> ---
> include/net/sock.h | 13 ++++++++-----
> net/core/sock.c | 3 +++
> 2 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 6679f3c..d41e8f4 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -81,14 +81,17 @@
> */
>
> /* Define this to get the SOCK_DBG debugging facility. */
> -#define SOCK_DEBUGGING
> +/* #define SOCK_DEBUGGING */
> #ifdef SOCK_DEBUGGING
> -#define SOCK_DEBUG(sk, msg...) do { if ((sk) && sock_flag((sk), SOCK_DBG)) \
> - printk(KERN_DEBUG msg); } while (0)
> +#define SOCK_DEBUG(sk, fmt, ...) \
> +do { \
> + if ((sk) && sock_flag((sk), SOCK_DBG)) \
> + pr_debug(fmt, ##__VA_ARGS__); \
trivia:
I would not suggest pr_debug here as it also requires
either DEBUG to be defined or CONFIG_DYNAMIC_DEBUG
to be set.
If you really set SOCK_DEBUGGING, then printk(KERN_DEBUG
is probably right.
^ permalink raw reply
* [PATCH net-next 0/2] Fix W=1 compilation warnings
From: Leon Romanovsky @ 2019-02-17 13:21 UTC (permalink / raw)
To: Saeed Mahameed, David S . Miller
Cc: Leon Romanovsky, RDMA mailing list, Eyal Davidovich, linux-netdev
From: Leon Romanovsky <leonro@mellanox.com>
Hi Saeed,
This short series fixes two small compilation warnings which are visible
while compiling with W=1.
Thanks
Leon Romanovsky (2):
net/mlx5e: Add missing static function annotation
net/mlx5: Delete unused FPGA QPN variable
drivers/net/ethernet/mellanox/mlx5/core/en/monitor_stats.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/fpga/core.c | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
--
2.19.1
^ permalink raw reply
* [PATCH net-next 2/2] net/mlx5: Delete unused FPGA QPN variable
From: Leon Romanovsky @ 2019-02-17 13:21 UTC (permalink / raw)
To: Saeed Mahameed, David S . Miller
Cc: Leon Romanovsky, RDMA mailing list, Eyal Davidovich, linux-netdev
In-Reply-To: <20190217132128.9709-1-leon@kernel.org>
From: Leon Romanovsky <leonro@mellanox.com>
fpga_qpn was assigned but never used and compilation with W=1
produced the following warning:
drivers/net/ethernet/mellanox/mlx5/core/fpga/core.c: In function _mlx5_fpga_event_:
drivers/net/ethernet/mellanox/mlx5/core/fpga/core.c:320:6: warning:
variable _fpga_qpn_ set but not used [-Wunused-but-set-variable]
u32 fpga_qpn;
^~~~~~~~
Fixes: 98db16bab59f ("net/mlx5: FPGA, Handle QP error event")
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/fpga/core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fpga/core.c b/drivers/net/ethernet/mellanox/mlx5/core/fpga/core.c
index 27c5f6c7d36a..d046d1ec2a86 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fpga/core.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fpga/core.c
@@ -317,7 +317,6 @@ static int mlx5_fpga_event(struct mlx5_fpga_device *fdev,
const char *event_name;
bool teardown = false;
unsigned long flags;
- u32 fpga_qpn;
u8 syndrome;
switch (event) {
@@ -328,7 +327,6 @@ static int mlx5_fpga_event(struct mlx5_fpga_device *fdev,
case MLX5_EVENT_TYPE_FPGA_QP_ERROR:
syndrome = MLX5_GET(fpga_qp_error_event, data, syndrome);
event_name = mlx5_fpga_qp_syndrome_to_string(syndrome);
- fpga_qpn = MLX5_GET(fpga_qp_error_event, data, fpga_qpn);
break;
default:
return NOTIFY_DONE;
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 1/2] net/mlx5e: Add missing static function annotation
From: Leon Romanovsky @ 2019-02-17 13:21 UTC (permalink / raw)
To: Saeed Mahameed, David S . Miller
Cc: Leon Romanovsky, RDMA mailing list, Eyal Davidovich, linux-netdev
In-Reply-To: <20190217132128.9709-1-leon@kernel.org>
From: Leon Romanovsky <leonro@mellanox.com>
Compilation with W=1 produces following warning:
drivers/net/ethernet/mellanox/mlx5/core/en/monitor_stats.c:69:6:
warning: no previous prototype for _mlx5e_monitor_counter_start_ [-Wmissing-prototypes]
void mlx5e_monitor_counter_start(struct mlx5e_priv *priv)
^~~~~~~~~~~~~~~~~~~~~~~~~~~
Avoid it by declaring mlx5e_monitor_counter_start() as a static function.
Fixes: 5c7e8bbb0257 ("net/mlx5e: Use monitor counters for update stats")
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en/monitor_stats.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/monitor_stats.c b/drivers/net/ethernet/mellanox/mlx5/core/en/monitor_stats.c
index 2ce420851e77..7cd5b02e0f10 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/monitor_stats.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/monitor_stats.c
@@ -66,7 +66,7 @@ static int mlx5e_monitor_event_handler(struct notifier_block *nb,
return NOTIFY_OK;
}
-void mlx5e_monitor_counter_start(struct mlx5e_priv *priv)
+static void mlx5e_monitor_counter_start(struct mlx5e_priv *priv)
{
MLX5_NB_INIT(&priv->monitor_counters_nb, mlx5e_monitor_event_handler,
MONITOR_COUNTER);
--
2.19.1
^ permalink raw reply related
* linux-next: Fixes tags need some work in the net tree
From: Stephen Rothwell @ 2019-02-17 13:52 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Hauke Mehrtens, Florian Fainelli
[-- Attachment #1: Type: text/plain, Size: 757 bytes --]
Hi all,
In commit
a40061ea2e39 ("net: systemport: Fix reception of BPDUs")
Fixes tag
Fixes: 4e8aedfe78c7 ("net: systemport: Turn on offloads by default")
has these problem(s):
- Target SHA1 does not exist
Did you mean
Fixes: b5061778f822 ("net: systemport: Turn on offloads by default")?
In commit
3b89ea9c5902 ("net: Fix for_each_netdev_feature on Big endian")
Fixes tag
Fixes: fd867d51f ("net/core: generic support for disabling netdev features down stack")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 net-next 2/2] net: sock: undefine SOCK_DEBUGGING
From: Yafang Shao @ 2019-02-17 14:07 UTC (permalink / raw)
To: Joe Perches
Cc: David Miller, Daniel Borkmann, Eric Dumazet, Cong Wang, netdev,
shaoyafang
In-Reply-To: <3aa310cede544d76e53ec962676a6ea4e3bd6b23.camel@perches.com>
On Sun, Feb 17, 2019 at 7:58 PM Joe Perches <joe@perches.com> wrote:
>
> On Sun, 2019-02-17 at 00:28 +0800, Yafang Shao wrote:
> > SOCK_DEBUG() is a old facility for debugging.
> > If the user want to use it for debugging, the user must modify the
> > application first, that doesn't seem like a good way.
> > Now we have more powerful facilities, i.e. bpf or tracepoint, for this kind
> > of debugging purpose.
> > So we'd better disable it by default.
> > The reason why I don't remove it comepletely is that someone may still
> > would like to use it for debugging.
> >
> > Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
> > Suggested-by: Joe Perches <joe@perches.com>
> > ---
> > include/net/sock.h | 13 ++++++++-----
> > net/core/sock.c | 3 +++
> > 2 files changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/net/sock.h b/include/net/sock.h
> > index 6679f3c..d41e8f4 100644
> > --- a/include/net/sock.h
> > +++ b/include/net/sock.h
> > @@ -81,14 +81,17 @@
> > */
> >
> > /* Define this to get the SOCK_DBG debugging facility. */
> > -#define SOCK_DEBUGGING
> > +/* #define SOCK_DEBUGGING */
> > #ifdef SOCK_DEBUGGING
> > -#define SOCK_DEBUG(sk, msg...) do { if ((sk) && sock_flag((sk), SOCK_DBG)) \
> > - printk(KERN_DEBUG msg); } while (0)
> > +#define SOCK_DEBUG(sk, fmt, ...) \
> > +do { \
> > + if ((sk) && sock_flag((sk), SOCK_DBG)) \
> > + pr_debug(fmt, ##__VA_ARGS__); \
>
> trivia:
>
> I would not suggest pr_debug here as it also requires
> either DEBUG to be defined or CONFIG_DYNAMIC_DEBUG
> to be set.
>
> If you really set SOCK_DEBUGGING, then printk(KERN_DEBUG
> is probably right.
>
Sure. Will change it.
Thanks
Yafang
^ permalink raw reply
* [PATCH net-next 0/3] net: dsa: mv88e6xxx: fix IPv6
From: Russell King - ARM Linux admin @ 2019-02-17 14:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Vivien Didelot; +Cc: David S. Miller, netdev
We'have had some emails in private over this issue, this is my current
patch set rebased on top of net-next which provides working IPv6 (and
probably other protocols as well) over mv88e6xxx DSA switches.
The problem comes down to mv88e6xxx defaulting to not flood unknown
unicast and multicast datagrams, as they would be by dumb switches,
and as the Linux bridge code does by default.
These flood settings can be disabled via the Linux bridge code if it's
desired to make the switch behave more like a managed switch, eg, by
enabling the multicast querier. However, the multicast querier
defaults to being disabled which effectively means that by default,
mv88e6xxx switches block all multicast traffic. This is at odds with
the Linux bridge documentation, and the defaults that the Linux bridge
code adopts.
So, this patch set adds DSA support for Linux bridge flags, adds
mv88e6xxx support for the unicast and multicast flooding flags, and
lastly enables flooding of these frames by default to match the
Linux bridge defaults.
drivers/net/dsa/mv88e6xxx/chip.c | 42 ++++++++++++++++++++++++++++++++++++----
include/net/dsa.h | 3 +++
net/dsa/dsa_priv.h | 2 ++
net/dsa/port.c | 15 ++++++++++++++
net/dsa/slave.c | 6 ++++++
5 files changed, 64 insertions(+), 4 deletions(-)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* [PATCH net-next 1/3] net: dsa: add support for bridge flags
From: Russell King @ 2019-02-17 14:25 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Vivien Didelot; +Cc: David S. Miller, netdev
In-Reply-To: <20190217142414.cjtmpi5y2l5rtdlb@shell.armlinux.org.uk>
The Linux bridge implementation allows various properties of the bridge
to be controlled, such as flooding unknown unicast and multicast frames.
This patch adds the necessary DSA infrastructure to allow the Linux
bridge support to control these properties for DSA switches.
We implement this by providing two new methods: one to get the switch-
wide support bitmask, and another to set the properties.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
include/net/dsa.h | 3 +++
net/dsa/dsa_priv.h | 2 ++
net/dsa/port.c | 15 +++++++++++++++
net/dsa/slave.c | 6 ++++++
4 files changed, 26 insertions(+)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 7f2a668ef2cc..6cc1222aa2ca 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -400,6 +400,9 @@ struct dsa_switch_ops {
void (*port_stp_state_set)(struct dsa_switch *ds, int port,
u8 state);
void (*port_fast_age)(struct dsa_switch *ds, int port);
+ int (*port_bridge_flags)(struct dsa_switch *ds, int port,
+ unsigned long);
+ unsigned long (*bridge_flags_support)(struct dsa_switch *ds);
/*
* VLAN support
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index 1f4972dab9f2..f4f99ec29f5d 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -160,6 +160,8 @@ int dsa_port_mdb_add(const struct dsa_port *dp,
struct switchdev_trans *trans);
int dsa_port_mdb_del(const struct dsa_port *dp,
const struct switchdev_obj_port_mdb *mdb);
+int dsa_port_bridge_flags(const struct dsa_port *dp, unsigned long flags,
+ struct switchdev_trans *trans);
int dsa_port_vlan_add(struct dsa_port *dp,
const struct switchdev_obj_port_vlan *vlan,
struct switchdev_trans *trans);
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 2d7e01b23572..eb745041b1d9 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -177,6 +177,21 @@ int dsa_port_ageing_time(struct dsa_port *dp, clock_t ageing_clock,
return dsa_port_notify(dp, DSA_NOTIFIER_AGEING_TIME, &info);
}
+int dsa_port_bridge_flags(const struct dsa_port *dp, unsigned long flags,
+ struct switchdev_trans *trans)
+{
+ struct dsa_switch *ds = dp->ds;
+ int port = dp->index;
+
+ if (switchdev_trans_ph_prepare(trans))
+ return ds->ops->port_bridge_flags ? 0 : -EOPNOTSUPP;
+
+ if (ds->ops->port_bridge_flags)
+ ds->ops->port_bridge_flags(ds, port, flags);
+
+ return 0;
+}
+
int dsa_port_fdb_add(struct dsa_port *dp, const unsigned char *addr,
u16 vid)
{
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 2e5e7c04821b..af53cdd14a29 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -295,6 +295,9 @@ static int dsa_slave_port_attr_set(struct net_device *dev,
case SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME:
ret = dsa_port_ageing_time(dp, attr->u.ageing_time, trans);
break;
+ case SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS:
+ ret = dsa_port_bridge_flags(dp, attr->u.brport_flags, trans);
+ break;
default:
ret = -EOPNOTSUPP;
break;
@@ -384,6 +387,9 @@ static int dsa_slave_port_attr_get(struct net_device *dev,
switch (attr->id) {
case SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT:
attr->u.brport_flags_support = 0;
+ if (ds->ops->bridge_flags_support)
+ attr->u.brport_flags_support |=
+ ds->ops->bridge_flags_support(ds);
break;
default:
return -EOPNOTSUPP;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 2/3] net: dsa: mv88e6xxx: add support for bridge flags
From: Russell King @ 2019-02-17 14:25 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Vivien Didelot; +Cc: David S. Miller, netdev
In-Reply-To: <20190217142414.cjtmpi5y2l5rtdlb@shell.armlinux.org.uk>
Add support for the bridge flags to Marvell 88e6xxx bridges, allowing
the multicast and unicast flood properties to be controlled. These
can be controlled on a per-port basis via commands such as:
bridge link set dev lan1 flood on|off
bridge link set dev lan1 mcast_flood on|off
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/dsa/mv88e6xxx/chip.c | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 32e7af5caa69..b75a865a293d 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4692,6 +4692,37 @@ static int mv88e6xxx_port_mdb_del(struct dsa_switch *ds, int port,
return err;
}
+static int mv88e6xxx_port_bridge_flags(struct dsa_switch *ds, int port,
+ unsigned long flags)
+{
+ struct mv88e6xxx_chip *chip = ds->priv;
+ bool unicast, multicast;
+ int ret = -EOPNOTSUPP;
+
+ unicast = dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port) ||
+ flags & BR_FLOOD;
+ multicast = flags & BR_MCAST_FLOOD;
+
+ mutex_lock(&chip->reg_lock);
+ if (chip->info->ops->port_set_egress_floods)
+ ret = chip->info->ops->port_set_egress_floods(chip, port,
+ unicast,
+ multicast);
+ mutex_unlock(&chip->reg_lock);
+
+ return ret;
+}
+
+static unsigned long mv88e6xxx_bridge_flags_support(struct dsa_switch *ds)
+{
+ unsigned long support = 0;
+
+ if (chip->info->ops->port_set_egress_floods)
+ support |= BR_FLOOD | BR_MCAST_FLOOD;
+
+ return support;
+}
+
static const struct dsa_switch_ops mv88e6xxx_switch_ops = {
#if IS_ENABLED(CONFIG_NET_DSA_LEGACY)
.probe = mv88e6xxx_drv_probe,
@@ -4719,6 +4750,8 @@ static const struct dsa_switch_ops mv88e6xxx_switch_ops = {
.set_ageing_time = mv88e6xxx_set_ageing_time,
.port_bridge_join = mv88e6xxx_port_bridge_join,
.port_bridge_leave = mv88e6xxx_port_bridge_leave,
+ .port_bridge_flags = mv88e6xxx_port_bridge_flags,
+ .bridge_flags_support = mv88e6xxx_bridge_flags_support,
.port_stp_state_set = mv88e6xxx_port_stp_state_set,
.port_fast_age = mv88e6xxx_port_fast_age,
.port_vlan_filtering = mv88e6xxx_port_vlan_filtering,
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 3/3] net: dsa: mv88e6xxx: defautl to multicast and unicast flooding
From: Russell King @ 2019-02-17 14:25 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Vivien Didelot; +Cc: David S. Miller, netdev
In-Reply-To: <20190217142414.cjtmpi5y2l5rtdlb@shell.armlinux.org.uk>
Switches work by learning the MAC address for each attached station by
monitoring traffic from each station. When a station sends a packet,
the switch records which port the MAC address is connected to.
With IPv4 networking, before communication commences with a neighbour,
an ARP packet is broadcasted to all stations asking for the MAC address
corresponding with the IPv4. The desired station responds with an ARP
reply, and the ARP reply causes the switch to learn which port the
station is connected to.
With IPv6 networking, the situation is rather different. Rather than
broadcasting ARP packets, a "neighbour solicitation" is multicasted
rather than broadcasted. This multicast needs to reach the intended
station in order for the neighbour to be discovered.
Once a neighbour has been discovered, and entered into the sending
stations neighbour cache, communication can restart at a point later
without sending a new neighbour solicitation, even if the entry in
the neighbour cache is marked as stale. This can be after the MAC
address has expired from the forwarding cache of the DSA switch -
when that occurs, there is a long pause in communication.
Our DSA implementation for mv88e6xxx switches has defaulted to having
multicast and unicast flooding disabled. As per the above description,
this is fine for IPv4 networking, since the broadcasted ARP queries
will be sent to and received by all stations on the same network.
However, this breaks IPv6 very badly - blocking neighbour solicitations
and later causing connections to stall.
The defaults that the Linux bridge code expect from bridges are that
unknown unicast frames and unknown multicast frames are flooded to
all stations, which is at odds to the defaults adopted by our DSA
implementation for mv88e6xxx switches.
This commit enables by default flooding of both unknown unicast and
unknown multicast frames. This means that mv88e6xxx DSA switches now
behave as per the bridge(8) man page, and IPv6 works flawlessly through
such a switch.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/dsa/mv88e6xxx/chip.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index b75a865a293d..eb5e3d88374f 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2144,13 +2144,14 @@ static int mv88e6xxx_setup_message_port(struct mv88e6xxx_chip *chip, int port)
static int mv88e6xxx_setup_egress_floods(struct mv88e6xxx_chip *chip, int port)
{
struct dsa_switch *ds = chip->ds;
- bool flood;
- /* Upstream ports flood frames with unknown unicast or multicast DA */
- flood = dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port);
+ /* Linux bridges are expected to flood unknown multicast and
+ * unicast frames to all ports - as per the defaults specified
+ * in the iproute2 bridge(8) man page. Not doing this causes
+ * stalls and failures with IPv6 over Marvell bridges. */
if (chip->info->ops->port_set_egress_floods)
return chip->info->ops->port_set_egress_floods(chip, port,
- flood, flood);
+ true, true);
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v3 net-next 0/2] clean up SOCK_DEBUG()
From: Yafang Shao @ 2019-02-17 14:26 UTC (permalink / raw)
To: davem
Cc: daniel, edumazet, joe, xiyou.wangcong, netdev, shaoyafang,
Yafang Shao
Per discussion with Daniel[1] and Eric[2], these SOCK_DEBUG() calles in
TCP are not needed now.
We'd better clean up it.
Plus undefine SOCK_DEBUGGING by default.
[1] https://patchwork.ozlabs.org/patch/1035573/
[2] https://patchwork.ozlabs.org/patch/1040533/
Yafang Shao (2):
tcp: clean up SOCK_DEBUG()
net: sock: undefine SOCK_DEBUGGING
include/net/sock.h | 13 ++++++++-----
net/core/sock.c | 3 +++
net/ipv4/tcp_input.c | 19 +------------------
net/ipv6/tcp_ipv6.c | 2 --
4 files changed, 12 insertions(+), 25 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH v3 net-next 1/2] tcp: clean up SOCK_DEBUG()
From: Yafang Shao @ 2019-02-17 14:26 UTC (permalink / raw)
To: davem
Cc: daniel, edumazet, joe, xiyou.wangcong, netdev, shaoyafang,
Yafang Shao
In-Reply-To: <1550413592-7877-1-git-send-email-laoar.shao@gmail.com>
Per discussion with Daniel[1] and Eric[2], these SOCK_DEBUG() calles in
TCP are not needed now.
We'd better clean up it.
[1] https://patchwork.ozlabs.org/patch/1035573/
[2] https://patchwork.ozlabs.org/patch/1040533/
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
---
net/ipv4/tcp_input.c | 19 +------------------
net/ipv6/tcp_ipv6.c | 2 --
2 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 7a027dec..6d2750e 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3595,7 +3595,7 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
* this segment (RFC793 Section 3.9).
*/
if (after(ack, tp->snd_nxt))
- goto invalid_ack;
+ return -1;
if (after(ack, prior_snd_una)) {
flag |= FLAG_SND_UNA_ADVANCED;
@@ -3714,10 +3714,6 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
tcp_process_tlp_ack(sk, ack, flag);
return 1;
-invalid_ack:
- SOCK_DEBUG(sk, "Ack %u after %u:%u\n", ack, tp->snd_una, tp->snd_nxt);
- return -1;
-
old_ack:
/* If data was SACKed, tag it and see if we should send more data.
* If data was DSACKed, see if we can undo a cwnd reduction.
@@ -3731,7 +3727,6 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
tcp_xmit_recovery(sk, rexmit);
}
- SOCK_DEBUG(sk, "Ack %u before %u:%u\n", ack, tp->snd_una, tp->snd_nxt);
return 0;
}
@@ -4432,13 +4427,9 @@ static void tcp_ofo_queue(struct sock *sk)
rb_erase(&skb->rbnode, &tp->out_of_order_queue);
if (unlikely(!after(TCP_SKB_CB(skb)->end_seq, tp->rcv_nxt))) {
- SOCK_DEBUG(sk, "ofo packet was already received\n");
tcp_drop(sk, skb);
continue;
}
- SOCK_DEBUG(sk, "ofo requeuing : rcv_next %X seq %X - %X\n",
- tp->rcv_nxt, TCP_SKB_CB(skb)->seq,
- TCP_SKB_CB(skb)->end_seq);
tail = skb_peek_tail(&sk->sk_receive_queue);
eaten = tail && tcp_try_coalesce(sk, tail, skb, &fragstolen);
@@ -4502,8 +4493,6 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPOFOQUEUE);
seq = TCP_SKB_CB(skb)->seq;
end_seq = TCP_SKB_CB(skb)->end_seq;
- SOCK_DEBUG(sk, "out of order segment: rcv_next %X seq %X - %X\n",
- tp->rcv_nxt, seq, end_seq);
p = &tp->out_of_order_queue.rb_node;
if (RB_EMPTY_ROOT(&tp->out_of_order_queue)) {
@@ -4779,10 +4768,6 @@ static void tcp_data_queue(struct sock *sk, struct sk_buff *skb)
if (before(TCP_SKB_CB(skb)->seq, tp->rcv_nxt)) {
/* Partial packet, seq < rcv_next < end_seq */
- SOCK_DEBUG(sk, "partial packet: rcv_next %X seq %X - %X\n",
- tp->rcv_nxt, TCP_SKB_CB(skb)->seq,
- TCP_SKB_CB(skb)->end_seq);
-
tcp_dsack_set(sk, TCP_SKB_CB(skb)->seq, tp->rcv_nxt);
/* If window is closed, drop tail of packet. But after
@@ -5061,8 +5046,6 @@ static int tcp_prune_queue(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
- SOCK_DEBUG(sk, "prune_queue: c=%x\n", tp->copied_seq);
-
NET_INC_STATS(sock_net(sk), LINUX_MIB_PRUNECALLED);
if (atomic_read(&sk->sk_rmem_alloc) >= sk->sk_rcvbuf)
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index e51cda7..57ef69a1 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -220,8 +220,6 @@ static int tcp_v6_connect(struct sock *sk, struct sockaddr *uaddr,
u32 exthdrlen = icsk->icsk_ext_hdr_len;
struct sockaddr_in sin;
- SOCK_DEBUG(sk, "connect: ipv4 mapped\n");
-
if (__ipv6_only_sock(sk))
return -ENETUNREACH;
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 net-next 2/2] net: sock: undefine SOCK_DEBUGGING
From: Yafang Shao @ 2019-02-17 14:26 UTC (permalink / raw)
To: davem
Cc: daniel, edumazet, joe, xiyou.wangcong, netdev, shaoyafang,
Yafang Shao
In-Reply-To: <1550413592-7877-1-git-send-email-laoar.shao@gmail.com>
SOCK_DEBUG() is a old facility for debugging.
If the user want to use it for debugging, the user must modify the
application first, that doesn't seem like a good way.
Now we have more powerful facilities, i.e. bpf or tracepoint, for this kind
of debugging purpose.
So we'd better disable it by default.
The reason why I don't remove it comepletely is that someone may still
would like to use it for debugging.
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
Suggested-by: Joe Perches <joe@perches.com>
---
include/net/sock.h | 13 ++++++++-----
net/core/sock.c | 3 +++
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 6679f3c..444e92f 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -81,14 +81,17 @@
*/
/* Define this to get the SOCK_DBG debugging facility. */
-#define SOCK_DEBUGGING
+/* #define SOCK_DEBUGGING */
#ifdef SOCK_DEBUGGING
-#define SOCK_DEBUG(sk, msg...) do { if ((sk) && sock_flag((sk), SOCK_DBG)) \
- printk(KERN_DEBUG msg); } while (0)
+#define SOCK_DEBUG(sk, fmt, ...) \
+do { \
+ if ((sk) && sock_flag((sk), SOCK_DBG)) \
+ printk(KERN_DEBUG fmt, ##__VA_ARGS__); \
+} while (0)
#else
/* Validate arguments and do nothing */
-static inline __printf(2, 3)
-void SOCK_DEBUG(const struct sock *sk, const char *msg, ...)
+__printf(2, 3)
+static inline void SOCK_DEBUG(const struct sock *sk, const char *fmt, ...)
{
}
#endif
diff --git a/net/core/sock.c b/net/core/sock.c
index 71ded4d..7c15835 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -753,6 +753,9 @@ int sock_setsockopt(struct socket *sock, int level, int optname,
switch (optname) {
case SO_DEBUG:
+ /* This option takes effect only when SOCK_DEBUGGING
+ * is defined.
+ */
if (val && !capable(CAP_NET_ADMIN))
ret = -EACCES;
else
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: defautl to multicast and unicast flooding
From: Russell King - ARM Linux admin @ 2019-02-17 14:27 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Vivien Didelot; +Cc: David S. Miller, netdev
In-Reply-To: <E1gvNNd-0006YN-Rc@rmk-PC.armlinux.org.uk>
On Sun, Feb 17, 2019 at 02:25:17PM +0000, Russell King wrote:
> Switches work by learning the MAC address for each attached station by
> monitoring traffic from each station. When a station sends a packet,
> the switch records which port the MAC address is connected to.
>
> With IPv4 networking, before communication commences with a neighbour,
> an ARP packet is broadcasted to all stations asking for the MAC address
> corresponding with the IPv4. The desired station responds with an ARP
> reply, and the ARP reply causes the switch to learn which port the
> station is connected to.
>
> With IPv6 networking, the situation is rather different. Rather than
> broadcasting ARP packets, a "neighbour solicitation" is multicasted
> rather than broadcasted. This multicast needs to reach the intended
> station in order for the neighbour to be discovered.
>
> Once a neighbour has been discovered, and entered into the sending
> stations neighbour cache, communication can restart at a point later
> without sending a new neighbour solicitation, even if the entry in
> the neighbour cache is marked as stale. This can be after the MAC
> address has expired from the forwarding cache of the DSA switch -
> when that occurs, there is a long pause in communication.
>
> Our DSA implementation for mv88e6xxx switches has defaulted to having
> multicast and unicast flooding disabled. As per the above description,
> this is fine for IPv4 networking, since the broadcasted ARP queries
> will be sent to and received by all stations on the same network.
> However, this breaks IPv6 very badly - blocking neighbour solicitations
> and later causing connections to stall.
>
> The defaults that the Linux bridge code expect from bridges are that
> unknown unicast frames and unknown multicast frames are flooded to
> all stations, which is at odds to the defaults adopted by our DSA
> implementation for mv88e6xxx switches.
>
> This commit enables by default flooding of both unknown unicast and
> unknown multicast frames. This means that mv88e6xxx DSA switches now
> behave as per the bridge(8) man page, and IPv6 works flawlessly through
> such a switch.
Note that there is the open question whether this affects the case where
each port is used as a separate network interface: that case has not yet
been tested.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> drivers/net/dsa/mv88e6xxx/chip.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> index b75a865a293d..eb5e3d88374f 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -2144,13 +2144,14 @@ static int mv88e6xxx_setup_message_port(struct mv88e6xxx_chip *chip, int port)
> static int mv88e6xxx_setup_egress_floods(struct mv88e6xxx_chip *chip, int port)
> {
> struct dsa_switch *ds = chip->ds;
> - bool flood;
>
> - /* Upstream ports flood frames with unknown unicast or multicast DA */
> - flood = dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port);
> + /* Linux bridges are expected to flood unknown multicast and
> + * unicast frames to all ports - as per the defaults specified
> + * in the iproute2 bridge(8) man page. Not doing this causes
> + * stalls and failures with IPv6 over Marvell bridges. */
> if (chip->info->ops->port_set_egress_floods)
> return chip->info->ops->port_set_egress_floods(chip, port,
> - flood, flood);
> + true, true);
>
> return 0;
> }
> --
> 2.7.4
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: stmmac / meson8b-dwmac
From: Martin Blumenstingl @ 2019-02-17 14:48 UTC (permalink / raw)
To: Jose Abreu
Cc: Simon Huelck, Emiliano Ingrassia, Gpeppe.cavallaro,
alexandre.torgue, linux-amlogic, netdev
In-Reply-To: <330a523a-c1d6-4a99-3287-459096af0330@synopsys.com>
Hello Jose,
On Mon, Feb 11, 2019 at 2:45 PM Jose Abreu <jose.abreu@synopsys.com> wrote:
>
> Hello,
>
> On 2/9/2019 1:09 AM, Martin Blumenstingl wrote:
> > (it's interesting that the sending direction has 445 retries)
>
> I saw this before and I think it was related with COE. Can you
> please disable all offloading and try again?
OK, details are:
(before doing anything)
# ethtool -k eth0
Features for eth0:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: on
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: on
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
tx-tcp-segmentation: off [fixed]
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp-mangleid-segmentation: off [fixed]
tx-tcp6-segmentation: off [fixed]
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]
this causes retries when running iperf3 in transmit mode.
with offloading disabled:
# ethtool -K eth0 rx off tx off
# ethtool -k eth0
Features for eth0:
rx-checksumming: off
tx-checksumming: off
tx-checksum-ipv4: off
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: off
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
tx-tcp-segmentation: off [fixed]
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp-mangleid-segmentation: off [fixed]
tx-tcp6-segmentation: off [fixed]
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]
# iperf3 -c 192.168.1.100
Connecting to host 192.168.1.100, port 5201
[ 5] local 192.168.1.131 port 58412 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 112 MBytes 937 Mbits/sec 32 59.4 KBytes
[ 5] 1.00-2.00 sec 112 MBytes 937 Mbits/sec 25 290 KBytes
[ 5] 2.00-3.00 sec 109 MBytes 915 Mbits/sec 150 279 KBytes
[ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 0 334 KBytes
[ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 0 342 KBytes
[ 5] 5.00-6.00 sec 111 MBytes 934 Mbits/sec 98 320 KBytes
[ 5] 6.00-7.00 sec 111 MBytes 929 Mbits/sec 123 76.4 KBytes
[ 5] 7.00-8.00 sec 109 MBytes 917 Mbits/sec 119 277 KBytes
[ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 0 314 KBytes
[ 5] 9.00-10.00 sec 112 MBytes 940 Mbits/sec 0 318 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.09 GBytes 933 Mbits/sec 547 sender
[ 5] 0.00-10.04 sec 1.09 GBytes 929 Mbits/sec receiver
iperf Done.
so for me disabling offloading didn't change anything.
Jose, is my command for disabling offloading correct?
Simon, does disabling offloading improve anything in your iperf2 or
real-world scenario on a kernel where you previously had performance
issues?
Regards
Martin
^ permalink raw reply
* Re: [PATCH v3 perf,bpf 08/11] perf, bpf: save btf information as headers to perf.data
From: Namhyung Kim @ 2019-02-17 14:58 UTC (permalink / raw)
To: Song Liu
Cc: Network Development, linux-kernel, Alexei Starovoitov,
Daniel Borkmann, kernel-team, Peter Zijlstra,
Arnaldo Carvalho de Melo, Jiri Olsa
In-Reply-To: <20190215215354.3114006-9-songliubraving@fb.com>
Hi,
On Sat, Feb 16, 2019 at 6:55 AM Song Liu <songliubraving@fb.com> wrote:
>
> This patch enables perf-record to save btf information as headers to
> perf.data A new header type HEADER_BTF is introduced for this data.
>
> Signed-off-by: Song Liu <songliubraving@fb.com>
> ---
[SNIP]
> +static void print_btf(struct feat_fd *ff, FILE *fp)
> +{
> + struct perf_env *env = &ff->ph->env;
> + struct rb_root *root;
> + struct rb_node *next;
> +
> + down_read(&env->bpf_progs.bpf_info_lock);
> +
> + root = &env->bpf_progs.btfs;
> + next = rb_first(root);
> +
> + while (next) {
> + struct btf_node *node;
> +
> + node = rb_entry(next, struct btf_node, rb_node);
> + next = rb_next(&node->rb_node);
> + fprintf(fp, "# bpf_prog_info of id %u\n", node->id);
How about saying it's "btf" info?
Thanks,
Namhyung
> + }
> +
> + up_read(&env->bpf_progs.bpf_info_lock);
> +}
^ permalink raw reply
* No traffic with Marvell switch and latest linux-next
From: Heiner Kallweit @ 2019-02-17 15:34 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Russell King - ARM Linux
Cc: netdev@vger.kernel.org
When testing latest linux-next on the ZII DTU I face the issue that no
traffic is flowing over the switch ports, even though in dmesg
everything looks good. Also PHY properly establishes the link.
With 4.20.10 I don't have the issue and with 5.0-rc6 also not.
However on 5.0-rc6 I got the following, also number of network
interrupts seems to be very high (few minutes after boot).
Any idea what's going on?
Andrew, IIRC you recently fixed some interrupt-related issue:
7ae710f9f8b2 ("gpio: vf610: Mask all GPIO interrupts")
But the description doesn't seem to match this trace.
irq 56: nobody cared (try booting with the "irqpoll" option)
CPU: 0 PID: 577 Comm: irq/38-400d1000 Not tainted 5.0.0-rc6 #1
Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
[<8010c898>] (unwind_backtrace) from [<8010ad98>] (show_stack+0x10/0x14)
[<8010ad98>] (show_stack) from [<80149660>] (__report_bad_irq+0x38/0xb0)
[<80149660>] (__report_bad_irq) from [<80149478>] (note_interrupt+0x10c/0x294)
[<80149478>] (note_interrupt) from [<80149cac>] (handle_nested_irq+0xd8/0xf4)
[<80149cac>] (handle_nested_irq) from [<80384a64>] (mv88e6xxx_g2_irq_thread_fn+0x90/0xc0)
[<80384a64>] (mv88e6xxx_g2_irq_thread_fn) from [<80149c60>] (handle_nested_irq+0x8c/0xf4)
[<80149c60>] (handle_nested_irq) from [<8037ccd0>] (mv88e6xxx_g1_irq_thread_work+0x98/0xcc)
[<8037ccd0>] (mv88e6xxx_g1_irq_thread_work) from [<80147ff4>] (irq_thread_fn+0x1c/0x78)
[<80147ff4>] (irq_thread_fn) from [<80148280>] (irq_thread+0x124/0x1cc)
[<80148280>] (irq_thread) from [<8012f8e8>] (kthread+0x140/0x148)
[<8012f8e8>] (kthread) from [<801010e8>] (ret_from_fork+0x14/0x2c)
Exception stack(0x9f6c7fb0 to 0x9f6c7ff8)
7fa0: 00000000 00000000 00000000 00000000
7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7fe0: 00000000 00000000 00000000 00000000 00000013 00000000
handlers:
[<b09c70df>] irq_default_primary_handler threaded [<44d6803f>] phy_interrupt
Disabling IRQ #56
36: 2030566 mscm-ir 79 Edge 400d1000.ethernet
38: 1010437 gpio-vf610 2 Level 400d1000.ethernet-1:00
42: 0 mv88e6xxx-g1 3 Edge mv88e6xxx-g1-atu-prob
44: 0 mv88e6xxx-g1 5 Edge mv88e6xxx-g1-vtu-prob
46: 1010435 mv88e6xxx-g1 7 Edge mv88e6xxx-g2
49: 0 mv88e6xxx-g2 1 Edge mv88e6xxx-1:01
53: 0 mv88e6xxx-g2 5 Edge mv88e6xxx-1:05
54: 0 mv88e6xxx-g2 6 Edge mv88e6xxx-1:06
56: 100000 mv88e6xxx-g2 8 Edge mv88e6xxx-1:08
63: 0 mv88e6xxx-g2 15 Edge mv88e6xxx-watchdog
Heiner
^ permalink raw reply
* Re: No traffic with Marvell switch and latest linux-next
From: Russell King - ARM Linux admin @ 2019-02-17 15:40 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Andrew Lunn, Florian Fainelli, netdev@vger.kernel.org
In-Reply-To: <0907f213-df83-4bb8-8fad-21b1dedaeca5@gmail.com>
On Sun, Feb 17, 2019 at 04:34:32PM +0100, Heiner Kallweit wrote:
> When testing latest linux-next on the ZII DTU I face the issue that no
> traffic is flowing over the switch ports, even though in dmesg
> everything looks good. Also PHY properly establishes the link.
>
> With 4.20.10 I don't have the issue and with 5.0-rc6 also not.
> However on 5.0-rc6 I got the following, also number of network
> interrupts seems to be very high (few minutes after boot).
> Any idea what's going on?
>
> Andrew, IIRC you recently fixed some interrupt-related issue:
> 7ae710f9f8b2 ("gpio: vf610: Mask all GPIO interrupts")
> But the description doesn't seem to match this trace.
I have a fix for the trace you have below, but it has nothing to do
with no traffic. I'll send it out shortly.
Which protocol are you using (ipv4 or ipv6)? Have you setup a
bridge device containing the ports you wish to switch network
traffic. Without a bridge device, DSA will by default treat each
port as a separate port. The other thing that gets people is the
ethernet interface connected to the DSA switch must be up _before_
bringing up any of the switch ports.
>
> irq 56: nobody cared (try booting with the "irqpoll" option)
> CPU: 0 PID: 577 Comm: irq/38-400d1000 Not tainted 5.0.0-rc6 #1
> Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
> [<8010c898>] (unwind_backtrace) from [<8010ad98>] (show_stack+0x10/0x14)
> [<8010ad98>] (show_stack) from [<80149660>] (__report_bad_irq+0x38/0xb0)
> [<80149660>] (__report_bad_irq) from [<80149478>] (note_interrupt+0x10c/0x294)
> [<80149478>] (note_interrupt) from [<80149cac>] (handle_nested_irq+0xd8/0xf4)
> [<80149cac>] (handle_nested_irq) from [<80384a64>] (mv88e6xxx_g2_irq_thread_fn+0x90/0xc0)
> [<80384a64>] (mv88e6xxx_g2_irq_thread_fn) from [<80149c60>] (handle_nested_irq+0x8c/0xf4)
> [<80149c60>] (handle_nested_irq) from [<8037ccd0>] (mv88e6xxx_g1_irq_thread_work+0x98/0xcc)
> [<8037ccd0>] (mv88e6xxx_g1_irq_thread_work) from [<80147ff4>] (irq_thread_fn+0x1c/0x78)
> [<80147ff4>] (irq_thread_fn) from [<80148280>] (irq_thread+0x124/0x1cc)
> [<80148280>] (irq_thread) from [<8012f8e8>] (kthread+0x140/0x148)
> [<8012f8e8>] (kthread) from [<801010e8>] (ret_from_fork+0x14/0x2c)
> Exception stack(0x9f6c7fb0 to 0x9f6c7ff8)
> 7fa0: 00000000 00000000 00000000 00000000
> 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> handlers:
> [<b09c70df>] irq_default_primary_handler threaded [<44d6803f>] phy_interrupt
> Disabling IRQ #56
>
>
> 36: 2030566 mscm-ir 79 Edge 400d1000.ethernet
> 38: 1010437 gpio-vf610 2 Level 400d1000.ethernet-1:00
> 42: 0 mv88e6xxx-g1 3 Edge mv88e6xxx-g1-atu-prob
> 44: 0 mv88e6xxx-g1 5 Edge mv88e6xxx-g1-vtu-prob
> 46: 1010435 mv88e6xxx-g1 7 Edge mv88e6xxx-g2
> 49: 0 mv88e6xxx-g2 1 Edge mv88e6xxx-1:01
> 53: 0 mv88e6xxx-g2 5 Edge mv88e6xxx-1:05
> 54: 0 mv88e6xxx-g2 6 Edge mv88e6xxx-1:06
> 56: 100000 mv88e6xxx-g2 8 Edge mv88e6xxx-1:08
> 63: 0 mv88e6xxx-g2 15 Edge mv88e6xxx-watchdog
>
> Heiner
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: No traffic with Marvell switch and latest linux-next
From: Andrew Lunn @ 2019-02-17 15:45 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Florian Fainelli, Russell King - ARM Linux,
netdev@vger.kernel.org
In-Reply-To: <0907f213-df83-4bb8-8fad-21b1dedaeca5@gmail.com>
On Sun, Feb 17, 2019 at 04:34:32PM +0100, Heiner Kallweit wrote:
> When testing latest linux-next on the ZII DTU I face the issue that no
> traffic is flowing over the switch ports, even though in dmesg
> everything looks good. Also PHY properly establishes the link.
Hi Heiner
Do you have
commit b79555d5d8d32643e9d7193341dcaff13bf9ffcd
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date: Tue Feb 12 19:56:15 2019 +0100
net: phy: fix interrupt handling in non-started states
Andrew
^ permalink raw reply
* Re: No traffic with Marvell switch and latest linux-next
From: Heiner Kallweit @ 2019-02-17 15:48 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, Russell King - ARM Linux,
netdev@vger.kernel.org
In-Reply-To: <20190217154501.GB5968@lunn.ch>
On 17.02.2019 16:45, Andrew Lunn wrote:
> On Sun, Feb 17, 2019 at 04:34:32PM +0100, Heiner Kallweit wrote:
>> When testing latest linux-next on the ZII DTU I face the issue that no
>> traffic is flowing over the switch ports, even though in dmesg
>> everything looks good. Also PHY properly establishes the link.
>
> Hi Heiner
>
> Do you have
>
> commit b79555d5d8d32643e9d7193341dcaff13bf9ffcd
> Author: Heiner Kallweit <hkallweit1@gmail.com>
> Date: Tue Feb 12 19:56:15 2019 +0100
>
> net: phy: fix interrupt handling in non-started states
>
In linux-next from Feb 15th this patch is included already.
> Andrew
>
Heiner
^ permalink raw reply
* Re: No traffic with Marvell switch and latest linux-next
From: Heiner Kallweit @ 2019-02-17 15:50 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, Florian Fainelli, netdev@vger.kernel.org
In-Reply-To: <20190217154026.tykxexcndx7l5urk@shell.armlinux.org.uk>
On 17.02.2019 16:40, Russell King - ARM Linux admin wrote:
> On Sun, Feb 17, 2019 at 04:34:32PM +0100, Heiner Kallweit wrote:
>> When testing latest linux-next on the ZII DTU I face the issue that no
>> traffic is flowing over the switch ports, even though in dmesg
>> everything looks good. Also PHY properly establishes the link.
>>
>> With 4.20.10 I don't have the issue and with 5.0-rc6 also not.
>> However on 5.0-rc6 I got the following, also number of network
>> interrupts seems to be very high (few minutes after boot).
>> Any idea what's going on?
>>
>> Andrew, IIRC you recently fixed some interrupt-related issue:
>> 7ae710f9f8b2 ("gpio: vf610: Mask all GPIO interrupts")
>> But the description doesn't seem to match this trace.
>
> I have a fix for the trace you have below, but it has nothing to do
> with no traffic. I'll send it out shortly.
>
> Which protocol are you using (ipv4 or ipv6)? Have you setup a
> bridge device containing the ports you wish to switch network
> traffic. Without a bridge device, DSA will by default treat each
> port as a separate port. The other thing that gets people is the
> ethernet interface connected to the DSA switch must be up _before_
> bringing up any of the switch ports.
>
ipv4, a simple ping. No bridge. Device is connected to a switch
that is always on.
Technical environment and userspace is always the same, so it seems
to be the kernel version.
>>
>> irq 56: nobody cared (try booting with the "irqpoll" option)
>> CPU: 0 PID: 577 Comm: irq/38-400d1000 Not tainted 5.0.0-rc6 #1
>> Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
>> [<8010c898>] (unwind_backtrace) from [<8010ad98>] (show_stack+0x10/0x14)
>> [<8010ad98>] (show_stack) from [<80149660>] (__report_bad_irq+0x38/0xb0)
>> [<80149660>] (__report_bad_irq) from [<80149478>] (note_interrupt+0x10c/0x294)
>> [<80149478>] (note_interrupt) from [<80149cac>] (handle_nested_irq+0xd8/0xf4)
>> [<80149cac>] (handle_nested_irq) from [<80384a64>] (mv88e6xxx_g2_irq_thread_fn+0x90/0xc0)
>> [<80384a64>] (mv88e6xxx_g2_irq_thread_fn) from [<80149c60>] (handle_nested_irq+0x8c/0xf4)
>> [<80149c60>] (handle_nested_irq) from [<8037ccd0>] (mv88e6xxx_g1_irq_thread_work+0x98/0xcc)
>> [<8037ccd0>] (mv88e6xxx_g1_irq_thread_work) from [<80147ff4>] (irq_thread_fn+0x1c/0x78)
>> [<80147ff4>] (irq_thread_fn) from [<80148280>] (irq_thread+0x124/0x1cc)
>> [<80148280>] (irq_thread) from [<8012f8e8>] (kthread+0x140/0x148)
>> [<8012f8e8>] (kthread) from [<801010e8>] (ret_from_fork+0x14/0x2c)
>> Exception stack(0x9f6c7fb0 to 0x9f6c7ff8)
>> 7fa0: 00000000 00000000 00000000 00000000
>> 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000
>> handlers:
>> [<b09c70df>] irq_default_primary_handler threaded [<44d6803f>] phy_interrupt
>> Disabling IRQ #56
>>
>>
>> 36: 2030566 mscm-ir 79 Edge 400d1000.ethernet
>> 38: 1010437 gpio-vf610 2 Level 400d1000.ethernet-1:00
>> 42: 0 mv88e6xxx-g1 3 Edge mv88e6xxx-g1-atu-prob
>> 44: 0 mv88e6xxx-g1 5 Edge mv88e6xxx-g1-vtu-prob
>> 46: 1010435 mv88e6xxx-g1 7 Edge mv88e6xxx-g2
>> 49: 0 mv88e6xxx-g2 1 Edge mv88e6xxx-1:01
>> 53: 0 mv88e6xxx-g2 5 Edge mv88e6xxx-1:05
>> 54: 0 mv88e6xxx-g2 6 Edge mv88e6xxx-1:06
>> 56: 100000 mv88e6xxx-g2 8 Edge mv88e6xxx-1:08
>> 63: 0 mv88e6xxx-g2 15 Edge mv88e6xxx-watchdog
>>
>> Heiner
>>
>
^ permalink raw reply
* Re: No traffic with Marvell switch and latest linux-next
From: Andrew Lunn @ 2019-02-17 15:51 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Florian Fainelli, Russell King - ARM Linux,
netdev@vger.kernel.org
In-Reply-To: <0907f213-df83-4bb8-8fad-21b1dedaeca5@gmail.com>
> 36: 2030566 mscm-ir 79 Edge 400d1000.ethernet
> 38: 1010437 gpio-vf610 2 Level 400d1000.ethernet-1:00
> 42: 0 mv88e6xxx-g1 3 Edge mv88e6xxx-g1-atu-prob
> 44: 0 mv88e6xxx-g1 5 Edge mv88e6xxx-g1-vtu-prob
> 46: 1010435 mv88e6xxx-g1 7 Edge mv88e6xxx-g2
> 49: 0 mv88e6xxx-g2 1 Edge mv88e6xxx-1:01
> 53: 0 mv88e6xxx-g2 5 Edge mv88e6xxx-1:05
> 54: 0 mv88e6xxx-g2 6 Edge mv88e6xxx-1:06
> 56: 100000 mv88e6xxx-g2 8 Edge mv88e6xxx-1:08
> 63: 0 mv88e6xxx-g2 15 Edge mv88e6xxx-watchdog
The PHY for Port 8 is not clearing its interrupt. In fact, it is not
even saying to the kernel it had an interrupt. After 100,000 interrupts
which nobody claimed, the kernel just disables it. So this looks like
your fix:
- if (!phy_is_started(phydev))
- return IRQ_NONE;
I think this went into net first. So it takes a little while to make
it into net-next. Maybe you don't have it yet?
Andrew
^ permalink raw reply
* Re: No traffic with Marvell switch and latest linux-next
From: Heiner Kallweit @ 2019-02-17 15:55 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, Russell King - ARM Linux,
netdev@vger.kernel.org
In-Reply-To: <20190217155148.GC5968@lunn.ch>
On 17.02.2019 16:51, Andrew Lunn wrote:
>> 36: 2030566 mscm-ir 79 Edge 400d1000.ethernet
>> 38: 1010437 gpio-vf610 2 Level 400d1000.ethernet-1:00
>> 42: 0 mv88e6xxx-g1 3 Edge mv88e6xxx-g1-atu-prob
>> 44: 0 mv88e6xxx-g1 5 Edge mv88e6xxx-g1-vtu-prob
>> 46: 1010435 mv88e6xxx-g1 7 Edge mv88e6xxx-g2
>> 49: 0 mv88e6xxx-g2 1 Edge mv88e6xxx-1:01
>> 53: 0 mv88e6xxx-g2 5 Edge mv88e6xxx-1:05
>> 54: 0 mv88e6xxx-g2 6 Edge mv88e6xxx-1:06
>> 56: 100000 mv88e6xxx-g2 8 Edge mv88e6xxx-1:08
>> 63: 0 mv88e6xxx-g2 15 Edge mv88e6xxx-watchdog
>
> The PHY for Port 8 is not clearing its interrupt. In fact, it is not
> even saying to the kernel it had an interrupt. After 100,000 interrupts
> which nobody claimed, the kernel just disables it. So this looks like
> your fix:
>
> - if (!phy_is_started(phydev))
> - return IRQ_NONE;
>
> I think this went into net first. So it takes a little while to make
> it into net-next. Maybe you don't have it yet?
>
I have it. And the root cause seems to be another one as Russell
mentioned he has a fix for the trace.
> Andrew
>
Heiner
^ permalink raw reply
* Re: No traffic with Marvell switch and latest linux-next
From: Andrew Lunn @ 2019-02-17 15:57 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Florian Fainelli, Russell King - ARM Linux,
netdev@vger.kernel.org
In-Reply-To: <9f2ca596-4310-7b55-1be6-bc1db1789edd@gmail.com>
> In linux-next from Feb 15th this patch is included already.
So why is port 8 not clearing its interrupt?
Maybe put a printk in m88e1121_did_interrupt(),
marvell_ack_interrupt(), and marvell_config_intr() and see if they are
getting called.
Andrew
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox