* Re: [PATCH v2 net-next] net/tcp: trace all TCP/IP state transition with tcp_set_state tracepoint
From: Song Liu @ 2017-12-04 17:49 UTC (permalink / raw)
To: Yafang Shao
Cc: David Miller, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org,
Steven Rostedt, Brendan Gregg, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1512207401-3154-1-git-send-email-laoar.shao@gmail.com>
> On Dec 2, 2017, at 1:36 AM, Yafang Shao <laoar.shao@gmail.com> wrote:
>
> The TCP/IP transition from TCP_LISTEN to TCP_SYN_RECV and some other
> transitions are not traced with tcp_set_state tracepoint.
>
> In order to trace the whole tcp lifespans, two helpers are introduced,
> void __tcp_set_state(struct sock *sk, int state)
> void __sk_state_store(struct sock *sk, int newstate)
>
> When do TCP/IP state transition, we should use these two helpers or use
> tcp_set_state() other than assigning a value to sk_state directly.
>
> Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
>
> ---
> v2: test
> ---
> include/net/tcp.h | 2 ++
> net/ipv4/inet_connection_sock.c | 6 +++---
> net/ipv4/inet_hashtables.c | 2 +-
> net/ipv4/tcp.c | 12 ++++++++++++
> 4 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 85ea578..4f2d015 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -1247,6 +1247,8 @@ static inline bool tcp_checksum_complete(struct sk_buff *skb)
> "Close Wait","Last ACK","Listen","Closing"
> };
> #endif
> +void __sk_state_store(struct sock *sk, int newstate);
> +void __tcp_set_state(struct sock *sk, int state);
> void tcp_set_state(struct sock *sk, int state);
>
> void tcp_done(struct sock *sk);
> diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
> index 4ca46dc..f3967f1 100644
> --- a/net/ipv4/inet_connection_sock.c
> +++ b/net/ipv4/inet_connection_sock.c
> @@ -783,7 +783,7 @@ struct sock *inet_csk_clone_lock(const struct sock *sk,
> if (newsk) {
> struct inet_connection_sock *newicsk = inet_csk(newsk);
>
> - newsk->sk_state = TCP_SYN_RECV;
> + __tcp_set_state(newsk, TCP_SYN_RECV);
> newicsk->icsk_bind_hash = NULL;
>
> inet_sk(newsk)->inet_dport = inet_rsk(req)->ir_rmt_port;
> @@ -877,7 +877,7 @@ int inet_csk_listen_start(struct sock *sk, int backlog)
> * It is OK, because this socket enters to hash table only
> * after validation is complete.
> */
> - sk_state_store(sk, TCP_LISTEN);
> + __sk_state_store(sk, TCP_LISTEN);
> if (!sk->sk_prot->get_port(sk, inet->inet_num)) {
> inet->inet_sport = htons(inet->inet_num);
>
> @@ -888,7 +888,7 @@ int inet_csk_listen_start(struct sock *sk, int backlog)
> return 0;
> }
>
> - sk->sk_state = TCP_CLOSE;
> + __tcp_set_state(sk, TCP_CLOSE);
> return err;
> }
> EXPORT_SYMBOL_GPL(inet_csk_listen_start);
> diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
> index e7d15fb..72c15b6 100644
> --- a/net/ipv4/inet_hashtables.c
> +++ b/net/ipv4/inet_hashtables.c
> @@ -430,7 +430,7 @@ bool inet_ehash_nolisten(struct sock *sk, struct sock *osk)
> sock_prot_inuse_add(sock_net(sk), sk->sk_prot, 1);
> } else {
> percpu_counter_inc(sk->sk_prot->orphan_count);
> - sk->sk_state = TCP_CLOSE;
> + __tcp_set_state(sk, TCP_CLOSE);
> sock_set_flag(sk, SOCK_DEAD);
> inet_csk_destroy_sock(sk);
> }
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index bf97317..2bc7e04 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -2036,6 +2036,18 @@ int tcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, int nonblock,
> }
> EXPORT_SYMBOL(tcp_recvmsg);
>
> +void __sk_state_store(struct sock *sk, int newstate)
> +{
> + trace_tcp_set_state(sk, sk->sk_state, newstate);
> + sk_state_store(sk, newstate);
> +}
> +
> +void __tcp_set_state(struct sock *sk, int state)
> +{
> + trace_tcp_set_state(sk, sk->sk_state, state);
> + sk->sk_state = state;
> +}
> +
> void tcp_set_state(struct sock *sk, int state)
> {
> int oldstate = sk->sk_state;
> --
> 1.8.3.1
>
Asked-by: Song Liu <songliubraving@fb.com>
^ permalink raw reply
* [PATCH 7/7 v2] net: fjes: Fix platform_get_irq's error checking
From: Arvind Yadav @ 2017-12-04 17:48 UTC (permalink / raw)
To: wg, mkl, michal.simek, opendmb, f.fainelli, davem
Cc: linux-kernel, linux-arm-kernel, netdev
In-Reply-To: <1512409703-20881-1-git-send-email-arvind.yadav.cs@gmail.com>
platform_get_irq() can fail here and we must check its return value.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
changes in v2:
commit message was not correct.
drivers/net/fjes/fjes_main.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/fjes/fjes_main.c b/drivers/net/fjes/fjes_main.c
index 750954b..af7204b 100644
--- a/drivers/net/fjes/fjes_main.c
+++ b/drivers/net/fjes/fjes_main.c
@@ -1268,6 +1268,11 @@ static int fjes_probe(struct platform_device *plat_dev)
hw->hw_res.start = res->start;
hw->hw_res.size = resource_size(res);
hw->hw_res.irq = platform_get_irq(plat_dev, 0);
+ if (hw->hw_res.irq <= 0) {
+ err = hw->hw_res.irq ? hw->hw_res.irq : -ENODEV;
+ goto err_free_netdev;
+ }
+
err = fjes_hw_init(&adapter->hw);
if (err)
goto err_free_netdev;
--
2.7.4
^ permalink raw reply related
* [PATCH 6/7 v2] net: ethernet: smsc: Fix platform_get_irq's error checking
From: Arvind Yadav @ 2017-12-04 17:48 UTC (permalink / raw)
To: wg, mkl, michal.simek, opendmb, f.fainelli, davem
Cc: linux-kernel, linux-arm-kernel, netdev
In-Reply-To: <1512409703-20881-1-git-send-email-arvind.yadav.cs@gmail.com>
platform_get_irq() can fail here and we must check its return value.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
changes in v2:
commit message was not correct.
drivers/net/ethernet/smsc/smc911x.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/smsc/smc911x.c b/drivers/net/ethernet/smsc/smc911x.c
index 0515744..5e3c7af 100644
--- a/drivers/net/ethernet/smsc/smc911x.c
+++ b/drivers/net/ethernet/smsc/smc911x.c
@@ -2088,6 +2088,11 @@ static int smc911x_drv_probe(struct platform_device *pdev)
ndev->dma = (unsigned char)-1;
ndev->irq = platform_get_irq(pdev, 0);
+ if (ndev->irq <= 0) {
+ ret = ndev->irq ? ndev->irq : -ENODEV;
+ goto release_both;
+ }
+
lp = netdev_priv(ndev);
lp->netdev = ndev;
#ifdef SMC_DYNAMIC_BUS_CONFIG
--
2.7.4
^ permalink raw reply related
* [PATCH 5/7 v2] net: ethernet: natsemi: Fix platform_get_irq's error checking
From: Arvind Yadav @ 2017-12-04 17:48 UTC (permalink / raw)
To: wg, mkl, michal.simek, opendmb, f.fainelli, davem
Cc: linux-kernel, linux-arm-kernel, netdev
In-Reply-To: <1512409703-20881-1-git-send-email-arvind.yadav.cs@gmail.com>
platform_get_irq() can fail here and we must check its return value.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
changes in v2:
commit message was not correct.
drivers/net/ethernet/natsemi/jazzsonic.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/natsemi/jazzsonic.c b/drivers/net/ethernet/natsemi/jazzsonic.c
index d5b2888..22424e9 100644
--- a/drivers/net/ethernet/natsemi/jazzsonic.c
+++ b/drivers/net/ethernet/natsemi/jazzsonic.c
@@ -242,6 +242,11 @@ static int jazz_sonic_probe(struct platform_device *pdev)
dev->base_addr = res->start;
dev->irq = platform_get_irq(pdev, 0);
+ if (dev->irq <= 0) {
+ err = dev->irq ? dev->irq : -ENODEV;
+ goto out;
+ }
+
err = sonic_probe1(dev);
if (err)
goto out;
--
2.7.4
^ permalink raw reply related
* [PATCH 4/7 v2] net: ethernet: i825xx: Fix platform_get_irq's error checking
From: Arvind Yadav @ 2017-12-04 17:48 UTC (permalink / raw)
To: wg, mkl, michal.simek, opendmb, f.fainelli, davem
Cc: netdev, linux-kernel, linux-arm-kernel
In-Reply-To: <1512409703-20881-1-git-send-email-arvind.yadav.cs@gmail.com>
The platform_get_irq() function returns negative number if an error
occurs, Zero if No irq is found and positive number if irq gets successful.
platform_get_irq() error checking only for zero is not correct.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
changes in v2:
commit message was not correct.
drivers/net/ethernet/i825xx/sni_82596.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/i825xx/sni_82596.c b/drivers/net/ethernet/i825xx/sni_82596.c
index b2c04a7..f2a11fc 100644
--- a/drivers/net/ethernet/i825xx/sni_82596.c
+++ b/drivers/net/ethernet/i825xx/sni_82596.c
@@ -120,9 +120,10 @@ static int sni_82596_probe(struct platform_device *dev)
netdevice->dev_addr[5] = readb(eth_addr + 0x06);
iounmap(eth_addr);
- if (!netdevice->irq) {
+ if (netdevice->irq <= 0) {
printk(KERN_ERR "%s: IRQ not found for i82596 at 0x%lx\n",
__FILE__, netdevice->base_addr);
+ retval = netdevice->irq ? netdevice->irq : -ENODEV;
goto probe_failed;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 3/7 v2] can: xilinx: Fix platform_get_irq's error checking
From: Arvind Yadav @ 2017-12-04 17:48 UTC (permalink / raw)
To: wg, mkl, michal.simek, opendmb, f.fainelli, davem
Cc: netdev, linux-kernel, linux-arm-kernel
In-Reply-To: <1512409703-20881-1-git-send-email-arvind.yadav.cs@gmail.com>
platform_get_irq() can fail here and we must check its return value.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
changes in v2:
commit message was not correct.
drivers/net/can/xilinx_can.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
index 89aec07..1b859af 100644
--- a/drivers/net/can/xilinx_can.c
+++ b/drivers/net/can/xilinx_can.c
@@ -1111,6 +1111,10 @@ static int xcan_probe(struct platform_device *pdev)
/* Get IRQ for the device */
ndev->irq = platform_get_irq(pdev, 0);
+ if (ndev->irq <= 0) {
+ ret = ndev->irq ? ndev->irq : -ENODEV;
+ goto err_free;
+ }
ndev->flags |= IFF_ECHO; /* We support local echo */
platform_set_drvdata(pdev, ndev);
--
2.7.4
^ permalink raw reply related
* [PATCH 2/7 v2] net: ezchip: nps_enet: Fix platform_get_irq's error checking
From: Arvind Yadav @ 2017-12-04 17:48 UTC (permalink / raw)
To: wg, mkl, michal.simek, opendmb, f.fainelli, davem
Cc: linux-kernel, linux-arm-kernel, netdev
In-Reply-To: <1512409703-20881-1-git-send-email-arvind.yadav.cs@gmail.com>
The platform_get_irq() function returns negative number if an error
occurs, Zero if No irq is found and positive number if irq gets successful.
platform_get_irq() error checking only for zero is not correct.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
changes in v2:
commit message was not correct.
drivers/net/ethernet/ezchip/nps_enet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ezchip/nps_enet.c b/drivers/net/ethernet/ezchip/nps_enet.c
index 659f1ad..7d4b628 100644
--- a/drivers/net/ethernet/ezchip/nps_enet.c
+++ b/drivers/net/ethernet/ezchip/nps_enet.c
@@ -623,9 +623,9 @@ static s32 nps_enet_probe(struct platform_device *pdev)
/* Get IRQ number */
priv->irq = platform_get_irq(pdev, 0);
- if (!priv->irq) {
+ if (priv->irq <= 0) {
dev_err(dev, "failed to retrieve <irq Rx-Tx> value from device tree\n");
- err = -ENODEV;
+ err = priv->irq ? priv->irq : -ENODEV;
goto out_netdev;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 1/7 v2] net: bcmgenet: Fix platform_get_irq's error checking
From: Arvind Yadav @ 2017-12-04 17:48 UTC (permalink / raw)
To: wg, mkl, michal.simek, opendmb, f.fainelli, davem
Cc: linux-kernel, linux-arm-kernel, netdev
In-Reply-To: <1512409703-20881-1-git-send-email-arvind.yadav.cs@gmail.com>
The platform_get_irq() function returns negative number if an error occurs,
Zero if No irq is found and positive number if irq gets successful.
platform_get_irq() error checking only for zero is not correct.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
changes in v2:
commit message was not correct.
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index 24b4f4c..e2f1268 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -3371,7 +3371,7 @@ static int bcmgenet_probe(struct platform_device *pdev)
priv->irq0 = platform_get_irq(pdev, 0);
priv->irq1 = platform_get_irq(pdev, 1);
priv->wol_irq = platform_get_irq(pdev, 2);
- if (!priv->irq0 || !priv->irq1) {
+ if (priv->irq0 <= 0 || priv->irq1 <= 0 || priv->wol_irq <= 0) {
dev_err(&pdev->dev, "can't find IRQs\n");
err = -EINVAL;
goto err;
--
2.7.4
^ permalink raw reply related
* [PATCH 0/7 v2] net: Fix platform_get_irq's error checking
From: Arvind Yadav @ 2017-12-04 17:48 UTC (permalink / raw)
To: wg, mkl, michal.simek, opendmb, f.fainelli, davem
Cc: linux-kernel, linux-arm-kernel, netdev
The platform_get_irq() function returns negative number if an error
occurs, Zero if No irq is found and positive number if irq gets successful.
platform_get_irq() error checking for only zero is not correct.
Removed Other 3 patch which is not related to this series.
Arvind Yadav (7):
[PATCH 1/7 v2] net: bcmgenet: Fix platform_get_irq's error checking
[PATCH 2/7 v2] net: ezchip: nps_enet: Fix platform_get_irq's error checking
[PATCH 3/7 v2] can: xilinx: Fix platform_get_irq's error checking
[PATCH 4/7 v2] net: ethernet: i825xx: Fix platform_get_irq's error checking
[PATCH 5/7 v2] net: ethernet: natsemi: Fix platform_get_irq's error checking
[PATCH 6/7 v2] net: ethernet: smsc: Fix platform_get_irq's error checking
[PATCH 7/7 v2] net: fjes: Fix platform_get_irq's error checking
drivers/net/can/xilinx_can.c | 4 ++++
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 2 +-
drivers/net/ethernet/ezchip/nps_enet.c | 4 ++--
drivers/net/ethernet/i825xx/sni_82596.c | 3 ++-
drivers/net/ethernet/natsemi/jazzsonic.c | 5 +++++
drivers/net/ethernet/smsc/smc911x.c | 5 +++++
drivers/net/fjes/fjes_main.c | 5 +++++
7 files changed, 24 insertions(+), 4 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH] net: sh_eth: do not advertise Gigabit capabilities when not available
From: Sergei Shtylyov @ 2017-12-04 17:42 UTC (permalink / raw)
To: Thomas Petazzoni, David S. Miller, Niklas Söderlund,
Geert Uytterhoeven, Simon Horman
Cc: netdev, linux-renesas-soc
In-Reply-To: <20171204141346.17410-1-thomas.petazzoni@free-electrons.com>
On 12/04/2017 05:13 PM, Thomas Petazzoni wrote:
> Not all variants of the sh_eth hardware have Gigabit
> support. Unfortunately, the current driver doesn't update
> phydev->supported depending on the MAC capabilities. Due to this, if
> you have a Gigabit capable PHY, the PHY will advertise its Gigabit
> capability and establish a link at 1Gbit/s, even though the MAC
> doesn't support it.
>
> In order to avoid this, we mark phydev->supported if we're running a
> non-Gigabit capable hardware.
>
> Tested on a SH7786 platform, with a Gigabit PHY.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> drivers/net/ethernet/renesas/sh_eth.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> index db72d13cebb9..0074c5998481 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
> @@ -1892,6 +1892,11 @@ static int sh_eth_phy_init(struct net_device *ndev)
> return PTR_ERR(phydev);
> }
>
> + /* mask with MAC supported features */
> + if (mdp->cd->register_type != SH_ETH_REG_GIGABIT)
> + phydev->supported &= PHY_BASIC_FEATURES;
> + phydev->advertising = phydev->supported;
> +
Um, looking at this again, I think we have phy_set_max_speed() for that
kind of stuff now...
[...]
MBR, Sergei
^ permalink raw reply
* Re: pull-request: bpf-next 2017-12-03
From: David Miller @ 2017-12-04 17:42 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <20171203010001.1230-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Sun, 3 Dec 2017 02:00:01 +0100
> The following pull-request contains BPF updates for your *net-next*
> tree.
Pulled, I'll push this back out after some build testing completes.
Thank you.
^ permalink raw reply
* [PATCH net-next 1/5] net: dsa: mv88e6xxx: egress floods all DSA ports
From: Vivien Didelot @ 2017-12-04 17:34 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Vivien Didelot
In-Reply-To: <20171204173457.14873-1-vivien.didelot@savoirfairelinux.com>
The mv88e6xxx driver currently assumes a single CPU port in the fabric
and thus floods frames with unknown DA on a single DSA port, the one
that is one hop closer to the CPU port.
With multiple CPU ports in mind, this isn't true anymore because CPU
ports could be found behind both DSA ports of a device in-between
others.
For example in a A <-> B <-> C fabric, both A and C having CPU ports,
device B will have to flood such frame to its two DSA ports.
This patch considers both CPU and DSA ports of a device as upstream
ports, where to flood frames with unknown DA addresses.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index b5e0987c88f0..15475dbb738b 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -1723,7 +1723,8 @@ static int mv88e6xxx_setup_message_port(struct mv88e6xxx_chip *chip, int port)
static int mv88e6xxx_setup_egress_floods(struct mv88e6xxx_chip *chip, int port)
{
- bool flood = port == dsa_upstream_port(chip->ds);
+ struct dsa_switch *ds = chip->ds;
+ bool flood = dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port);
/* Upstream ports flood frames with unknown unicast or multicast DA */
if (chip->info->ops->port_set_egress_floods)
--
2.15.1
^ permalink raw reply related
* [PATCH net-next 3/5] net: dsa: mv88e6xxx: setup global upstream port
From: Vivien Didelot @ 2017-12-04 17:34 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Vivien Didelot
In-Reply-To: <20171204173457.14873-1-vivien.didelot@savoirfairelinux.com>
Move the setup of the global upstream port within the
mv88e6xxx_setup_upstream_port function.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 29 ++++++++++++++++-------------
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 3dce1ab19582..5de8596b01ad 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -1756,6 +1756,22 @@ static int mv88e6xxx_setup_upstream_port(struct mv88e6xxx_chip *chip, int port)
return err;
}
+ if (port == upstream_port) {
+ if (chip->info->ops->set_cpu_port) {
+ err = chip->info->ops->set_cpu_port(chip,
+ upstream_port);
+ if (err)
+ return err;
+ }
+
+ if (chip->info->ops->set_egress_port) {
+ err = chip->info->ops->set_egress_port(chip,
+ upstream_port);
+ if (err)
+ return err;
+ }
+ }
+
return 0;
}
@@ -1957,21 +1973,8 @@ static int mv88e6xxx_set_ageing_time(struct dsa_switch *ds,
static int mv88e6xxx_g1_setup(struct mv88e6xxx_chip *chip)
{
struct dsa_switch *ds = chip->ds;
- u32 upstream_port = dsa_upstream_port(ds);
int err;
- if (chip->info->ops->set_cpu_port) {
- err = chip->info->ops->set_cpu_port(chip, upstream_port);
- if (err)
- return err;
- }
-
- if (chip->info->ops->set_egress_port) {
- err = chip->info->ops->set_egress_port(chip, upstream_port);
- if (err)
- return err;
- }
-
/* Disable remote management, and set the switch's DSA device number. */
err = mv88e6xxx_g1_write(chip, MV88E6XXX_G1_CTL2,
MV88E6XXX_G1_CTL2_MULTIPLE_CASCADE |
--
2.15.1
^ permalink raw reply related
* [PATCH net-next 5/5] net: dsa: return per-port upstream port
From: Vivien Didelot @ 2017-12-04 17:34 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Vivien Didelot
In-Reply-To: <20171204173457.14873-1-vivien.didelot@savoirfairelinux.com>
The current dsa_upstream_port() helper still assumes a unique CPU port
in the whole switch fabric. This is becoming wrong, as every port in the
fabric has its dedicated CPU port, thus every port has an upstream port.
Add a port argument to the dsa_upstream_port() helper and fetch its CPU
port instead of the deprecated unique fabric CPU port. A CPU or unused
port has no dedicated CPU port, so return itself in this case.
At the same time, change the return value from u8 to unsigned int since
there is no need to limit the size here.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
include/net/dsa.h | 9 ++++++---
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 5de8596b01ad..fe4881795906 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -1746,7 +1746,7 @@ static int mv88e6xxx_serdes_power(struct mv88e6xxx_chip *chip, int port,
static int mv88e6xxx_setup_upstream_port(struct mv88e6xxx_chip *chip, int port)
{
struct dsa_switch *ds = chip->ds;
- int upstream_port = dsa_upstream_port(ds);
+ int upstream_port = dsa_upstream_port(ds, port);
int err;
if (chip->info->ops->port_set_upstream_port) {
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 8198efcc8ced..d29feccaefab 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -307,10 +307,13 @@ static inline unsigned int dsa_towards_port(struct dsa_switch *ds, int device,
}
/* Return the local port used to reach the dedicated CPU port */
-static inline u8 dsa_upstream_port(struct dsa_switch *ds)
+static inline unsigned int dsa_upstream_port(struct dsa_switch *ds, int port)
{
- struct dsa_switch_tree *dst = ds->dst;
- struct dsa_port *cpu_dp = dst->cpu_dp;
+ const struct dsa_port *dp = dsa_to_port(ds, port);
+ const struct dsa_port *cpu_dp = dp->cpu_dp;
+
+ if (!cpu_dp)
+ return port;
return dsa_towards_port(ds, cpu_dp->ds->index, cpu_dp->index);
}
--
2.15.1
^ permalink raw reply related
* [PATCH net-next 4/5] net: dsa: assign a CPU port to DSA port
From: Vivien Didelot @ 2017-12-04 17:34 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Vivien Didelot
In-Reply-To: <20171204173457.14873-1-vivien.didelot@savoirfairelinux.com>
DSA ports also need to have a dedicated CPU port assigned to them,
because they need to know where to egress frames targeting the CPU,
e.g. To_Cpu frames received on a Marvell Tag port.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
net/dsa/dsa2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index 1e287420ff49..21f9bed11988 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -241,7 +241,7 @@ static int dsa_tree_setup_default_cpu(struct dsa_switch_tree *dst)
for (port = 0; port < ds->num_ports; port++) {
dp = &ds->ports[port];
- if (dsa_port_is_user(dp))
+ if (dsa_port_is_user(dp) || dsa_port_is_dsa(dp))
dp->cpu_dp = dst->cpu_dp;
}
}
--
2.15.1
^ permalink raw reply related
* [PATCH net-next 2/5] net: dsa: mv88e6xxx: helper to setup upstream port
From: Vivien Didelot @ 2017-12-04 17:34 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Vivien Didelot
In-Reply-To: <20171204173457.14873-1-vivien.didelot@savoirfairelinux.com>
Add a helper function to setup the upstream port of a given port.
This is the port used to reach the dedicated CPU port. This function
will be extended later to setup the global upstream port as well.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 26 +++++++++++++++++++-------
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 15475dbb738b..3dce1ab19582 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -1743,6 +1743,22 @@ static int mv88e6xxx_serdes_power(struct mv88e6xxx_chip *chip, int port,
return 0;
}
+static int mv88e6xxx_setup_upstream_port(struct mv88e6xxx_chip *chip, int port)
+{
+ struct dsa_switch *ds = chip->ds;
+ int upstream_port = dsa_upstream_port(ds);
+ int err;
+
+ if (chip->info->ops->port_set_upstream_port) {
+ err = chip->info->ops->port_set_upstream_port(chip, port,
+ upstream_port);
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
static int mv88e6xxx_setup_port(struct mv88e6xxx_chip *chip, int port)
{
struct dsa_switch *ds = chip->ds;
@@ -1813,13 +1829,9 @@ static int mv88e6xxx_setup_port(struct mv88e6xxx_chip *chip, int port)
if (err)
return err;
- reg = 0;
- if (chip->info->ops->port_set_upstream_port) {
- err = chip->info->ops->port_set_upstream_port(
- chip, port, dsa_upstream_port(ds));
- if (err)
- return err;
- }
+ err = mv88e6xxx_setup_upstream_port(chip, port);
+ if (err)
+ return err;
err = mv88e6xxx_port_set_8021q_mode(chip, port,
MV88E6XXX_PORT_CTL2_8021Q_MODE_DISABLED);
--
2.15.1
^ permalink raw reply related
* [PATCH net-next 0/5] net: dsa: use per-port upstream port
From: Vivien Didelot @ 2017-12-04 17:34 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Vivien Didelot
An upstream port is a local switch port used to reach a CPU port.
DSA still considers a unique CPU port in the whole switch fabric and
thus return a unique upstream port for a given switch. This is wrong in
a multiple CPU ports environment.
We are now switching to using the dedicated CPU port assigned to each
port in order to get rid of the deprecated unique tree CPU port.
This patchset makes the dsa_upstream_port() helper take a port argument
and goes one step closer complete support for multiple CPU ports.
Vivien Didelot (5):
net: dsa: mv88e6xxx: egress floods all DSA ports
net: dsa: mv88e6xxx: helper to setup upstream port
net: dsa: mv88e6xxx: setup global upstream port
net: dsa: assign a CPU port to DSA port
net: dsa: return per-port upstream port
drivers/net/dsa/mv88e6xxx/chip.c | 58 +++++++++++++++++++++++++---------------
include/net/dsa.h | 9 ++++---
net/dsa/dsa2.c | 2 +-
3 files changed, 44 insertions(+), 25 deletions(-)
--
2.15.1
^ permalink raw reply
* Re: [PATCH 2/2] net: sh_eth: don't use NULL as "struct device" for the DMA mapping API
From: Sergei Shtylyov @ 2017-12-04 17:30 UTC (permalink / raw)
To: Thomas Petazzoni, David S. Miller, Niklas Söderlund,
Geert Uytterhoeven, Simon Horman
Cc: netdev, linux-renesas-soc
In-Reply-To: <20171204133327.3505-3-thomas.petazzoni@free-electrons.com>
On 12/04/2017 04:33 PM, Thomas Petazzoni wrote:
> Using NULL as argument for the DMA mapping API is bogus, as the DMA
> mapping API may use information from the "struct device" to perform
> the DMA mapping operation. Therefore, pass the appropriate "struct
> device".
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH iproute2 net-next] gre6: add collect metadata support
From: Gregory Rose @ 2017-12-04 17:26 UTC (permalink / raw)
To: William Tu, netdev
In-Reply-To: <1512169407-5588-1-git-send-email-u9012063@gmail.com>
On 12/1/2017 3:03 PM, William Tu wrote:
> The patch adds 'external' option to support collect metadata
> gre6 tunnel. Example of L3 and L2 gre device:
> bash:~# ip link add dev ip6gre123 type ip6gre external
> bash:~# ip link add dev ip6gretap123 type ip6gretap external
Hi William,
one question. Is there ever actually going to be a situation in which
an ipv6 gre tunnel will go from
external to not external? I'm wondering if the "no external" option is
really needed since default is
no and I'm not sure under what circumstances a tunnel would go from
external to not external.
Thanks,
- Greg
>
> Signed-off-by: William Tu <u9012063@gmail.com>
> ---
> ip/link_gre6.c | 55 ++++++++++++++++++++++++++++++++-------------------
> man/man8/ip-link.8.in | 6 ++++++
> 2 files changed, 41 insertions(+), 20 deletions(-)
>
> diff --git a/ip/link_gre6.c b/ip/link_gre6.c
> index 0a82eaecf2cd..2cb46ca116d0 100644
> --- a/ip/link_gre6.c
> +++ b/ip/link_gre6.c
> @@ -105,6 +105,7 @@ static int gre_parse_opt(struct link_util *lu, int argc, char **argv,
> __u16 encapflags = TUNNEL_ENCAP_FLAG_CSUM6;
> __u16 encapsport = 0;
> __u16 encapdport = 0;
> + __u8 metadata = 0;
> int len;
> __u32 fwmark = 0;
> __u32 erspan_idx = 0;
> @@ -178,6 +179,9 @@ get_failed:
> if (greinfo[IFLA_GRE_ENCAP_SPORT])
> encapsport = rta_getattr_u16(greinfo[IFLA_GRE_ENCAP_SPORT]);
>
> + if (greinfo[IFLA_GRE_COLLECT_METADATA])
> + metadata = 1;
> +
> if (greinfo[IFLA_GRE_ENCAP_DPORT])
> encapdport = rta_getattr_u16(greinfo[IFLA_GRE_ENCAP_DPORT]);
>
> @@ -355,6 +359,8 @@ get_failed:
> encapflags |= TUNNEL_ENCAP_FLAG_REMCSUM;
> } else if (strcmp(*argv, "noencap-remcsum") == 0) {
> encapflags &= ~TUNNEL_ENCAP_FLAG_REMCSUM;
> + } else if (strcmp(*argv, "external") == 0) {
> + metadata = 1;
> } else if (strcmp(*argv, "fwmark") == 0) {
> NEXT_ARG();
> if (strcmp(*argv, "inherit") == 0) {
> @@ -388,26 +394,30 @@ get_failed:
> argc--; argv++;
> }
>
> - addattr32(n, 1024, IFLA_GRE_IKEY, ikey);
> - addattr32(n, 1024, IFLA_GRE_OKEY, okey);
> - addattr_l(n, 1024, IFLA_GRE_IFLAGS, &iflags, 2);
> - addattr_l(n, 1024, IFLA_GRE_OFLAGS, &oflags, 2);
> - addattr_l(n, 1024, IFLA_GRE_LOCAL, &laddr, sizeof(laddr));
> - addattr_l(n, 1024, IFLA_GRE_REMOTE, &raddr, sizeof(raddr));
> - if (link)
> - addattr32(n, 1024, IFLA_GRE_LINK, link);
> - addattr_l(n, 1024, IFLA_GRE_TTL, &hop_limit, 1);
> - addattr_l(n, 1024, IFLA_GRE_ENCAP_LIMIT, &encap_limit, 1);
> - addattr_l(n, 1024, IFLA_GRE_FLOWINFO, &flowinfo, 4);
> - addattr32(n, 1024, IFLA_GRE_FLAGS, flags);
> - addattr32(n, 1024, IFLA_GRE_FWMARK, fwmark);
> - if (erspan_idx != 0)
> - addattr32(n, 1024, IFLA_GRE_ERSPAN_INDEX, erspan_idx);
> -
> - addattr16(n, 1024, IFLA_GRE_ENCAP_TYPE, encaptype);
> - addattr16(n, 1024, IFLA_GRE_ENCAP_FLAGS, encapflags);
> - addattr16(n, 1024, IFLA_GRE_ENCAP_SPORT, htons(encapsport));
> - addattr16(n, 1024, IFLA_GRE_ENCAP_DPORT, htons(encapdport));
> + if (!metadata) {
> + addattr32(n, 1024, IFLA_GRE_IKEY, ikey);
> + addattr32(n, 1024, IFLA_GRE_OKEY, okey);
> + addattr_l(n, 1024, IFLA_GRE_IFLAGS, &iflags, 2);
> + addattr_l(n, 1024, IFLA_GRE_OFLAGS, &oflags, 2);
> + addattr_l(n, 1024, IFLA_GRE_LOCAL, &laddr, sizeof(laddr));
> + addattr_l(n, 1024, IFLA_GRE_REMOTE, &raddr, sizeof(raddr));
> + if (link)
> + addattr32(n, 1024, IFLA_GRE_LINK, link);
> + addattr_l(n, 1024, IFLA_GRE_TTL, &hop_limit, 1);
> + addattr_l(n, 1024, IFLA_GRE_ENCAP_LIMIT, &encap_limit, 1);
> + addattr_l(n, 1024, IFLA_GRE_FLOWINFO, &flowinfo, 4);
> + addattr32(n, 1024, IFLA_GRE_FLAGS, flags);
> + addattr32(n, 1024, IFLA_GRE_FWMARK, fwmark);
> + if (erspan_idx != 0)
> + addattr32(n, 1024, IFLA_GRE_ERSPAN_INDEX, erspan_idx);
> +
> + addattr16(n, 1024, IFLA_GRE_ENCAP_TYPE, encaptype);
> + addattr16(n, 1024, IFLA_GRE_ENCAP_FLAGS, encapflags);
> + addattr16(n, 1024, IFLA_GRE_ENCAP_SPORT, htons(encapsport));
> + addattr16(n, 1024, IFLA_GRE_ENCAP_DPORT, htons(encapdport));
> + } else {
> + addattr_l(n, 1024, IFLA_GRE_COLLECT_METADATA, NULL, 0);
> + }
>
> return 0;
> }
> @@ -426,6 +436,11 @@ static void gre_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
> if (!tb)
> return;
>
> + if (tb[IFLA_GRE_COLLECT_METADATA]) {
> + print_bool(PRINT_ANY, "collect_metadata", "external", true);
> + return;
> + }
> +
> if (tb[IFLA_GRE_FLAGS])
> flags = rta_getattr_u32(tb[IFLA_GRE_FLAGS]);
>
> diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
> index a6a10e577b1f..c9b9bb7b2a4e 100644
> --- a/man/man8/ip-link.8.in
> +++ b/man/man8/ip-link.8.in
> @@ -755,6 +755,8 @@ the following additional arguments are supported:
> .BI "dscp inherit"
> ] [
> .BI dev " PHYS_DEV "
> +] [
> +.RB [ no ] external
> ]
>
> .in +8
> @@ -833,6 +835,10 @@ or
> .IR 00 ".." ff
> when tunneling non-IP packets. The default value is 00.
>
> +.sp
> +.RB [ no ] external
> +- make this tunnel externally controlled (or not, which is the default).
> +
> .in -8
>
> .TP
^ permalink raw reply
* Re: [PATCH 1/2] net: sh_eth: use correct "struct device" when calling DMA mapping functions
From: Sergei Shtylyov @ 2017-12-04 17:24 UTC (permalink / raw)
To: Thomas Petazzoni, David S. Miller, Niklas Söderlund,
Geert Uytterhoeven, Simon Horman
Cc: netdev, linux-renesas-soc
In-Reply-To: <20171204133327.3505-2-thomas.petazzoni@free-electrons.com>
On 12/04/2017 04:33 PM, Thomas Petazzoni wrote:
> There are two types of "struct device": the one representing the
> physical device on its physical bus (platform, SPI, PCI, etc.), and
> the one representing the logical device in its device class (net,
> etc.).
>
> The DMA mapping API expects to receive as argument a "struct device"
> representing the physical device, as the "struct device" contains
> information about the bus that the DMA API needs.
>
> However, the sh_eth driver mistakenly uses the "struct device"
> representing the logical device (embedded in "struct net_device")
> rather than the "struct device" representing the physical device on
> its bus.
>
> This commit fixes that by adjusting all calls to the DMA mapping API.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
I'm still unsure the ravb driver doesn't have this issue...
[...]
MBR, Sergei
^ permalink raw reply
* Re: Linux network is damn fast, need more use XDP (Was: DC behaviors today)
From: Matthias Tafelmeier @ 2017-12-04 17:19 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Dave Taht
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Christina Jacob,
Joel Wirāmu Pauling,
cerowrt-devel-JXvr2/1DY2fm6VMwtOF2vx4hnT+Y9+D1@public.gmane.org,
bloat-JXvr2/1DY2fm6VMwtOF2vx4hnT+Y9+D1, David Ahern, Tariq Toukan
In-Reply-To: <20171204110923.3a213986-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1.1.1.1: Type: text/plain, Size: 1455 bytes --]
Hello,
> Scaling up to more CPUs and TCP-stream, Tariq[1] and I have showed the
> Linux kernel network stack scales to 94Gbit/s (linerate minus overhead).
> But when the drivers page-recycler fails, we hit bottlenecks in the
> page-allocator, that cause negative scaling to around 43Gbit/s.
>
> [1] http://lkml.kernel.org/r/cef85936-10b2-5d76-9f97-cb03b418fd94@mellanox.com
>
> Linux have for a _long_ time been doing 10Gbit/s TCP-stream easily, on
> a SINGLE CPU. This is mostly thanks to TSO/GRO aggregating packets,
> but last couple of years the network stack have been optimized (with
> UDP workloads), and as a result we can do 10G without TSO/GRO on a
> single-CPU. This is "only" 812Kpps with MTU size frames.
Cannot find the reference anymore, but there was once some workshop held
by you during some netdev where you were stating that you're practially
in rigorous exchange with NIC vendors as to having them tremendously
increase the RX/TX rings(queues) numbers. Further, that there are hardly
any limits to the number other than FPGA magic/physical HW - up to
millions is viable was coined back then. May I ask were this ended up?
Wouldn't that be key for massive parallelization either - With having a
queue(producer), a CPU (consumer) - vice versa - per flow at the
extreme? Did this end up in this SMART-NIC thingummy? The latter is
rather trageted at XDP, no?
--
Besten Gruß
Matthias Tafelmeier
[-- Attachment #1.1.1.2: 0x8ADF343B.asc --]
[-- Type: application/pgp-keys, Size: 4806 bytes --]
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 538 bytes --]
[-- Attachment #2: Type: text/plain, Size: 140 bytes --]
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
^ permalink raw reply
* RE: [PATCH INTERNAL V2 1/1] brcmfmac: add console log support with configurable read size
From: Li Jin @ 2017-12-04 17:11 UTC (permalink / raw)
To: Kalle Valo
Cc: Wright Feng, Chi-Hsien Lin, Hante Meuleman, Franky Lin,
Arend Van Spriel, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
brcm80211-dev-list-+wT8y+m8/X5BDgjK7y7TUQ, BRCM80211-DEV-LIST,PDL,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Jason Uy
In-Reply-To: <87o9nejzic.fsf-5ukZ45wKbUHoml4zekdYB16hYfS7NtTn@public.gmane.org>
Hi Kalle,
Apologies. The title of this patch should be EXTERNAL. I put down INTERNAL
by mistake.
Thanks!
Li
-----Original Message-----
From: Kalle Valo [mailto:kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org]
Sent: Monday, December 4, 2017 7:15 AM
To: Li Jin
Cc: Wright Feng; Chi-Hsien Lin; Hante Meuleman; Franky Lin; Arend van
Spriel; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
brcm80211-dev-list-+wT8y+m8/X5BDgjK7y7TUQ@public.gmane.org; brcm80211-dev-list.pdl-dY08KVG/lbpWk0Htik3J/w@public.gmane.org;
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Jason Uy
Subject: Re: [PATCH INTERNAL V2 1/1] brcmfmac: add console log support
with configurable read size
Li Jin <li.jin-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> writes:
> From: Jason Uy <jason.uy-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>
> Add support for configurable read size so that older wifi chips that
> have size restrictions can be supported.
>
> Signed-off-by: Jason Uy <jason.uy-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Ray Jui <ray.jui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Li Jin <li.jin-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Arend, am I supposed to apply this even if there's this "INTERNAL" tag in
the Subject?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/2] net: sh_eth: add support for SH7786
From: Sergei Shtylyov @ 2017-12-04 17:06 UTC (permalink / raw)
To: Thomas Petazzoni, David S. Miller, Niklas Söderlund,
Geert Uytterhoeven, Simon Horman
Cc: netdev, linux-renesas-soc
In-Reply-To: <4c0c70ac-6db2-7c8a-4e5e-9364919e5012@cogentembedded.com>
On 12/04/2017 07:56 PM, Sergei Shtylyov wrote:
>> This commit adds the sh_eth_cpu_data structure that describes the
>> SH7786 variant of the IP.
>
> The manual seems to be unavailable, so I have to trust you. :-)
>
>> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
I actually meant:
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> [...]
MBR, Sergei
^ permalink raw reply
* BPF: bug without effect in BPF_RSH case of adjust_scalar_min_max_vals()
From: Jann Horn @ 2017-12-04 17:03 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Edward Cree
Cc: Network Development, kernel list
As far as I can tell, commit b03c9f9fdc37 ("bpf/verifier: track signed
and unsigned min/max values") introduced the following effectless bug
in the BPF_RSH case of adjust_scalar_min_max_vals() (unless that's
intentional):
`dst_reg->smax_value` is only updated in the case where
`dst_reg->smin_value < 0` and `umin_val == 0`. This is obviously
harmless if `dst_reg->smax_value >= 0`, but if `dst_reg->smax_value <
0`, this will temporarily result in a state where the signed upper
bound of `dst_reg` is lower than the signed lower bound (which will be
set to 0). I don't think this should ever happen.
Luckily, this doesn't have any effect because of the
inter-representation information propagation that happens immediately
afterwards: __update_reg_bounds() neither modifies nor propagates the
incorrect `reg->smax_value` (the assignment is a no-op in this case),
then `__reg_deduce_bounds` takes the first branch and resets
`reg->smax_value` to `reg->umax_value`, which is correct.
To test this, I applied this patch to the kernel:
=======================
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index d4593571c404..bcf6a4aa25cd 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2205,8 +2205,10 @@ static int adjust_scalar_min_max_vals(struct
bpf_verifier_env *env,
dst_reg->var_off = tnum_rshift(tnum_unknown, umin_val);
dst_reg->umin_value >>= umax_val;
dst_reg->umax_value >>= umin_val;
+ pr_warn("BPF_RSH point A: smin=%lld, smax=%lld, umin=%llx,
umax=%llx, tribits=%llx, trimask=%llx\n", dst_reg->smin_value,
dst_reg->smax_value, dst_reg->umin_value, dst_reg->umax_value,
dst_reg->var_off.value, dst_reg->var_off.mask);
/* We may learn something more from the var_off */
__update_reg_bounds(dst_reg);
+ pr_warn("BPF_RSH point B: smin=%lld, smax=%lld, umin=%llx,
umax=%llx, tribits=%llx, trimask=%llx\n", dst_reg->smin_value,
dst_reg->smax_value, dst_reg->umin_value, dst_reg->umax_value,
dst_reg->var_off.value, dst_reg->var_off.mask);
break;
default:
mark_reg_unknown(env, regs, insn->dst_reg);
@@ -2214,7 +2216,11 @@ static int adjust_scalar_min_max_vals(struct
bpf_verifier_env *env,
}
__reg_deduce_bounds(dst_reg);
+ if (opcode == BPF_RSH)
+ pr_warn("BPF_RSH point C: smin=%lld, smax=%lld, umin=%llx,
umax=%llx, tribits=%llx, trimask=%llx\n", dst_reg->smin_value,
dst_reg->smax_value, dst_reg->umin_value, dst_reg->umax_value,
dst_reg->var_off.value, dst_reg->var_off.mask);
__reg_bound_offset(dst_reg);
+ if (opcode == BPF_RSH)
+ pr_warn("BPF_RSH point D: smin=%lld, smax=%lld, umin=%llx,
umax=%llx, tribits=%llx, trimask=%llx\n", dst_reg->smin_value,
dst_reg->smax_value, dst_reg->umin_value, dst_reg->umax_value,
dst_reg->var_off.value, dst_reg->var_off.mask);
return 0;
}
=======================
Then I attempted to load the following eBPF bytecode with verbosity level 2:
=======================
BPF_LD_MAP_FD(BPF_REG_ARG1, mapfd),
BPF_MOV64_REG(BPF_REG_TMP, BPF_REG_FP),
BPF_ALU64_IMM(BPF_ADD, BPF_REG_TMP, -4), // allocate 4 bytes stack
BPF_MOV32_IMM(BPF_REG_ARG2, 1),
BPF_STX_MEM(BPF_W, BPF_REG_TMP, BPF_REG_ARG2, 0),
BPF_MOV64_REG(BPF_REG_ARG2, BPF_REG_TMP),
BPF_EMIT_CALL(BPF_FUNC_map_lookup_elem),
BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, 2),
BPF_MOV64_REG(BPF_REG_0, 0), // prepare exit
BPF_EXIT_INSN(), // exit
BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_0, 0),
BPF_ALU64_IMM(BPF_AND, BPF_REG_3, 0xf),
BPF_MOV64_IMM(BPF_REG_1, -42),
BPF_ALU64_REG(BPF_ADD, BPF_REG_1, BPF_REG_3),
BPF_MOV64_IMM(BPF_REG_2, 2),
BPF_ALU64_REG(BPF_RSH, BPF_REG_1, BPF_REG_2),
BPF_EXIT_INSN()
=======================
dmesg output:
=======================
[ 145.423122] BPF_RSH point A: smin=0, smax=-27,
umin=3ffffffffffffff5, umax=3ffffffffffffff9,
tribits=3ffffffffffffff0, trimask=f
[ 145.423129] BPF_RSH point B: smin=4611686018427387888, smax=-27,
umin=3ffffffffffffff5, umax=3ffffffffffffff9,
tribits=3ffffffffffffff0, trimask=f
[ 145.423133] BPF_RSH point C: smin=4611686018427387893,
smax=4611686018427387897, umin=3ffffffffffffff5,
umax=3ffffffffffffff9, tribits=3ffffffffffffff0, trimask=f
[ 145.423136] BPF_RSH point D: smin=4611686018427387893,
smax=4611686018427387897, umin=3ffffffffffffff5,
umax=3ffffffffffffff9, tribits=3ffffffffffffff0, trimask=f
=======================
^ permalink raw reply related
* Re: [Bloat] Linux network is damn fast, need more use XDP (Was: DC behaviors today)
From: Dave Taht @ 2017-12-04 17:00 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev@vger.kernel.org, Christina Jacob, Joel Wirāmu Pauling,
cerowrt-devel@lists.bufferbloat.net, bloat, David Ahern,
Tariq Toukan
In-Reply-To: <20171204110923.3a213986@redhat.com>
Jesper:
I have a tendency to deal with netdev by itself and never cross post
there, as the bufferbloat.net servers (primarily to combat spam)
mandate starttls and vger doesn't support it at all, thus leading to
raising davem blood pressure which I'd rather not do.
But moving on...
On Mon, Dec 4, 2017 at 2:56 AM, Jesper Dangaard Brouer
<brouer@redhat.com> wrote:
>
> On Sun, 03 Dec 2017 20:19:33 -0800 Dave Taht <dave@taht.net> wrote:
>
>> Changing the topic, adding bloat.
>
> Adding netdev, and also adjust the topic to be a rant on that the Linux
> kernel network stack is actually damn fast, and if you need something
> faster then XDP can solved your needs...
>
>> Joel Wirāmu Pauling <joel@aenertia.net> writes:
>>
>> > Just from a Telco/Industry perspective slant.
>> >
>> > Everything in DC has moved to SFP28 interfaces at 25Gbit as the server
>> > port of interconnect. Everything TOR wise is now QSFP28 - 100Gbit.
>> > Mellanox X5 cards are the current hotness, and their offload
>> > enhancements (ASAP2 - which is sorta like DPDK on steroids) allows for
>> > OVS flow rules programming into the card. We have a lot of customers
>> > chomping at the bit for that feature (disclaimer I work for Nuage
>> > Networks, and we are working on enhanced OVS to do just that) for NFV
>> > workloads.
>>
>> What Jesper's been working on for ages has been to try and get linux's
>> PPS up for small packets, which last I heard was hovering at about
>> 4Gbits.
>
> I hope you made a typo here Dave, the normal Linux kernel is definitely
> way beyond 4Gbit/s, you must have misunderstood something, maybe you
> meant 40Gbit/s? (which is also too low)
The context here was PPS for *non-gro'd* tcp ack packets, in the
further context of
the increasingly epic "benefits of ack filtering" thread on the bloat
list, in the context
that for 50x1 end-user-asymmetry we were seeing 90% less acks with the new
sch_cake ack-filter code, double the throughput...
The kind of return traffic you see from data sent outside the DC, with
tons of flows.
What's that number?
>
> Scaling up to more CPUs and TCP-stream, Tariq[1] and I have showed the
> Linux kernel network stack scales to 94Gbit/s (linerate minus overhead).
> But when the drivers page-recycler fails, we hit bottlenecks in the
> page-allocator, that cause negative scaling to around 43Gbit/s.
So I divide by 94/22 and get 4gbit for acks. Or I look at PPS * 66. Or?
> [1] http://lkml.kernel.org/r/cef85936-10b2-5d76-9f97-cb03b418fd94@mellanox.com
>
> Linux have for a _long_ time been doing 10Gbit/s TCP-stream easily, on
> a SINGLE CPU. This is mostly thanks to TSO/GRO aggregating packets,
> but last couple of years the network stack have been optimized (with
> UDP workloads), and as a result we can do 10G without TSO/GRO on a
> single-CPU. This is "only" 812Kpps with MTU size frames.
acks.
> It is important to NOTICE that I'm mostly talking about SINGLE-CPU
> performance. But the Linux kernel scales very well to more CPUs, and
> you can scale this up, although we are starting to hit scalability
> issues in MM-land[1].
>
> I've also demonstrated that netdev-community have optimized the kernels
> per-CPU processing power to around 2Mpps. What does this really
> mean... well with MTU size packets 812Kpps was 10Gbit/s, thus 25Gbit/s
> should be around 2Mpps.... That implies Linux can do 25Gbit/s on a
> single CPU without GRO (MTU size frames). Do you need more I ask?
The benchmark I had in mind was, say, 100k flows going out over the internet,
and the characteristics of the ack flows on the return path.
>
>
>> The route table lookup also really expensive on the main cpu.
To clarify the context here, I was asking specifically if the X5 mellonox card
did routing table offlload or only switching.
> Well, it used-to-be very expensive. Vincent Bernat wrote some excellent
> blogposts[2][3] on the recent improvements over kernel versions, and
> gave due credit to people involved.
>
> [2] https://vincent.bernat.im/en/blog/2017-performance-progression-ipv4-route-lookup-linux
> [3] https://vincent.bernat.im/en/blog/2017-performance-progression-ipv6-route-lookup-linux
>
> He measured around 25 to 35 nanosec cost of route lookups. My own
> recent measurements were 36.9 ns cost of fib_table_lookup.
On intel hw.
>
>> Does this stuff offload the route table lookup also?
>
> If you have not heard, the netdev-community have worked on something
> called XDP (eXpress Data Path). This is a new layer in the network
> stack, that basically operates a the same "layer"/level as DPDK.
> Thus, surprise we get the same performance numbers as DPDK. E.g. I can
> do 13.4 Mpps forwarding with ixgbe on a single CPU (more CPUs=14.6Mps)
>
> We can actually use XDP for (software) offloading the Linux routing
> table. There are two methods we are experimenting with:
>
> (1) externally monitor route changes from userspace and update BPF-maps
> to reflect this. That approach is already accepted upstream[4][5]. I'm
> measuring 9,513,746 pps per CPU with that approach.
>
> (2) add a bpf helper to simply call fib_table_lookup() from the XDP hook.
> This is still experimental patches (credit to David Ahern), and I've
> measured 9,350,160 pps with this approach in a single CPU. Using more
> CPUs we hit 14.6Mpps (only used 3 CPUs in that test)
Neat. Perhaps trying xdp on the itty bitty routers I usually work on
would be a win.
quad arm cores are increasingy common there.
>
> [4] https://github.com/torvalds/linux/blob/master/samples/bpf/xdp_router_ipv4_user.c
> [5] https://github.com/torvalds/linux/blob/master/samples/bpf/xdp_router_ipv4_kern.c
thx very much for the update.
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> LinkedIn: http://www.linkedin.com/in/brouer
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
^ 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