* Re: [PATCHv2] net: cpsw: Add support for wake-on-lan for cpsw
From: Mugunthan V N @ 2013-08-19 11:39 UTC (permalink / raw)
To: ujhelyi.m; +Cc: davem, netdev, linux-kernel
In-Reply-To: <1376910358-19882-1-git-send-email-ujhelyi.m@gmail.com>
On Monday 19 August 2013 04:35 PM, ujhelyi.m@gmail.com wrote:
> From: Matus Ujhelyi <ujhelyi.m@gmail.com>
>
> Some phy's can be configured to enable wake on lan (e.g. at803x or marvell 88E1318S).
> There is no way how to enable wol on CPSW with such connected phys. This patch
> adds this support. It is provided by calling the phy's related code.
>
> Tested on board with at8030x connected phy. Wol interrupt line is
> connected to GPIO0 on am335x.
>
> Signed-off-by: Matus Ujhelyi <ujhelyi.m@gmail.com>
Looks good to me.
Acked-by: Mugunthan V N <mugunthanvnm@gmail.com>
Regards
Mugunthan V N
^ permalink raw reply
* Re: [PATCH ipsec v2 3/3] xfrm: choose protocol family by skb protocol
From: Steffen Klassert @ 2013-08-19 11:46 UTC (permalink / raw)
To: Hannes Frederic Sowa, netdev, edumazet
In-Reply-To: <20130818114701.GA10270@order.stressinduktion.org>
On Sun, Aug 18, 2013 at 01:47:01PM +0200, Hannes Frederic Sowa wrote:
> We need to choose the protocol family by skb->protocol. Otherwise we
> call the wrong xfrm{4,6}_local_error handler in case an ipv6 sockets is
> used in ipv4 mode, in which case we should call down to xfrm4_local_error
> (ip6 sockets are a superset of ip4 ones).
>
> We are called before before ip_output functions, so skb->protocol is
> not reset.
>
> v2:
> a) unchanged
>
> Cc: Steffen Klassert <steffen.klassert@secunet.com>
> Acked-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
All applied to the ipsec tree, thanks a lot!
^ permalink raw reply
* Re: [ PATCH net-next ] xfrm: remove irrelevant comment in xfrm_input().
From: Steffen Klassert @ 2013-08-19 11:47 UTC (permalink / raw)
To: Rami Rosen; +Cc: davem, netdev
In-Reply-To: <1376916431-8249-1-git-send-email-ramirose@gmail.com>
On Mon, Aug 19, 2013 at 03:47:11PM +0300, Rami Rosen wrote:
> This patch removes a comment in xfrm_input() which became irrelevant
> due to commit 2774c13, "xfrm: Handle blackhole route creation via afinfo".
> That commit removed returning -EREMOTE in the xfrm_lookup() method when the
> packet should be discarded and also removed the correspoinding -EREMOTE
> handlers. This was replaced by calling the make_blackhole() method. Therefore
> the comment about -EREMOTE is not relevant anymore.
>
> Signed-off-by: Rami Rosen <ramirose@gmail.com>
Applied to ipsec-next, thanks!
^ permalink raw reply
* Re: [PATCH] ipv6: handle Redirect ICMP Message with no Redirected Header option
From: Hannes Frederic Sowa @ 2013-08-19 11:55 UTC (permalink / raw)
To: Duan Jiong; +Cc: davem, netdev
In-Reply-To: <5211F97B.4090209@cn.fujitsu.com>
On Mon, Aug 19, 2013 at 06:54:51PM +0800, Duan Jiong wrote:
> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>
> rfc 4861 says the Redirected Header option is optional, so
> the kernel should not drop the Redirect Message that has no
> Redirected Header option. In this patch, the function
> ip6_redirect_no_header() is introduced to deal with that
> condition.
>
> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> ---
> include/net/ip6_route.h | 1 +
> net/ipv6/ndisc.c | 4 +++-
> net/ipv6/route.c | 21 +++++++++++++++++++++
> 3 files changed, 25 insertions(+), 1 deletions(-)
>
> diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
> index 260f83f..7966f54 100644
> --- a/include/net/ip6_route.h
> +++ b/include/net/ip6_route.h
> @@ -135,6 +135,7 @@ extern void ip6_update_pmtu(struct sk_buff *skb, struct net *net, __be32 mtu,
> extern void ip6_sk_update_pmtu(struct sk_buff *skb, struct sock *sk,
> __be32 mtu);
> extern void ip6_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark);
> +extern void ip6_redirect_no_header(struct sk_buff *skb, struct net *net, int oif, u32 mark);
> extern void ip6_sk_redirect(struct sk_buff *skb, struct sock *sk);
>
> struct netlink_callback;
> diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
> index 79aa965..04d31c2 100644
> --- a/net/ipv6/ndisc.c
> +++ b/net/ipv6/ndisc.c
> @@ -1369,8 +1369,10 @@ static void ndisc_redirect_rcv(struct sk_buff *skb)
> if (!ndisc_parse_options(msg->opt, ndoptlen, &ndopts))
> return;
>
> - if (!ndopts.nd_opts_rh)
> + if (!ndopts.nd_opts_rh) {
> + ip6_redirect_no_header(skb, dev_net(skb->dev), 0, 0);
> return;
> + }
Can't we just jump down to icmpv6_notify without introducing
ip6_redirect_no_header?
>
> hdr = (u8 *)ndopts.nd_opts_rh;
> hdr += 8;
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index b70f897..9934b87 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1178,6 +1178,27 @@ void ip6_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark)
> }
> EXPORT_SYMBOL_GPL(ip6_redirect);
>
> +void ip6_redirect_no_header(struct sk_buff *skb, struct net *net, int oif, u32 mark)
> +{
> + const struct ipv6hdr *iph = (struct ipv6hdr *) skb_network_header(skb);
const struct ipv6hdr *iph = ipv6_hdr(skb);
Thanks,
Hannes
^ permalink raw reply
* [PATCH v4 1/7] net: fsl_pq_mdio: use platform_{get,set}_drvdata()
From: Libo Chen @ 2013-08-19 11:58 UTC (permalink / raw)
To: David Miller; +Cc: netdev, LKML, Sergei Shtylyov, Li Zefan
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen <libo.chen@huawei.com>
---
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fsl_pq_mdio.c b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
index c93a056..b7dcd41 100644
--- a/drivers/net/ethernet/freescale/fsl_pq_mdio.c
+++ b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
@@ -409,7 +409,7 @@ static int fsl_pq_mdio_probe(struct platform_device *pdev)
priv->regs = priv->map + data->mii_offset;
new_bus->parent = &pdev->dev;
- dev_set_drvdata(&pdev->dev, new_bus);
+ platform_set_drvdata(pdev, new_bus);
if (data->get_tbipa) {
for_each_child_of_node(np, tbi) {
--
1.7.1
^ permalink raw reply related
* [PATCH v4 0/7] net: use platform_{get,set}_drvdata()
From: Libo Chen @ 2013-08-19 11:58 UTC (permalink / raw)
To: David Miller
Cc: netdev, Li Zefan, leoli, linuxppc-dev, pantelis.antoniou, vbordug,
Greg KH, jg1.han, Sergei Shtylyov
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
changelog v4:
remove modify about happy_meal_pci_probe && happy_meal_pci_remove
changelog v3:
remove modify about dev_set_drvdata()
changelog v2:
this version add modify record about dev_set_drvdata().
Libo Chen (7):
net: fsl_pq_mdio: use platform_{get,set}_drvdata()
net: ucc_geth: use platform_{get,set}_drvdata()
net: fec_mpc52xx_phy: use platform_{get,set}_drvdata()
net: sunbmac: use platform_{get,set}_drvdata()
net: sunhme: use platform_{get,set}_drvdata()
net: xilinx_emaclite: use platform_{get,set}_drvdata()
net: davinci_mdio: use platform_{get,set}_drvdata()
drivers/net/ethernet/freescale/fec_mpc52xx_phy.c | 3 +--
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
drivers/net/ethernet/freescale/ucc_geth.c | 3 +--
drivers/net/ethernet/sun/sunbmac.c | 2 +-
drivers/net/ethernet/sun/sunhme.c | 2 +-
drivers/net/ethernet/ti/davinci_mdio.c | 3 +--
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 3 +--
7 files changed, 7 insertions(+), 11 deletions(-)
^ permalink raw reply
* [PATCH v4 3/7] net: fec_mpc52xx_phy: use platform_{get,set}_drvdata()
From: Libo Chen @ 2013-08-19 11:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev, LKML, Li Zefan, Sergei Shtylyov
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &of->dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen <libo.chen@huawei.com>
---
drivers/net/ethernet/freescale/fec_mpc52xx_phy.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_mpc52xx_phy.c b/drivers/net/ethernet/freescale/fec_mpc52xx_phy.c
index 360a578..eb44797 100644
--- a/drivers/net/ethernet/freescale/fec_mpc52xx_phy.c
+++ b/drivers/net/ethernet/freescale/fec_mpc52xx_phy.c
@@ -123,8 +123,7 @@ static int mpc52xx_fec_mdio_probe(struct platform_device *of)
static int mpc52xx_fec_mdio_remove(struct platform_device *of)
{
- struct device *dev = &of->dev;
- struct mii_bus *bus = dev_get_drvdata(dev);
+ struct mii_bus *bus = platform_get_drvdata(of);
struct mpc52xx_fec_mdio_priv *priv = bus->priv;
mdiobus_unregister(bus);
--
1.7.1
^ permalink raw reply related
* [PATCH v4 2/7] net: ucc_geth: use platform_{get,set}_drvdata()
From: Libo Chen @ 2013-08-19 11:59 UTC (permalink / raw)
To: David Miller; +Cc: leoli, netdev, Li Zefan, Sergei Shtylyov, linuxppc-dev
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &ofdev->dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen <libo.chen@huawei.com>
---
drivers/net/ethernet/freescale/ucc_geth.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
index 3c43dac..533885c 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -3911,8 +3911,7 @@ static int ucc_geth_probe(struct platform_device* ofdev)
static int ucc_geth_remove(struct platform_device* ofdev)
{
- struct device *device = &ofdev->dev;
- struct net_device *dev = dev_get_drvdata(device);
+ struct net_device *dev = platform_get_drvdata(ofdev);
struct ucc_geth_private *ugeth = netdev_priv(dev);
unregister_netdev(dev);
--
1.7.1
^ permalink raw reply related
* [PATCH v4 4/7] net: sunbmac: use platform_{get,set}_drvdata()
From: Libo Chen @ 2013-08-19 11:59 UTC (permalink / raw)
To: David Miller; +Cc: emilio, Greg KH, netdev, LKML, Li Zefan, Sergei Shtylyov
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &of->dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen <libo.chen@huawei.com>
---
drivers/net/ethernet/sun/sunbmac.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/sun/sunbmac.c b/drivers/net/ethernet/sun/sunbmac.c
index 0d43fa9..0a32ca5 100644
--- a/drivers/net/ethernet/sun/sunbmac.c
+++ b/drivers/net/ethernet/sun/sunbmac.c
@@ -1239,7 +1239,7 @@ static int bigmac_sbus_probe(struct platform_device *op)
static int bigmac_sbus_remove(struct platform_device *op)
{
- struct bigmac *bp = dev_get_drvdata(&op->dev);
+ struct bigmac *bp = platform_get_drvdata(op);
struct device *parent = op->dev.parent;
struct net_device *net_dev = bp->dev;
struct platform_device *qec_op;
--
1.7.1
^ permalink raw reply related
* [PATCH v4 5/7] net: sunhme: use platform_{get,set}_drvdata()
From: Libo Chen @ 2013-08-19 11:59 UTC (permalink / raw)
To: David Miller; +Cc: jg1.han, Bill Pemberton, netdev, LKML, Sergei Shtylyov
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &of->dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen <libo.chen@huawei.com>
---
drivers/net/ethernet/sun/sunhme.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/sun/sunhme.c b/drivers/net/ethernet/sun/sunhme.c
index 171f5b0..b90d311 100644
--- a/drivers/net/ethernet/sun/sunhme.c
+++ b/drivers/net/ethernet/sun/sunhme.c
@@ -3231,7 +3231,7 @@ static int hme_sbus_probe(struct platform_device *op)
static int hme_sbus_remove(struct platform_device *op)
{
- struct happy_meal *hp = dev_get_drvdata(&op->dev);
+ struct happy_meal *hp = platform_get_drvdata(op);
struct net_device *net_dev = hp->dev;
unregister_netdev(net_dev);
--
1.7.1
^ permalink raw reply related
* [PATCH v4 7/7] net: davinci_mdio: use platform_{get,set}_drvdata()
From: Libo Chen @ 2013-08-19 12:00 UTC (permalink / raw)
To: David Miller
Cc: mugunthanvnm, bigeasy, prabhakar.csengg, b-liu, netdev, LKML,
Li Zefan, Sergei Shtylyov
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen <libo.chen@huawei.com>
Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
drivers/net/ethernet/ti/davinci_mdio.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index 16ddfc3..01b0cc5 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -421,8 +421,7 @@ bail_out:
static int davinci_mdio_remove(struct platform_device *pdev)
{
- struct device *dev = &pdev->dev;
- struct davinci_mdio_data *data = dev_get_drvdata(dev);
+ struct davinci_mdio_data *data = platform_get_drvdata(pdev);
if (data->bus) {
mdiobus_unregister(data->bus);
--
1.7.1
^ permalink raw reply related
* [PATCH v4 6/7] net: xilinx_emaclite: use platform_{get,set}_drvdata()
From: Libo Chen @ 2013-08-19 12:00 UTC (permalink / raw)
To: David Miller
Cc: michal.simek, renner, Greg KH, Li Zefan, Sergei Shtylyov, monstr,
netdev
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &of_dev->dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen <libo.chen@huawei.com>
Acked-by: Michal Simek <monstr@monstr.eu>
---
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index fd4dbda..7c1ccbc 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -1230,8 +1230,7 @@ error:
*/
static int xemaclite_of_remove(struct platform_device *of_dev)
{
- struct device *dev = &of_dev->dev;
- struct net_device *ndev = dev_get_drvdata(dev);
+ struct net_device *ndev = platform_get_drvdata(of_dev);
struct net_local *lp = netdev_priv(ndev);
--
1.7.1
^ permalink raw reply related
* [net-next PATCH 1/1] drivers: net: cpsw: remove platform data header file of cpsw
From: Mugunthan V N @ 2013-08-19 12:17 UTC (permalink / raw)
To: netdev; +Cc: davem, Mugunthan V N
CPSW driver no longer supports platform register as all the SoCs which has CPSW
are supporting DT only booting, so moving cpsw.h header file from platform
include to drivers/net/ethernet/ti
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/ethernet/ti/cpsw.c | 2 +-
drivers/net/ethernet/ti/cpsw.h | 42 ++++++++++++++++++++++++++++++++++++
include/linux/platform_data/cpsw.h | 44 --------------------------------------
3 files changed, 43 insertions(+), 45 deletions(-)
create mode 100644 drivers/net/ethernet/ti/cpsw.h
delete mode 100644 include/linux/platform_data/cpsw.h
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 0fcf212..b4a85f5 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -34,9 +34,9 @@
#include <linux/of_device.h>
#include <linux/if_vlan.h>
-#include <linux/platform_data/cpsw.h>
#include <linux/pinctrl/consumer.h>
+#include "cpsw.h"
#include "cpsw_ale.h"
#include "cpts.h"
#include "davinci_cpdma.h"
diff --git a/drivers/net/ethernet/ti/cpsw.h b/drivers/net/ethernet/ti/cpsw.h
new file mode 100644
index 0000000..eb3e101
--- /dev/null
+++ b/drivers/net/ethernet/ti/cpsw.h
@@ -0,0 +1,42 @@
+/* Texas Instruments Ethernet Switch Driver
+ *
+ * Copyright (C) 2013 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#ifndef __CPSW_H__
+#define __CPSW_H__
+
+#include <linux/if_ether.h>
+
+struct cpsw_slave_data {
+ char phy_id[MII_BUS_ID_SIZE];
+ int phy_if;
+ u8 mac_addr[ETH_ALEN];
+ u16 dual_emac_res_vlan; /* Reserved VLAN for DualEMAC */
+};
+
+struct cpsw_platform_data {
+ struct cpsw_slave_data *slave_data;
+ u32 ss_reg_ofs; /* Subsystem control register offset */
+ u32 channels; /* number of cpdma channels (symmetric) */
+ u32 slaves; /* number of slave cpgmac ports */
+ u32 active_slave; /* time stamping, ethtool and SIOCGMIIPHY slave */
+ u32 cpts_clock_mult; /* convert input clock ticks to nanoseconds */
+ u32 cpts_clock_shift; /* convert input clock ticks to nanoseconds */
+ u32 ale_entries; /* ale table size */
+ u32 bd_ram_size; /*buffer descriptor ram size */
+ u32 rx_descs; /* Number of Rx Descriptios */
+ u32 mac_control; /* Mac control register */
+ u16 default_vlan; /* Def VLAN for ALE lookup in VLAN aware mode*/
+ bool dual_emac; /* Enable Dual EMAC mode */
+};
+
+#endif /* __CPSW_H__ */
diff --git a/include/linux/platform_data/cpsw.h b/include/linux/platform_data/cpsw.h
deleted file mode 100644
index bb3cd58..0000000
--- a/include/linux/platform_data/cpsw.h
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * Texas Instruments Ethernet Switch Driver
- *
- * Copyright (C) 2012 Texas Instruments
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation version 2.
- *
- * This program is distributed "as is" WITHOUT ANY WARRANTY of any
- * kind, whether express or implied; without even the implied warranty
- * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-#ifndef __CPSW_H__
-#define __CPSW_H__
-
-#include <linux/if_ether.h>
-
-struct cpsw_slave_data {
- char phy_id[MII_BUS_ID_SIZE];
- int phy_if;
- u8 mac_addr[ETH_ALEN];
- u16 dual_emac_res_vlan; /* Reserved VLAN for DualEMAC */
-
-};
-
-struct cpsw_platform_data {
- u32 ss_reg_ofs; /* Subsystem control register offset */
- u32 channels; /* number of cpdma channels (symmetric) */
- u32 slaves; /* number of slave cpgmac ports */
- struct cpsw_slave_data *slave_data;
- u32 active_slave; /* time stamping, ethtool and SIOCGMIIPHY slave */
- u32 cpts_clock_mult; /* convert input clock ticks to nanoseconds */
- u32 cpts_clock_shift; /* convert input clock ticks to nanoseconds */
- u32 ale_entries; /* ale table size */
- u32 bd_ram_size; /*buffer descriptor ram size */
- u32 rx_descs; /* Number of Rx Descriptios */
- u32 mac_control; /* Mac control register */
- u16 default_vlan; /* Def VLAN for ALE lookup in VLAN aware mode*/
- bool dual_emac; /* Enable Dual EMAC mode */
-};
-
-#endif /* __CPSW_H__ */
--
1.8.4.rc1.21.gfb56570
^ permalink raw reply related
* Re: [PATCH net-next] myri10ge: Add support for ndo_busy_poll
From: Hyong-Youb Kim @ 2013-08-19 12:20 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <1376902939-21968-1-git-send-email-hykim@myri.com>
Just for the record, here are a couple TCP_RR numbers from netperf.
Polling has the intended effect on this driver too.
Setup:
Linux 3.11-rc5 with many of unused features disabled
A couple machines with an E31270 CPU and a single-port 10G-PCIE-8B-S NIC
No switches
netperf 2.6.0
ethtool -C eth2 rx-usecs 0
ethtool -K eth2 gro off
net.core.busy_read=0: 53385.06 trans/s
net.core.busy_read=50: 87898.95 trans/s
The increase from busy_read is comparable to what Intel developers
reported earlier using ixgbe.
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Christoph Paasch @ 2013-08-19 12:33 UTC (permalink / raw)
To: Corey Hickey
Cc: Eric Dumazet, Jozsef Kadlecsik, Linux Netdev List,
netfilter-devel
In-Reply-To: <5211DAA6.1070302@fatooh.org>
Hello,
I would say, the problem is due to a sequence-number rewriting
middlebox, who does not correctly handle the SACK-blocks.
In remote.pcap, you see:
Packet#10: A Dup-ACK: ACK 1005503816, SACK: 1005505184-1005505648
The SACK actually covers Packet#9
In tun0.pcap, you have:
Packet#9: The one that is SACK'ed: SEQ: 3514869772
Packet#11: The Dup-ACK: ACK: 3514868404, SACK: 3570452498-3570452962
You can see that the SACK-block is not really aligned with the ACK-numbers.
Netfilter is probably dropping the Dup-ACK, because the SACK-block is
acknowledging unseen data.
There are middleboxes out there that randomize the sequence numbers, due to
an old bug in Windows, where the initial sequence number was not
sufficiently randomized. There are some of these middleboxes, who simply do
not support SACK, thus modify only the sequence numbers of the TCP-header
(https://supportforums.cisco.com/docs/DOC-12668#TCP_Sequence_Number_Randomization_and_SACK).
This results in a TCP retransmission timeout on the sender, because of
the invalid SACK-blocks, the duplicate ACKs are not accounted. This
completly kills the performance, as you can see in our presentation given at
IETF87: http://tools.ietf.org/agenda/87/slides/slides-87-tcpm-11.pdf
We have a patch that accounts DUP-ACKs with invalid SACK-blocks effectively
as duplicate acknowledgments. I can send the patches, if the
netdev-community is interested in accepting these upstream.
Cheers,
Christoph
On 19/08/13 - 01:43:18, Corey Hickey wrote:
> On 2013-08-18 17:03, Eric Dumazet wrote:
> > On Sun, 2013-08-18 at 17:00 -0700, Eric Dumazet wrote:
> >
> >> Code like this seems very suspect to me :
> >>
> >> before(sack, receiver->td_end + 1)
> >>
> >
> > My suggestion would be to try :
> >
> > diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
>
> [...]
>
> Thanks for all your suggestions--I really wasn't expecting so much on a
> weekend. Here's all the data I have for tonight.
>
>
> I tried the linux-next kernel, then linux-next with your patch applied.
> Neither of them fix the problem, unfortunately. I have taken tcpdumps
> for a working SSH and a failing SSH.
>
> http://fatooh.org/files/tmp/linux-next-patch1.tar.bz2
>
> [localhost]
> sudo tcpdump -ni br0 -s 0 -w /tmp/local.pcap 'host 10.15.24.13 or icmp'
>
> [router eth0]
> tcpdump -ni eth0 -s 0 -w /tmp/eth0.pcap \
> 'host 10.15.24.13 or (icmp and host not 69.78.33.132)'
> * the exclusion here is just to remove some unrelated clutter
>
> [router tun0]
> tcpdump -ni tun0 -s 0 -w /tmp/tun0.pcap -s 0 'host 10.15.24.13 or icmp'
>
> [remote]
> tcpdump -ni eth0 -s 0 -w remote.pcap 'host 192.168.61.56'
>
>
> Some notes:
>
> 1. I tested the new kernels only on the Linux router, assuming that is
> where it was intended.
>
> 2. I take back what I wrote earlier about every connection that involves
> PMTU discovery failed; I may have been observing this wrong. For now,
> the situation is that some connections stop forwarding packets from the
> remote host immediately after the retransmit, while other work fine.
>
> 3. From local.pcap, you can see that my localhost doesn't actually
> transmit a large packet, yet the router's eth0 sees a large packet come
> in. I think this is due to TSO, but I'm not completely sure.
>
> 4. For some reason, I cannot reproduce this when SSHing to a host at
> work that is running Debian sid with 3.10-1-amd64, but I can reproduce
> it when SSHing to hosts running Centos 6.4 with
> 2.6.32-358.6.1.el6.x86_64 (which surely has a ton of patches applied,
> for whatever that's worth).
>
> 5. I have only a vague understanding of SACK; I will be reading up on
> this soon. I will also look into packetdrill for reproducing the
> problem, if the SSH results aren't good enough.
>
> 6. If I reduce the MTU on localhost to match the path MTU, the problem
> does go away.
>
> Thanks again for all the help,
> Corey
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch -next] ipip: dereferencing an ERR_PTR in ip_tunnel_init_net()
From: Eric Dumazet @ 2013-08-19 12:58 UTC (permalink / raw)
To: Dan Carpenter
Cc: David S. Miller, Nicolas Dichtel, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, kernel-janitors
In-Reply-To: <20130819070510.GE28591@elgon.mountain>
On Mon, 2013-08-19 at 10:05 +0300, Dan Carpenter wrote:
> We need to move the derefernce after the IS_ERR() check.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
> index a4d9126..24549b4 100644
> --- a/net/ipv4/ip_tunnel.c
> +++ b/net/ipv4/ip_tunnel.c
> @@ -854,14 +854,14 @@ int ip_tunnel_init_net(struct net *net, int ip_tnl_net_id,
>
> rtnl_lock();
> itn->fb_tunnel_dev = __ip_tunnel_create(net, ops, &parms);
> - /* FB netdevice is special: we have one, and only one per netns.
> - * Allowing to move it to another netns is clearly unsafe.
> - */
> - itn->fb_tunnel_dev->features |= NETIF_F_NETNS_LOCAL;
> rtnl_unlock();
>
> if (IS_ERR(itn->fb_tunnel_dev))
> return PTR_ERR(itn->fb_tunnel_dev);
> + /* FB netdevice is special: we have one, and only one per netns.
> + * Allowing to move it to another netns is clearly unsafe.
> + */
> + itn->fb_tunnel_dev->features |= NETIF_F_NETNS_LOCAL;
>
> return 0;
> }
> --
Please add to the changelog :
Bug was added in commit 6c742e714d8c2 ("ipip: add x-netns support")
I do not think this fix is safe.
"dev->features |= some_flag;" should be protected by rtnl
So I suggest using instead :
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index a4d9126..830de3f 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -857,13 +857,11 @@ int ip_tunnel_init_net(struct net *net, int ip_tnl_net_id,
/* FB netdevice is special: we have one, and only one per netns.
* Allowing to move it to another netns is clearly unsafe.
*/
- itn->fb_tunnel_dev->features |= NETIF_F_NETNS_LOCAL;
+ if (!IS_ERR(itn->fb_tunnel_dev))
+ itn->fb_tunnel_dev->features |= NETIF_F_NETNS_LOCAL;
rtnl_unlock();
- if (IS_ERR(itn->fb_tunnel_dev))
- return PTR_ERR(itn->fb_tunnel_dev);
-
- return 0;
+ return PTR_RET(itn->fb_tunnel_dev);
}
EXPORT_SYMBOL_GPL(ip_tunnel_init_net);
^ permalink raw reply related
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Eric Dumazet @ 2013-08-19 13:24 UTC (permalink / raw)
To: Christoph Paasch
Cc: Corey Hickey, Jozsef Kadlecsik, Linux Netdev List,
netfilter-devel
In-Reply-To: <20130819123314.GC3583@cpaasch-mac>
On Mon, 2013-08-19 at 14:33 +0200, Christoph Paasch wrote:
> Hello,
>
> I would say, the problem is due to a sequence-number rewriting
> middlebox, who does not correctly handle the SACK-blocks.
>
> In remote.pcap, you see:
> Packet#10: A Dup-ACK: ACK 1005503816, SACK: 1005505184-1005505648
> The SACK actually covers Packet#9
>
> In tun0.pcap, you have:
> Packet#9: The one that is SACK'ed: SEQ: 3514869772
> Packet#11: The Dup-ACK: ACK: 3514868404, SACK: 3570452498-3570452962
>
> You can see that the SACK-block is not really aligned with the ACK-numbers.
>
> Netfilter is probably dropping the Dup-ACK, because the SACK-block is
> acknowledging unseen data.
>
>
> There are middleboxes out there that randomize the sequence numbers, due to
> an old bug in Windows, where the initial sequence number was not
> sufficiently randomized. There are some of these middleboxes, who simply do
> not support SACK, thus modify only the sequence numbers of the TCP-header
> (https://supportforums.cisco.com/docs/DOC-12668#TCP_Sequence_Number_Randomization_and_SACK).
>
> This results in a TCP retransmission timeout on the sender, because of
> the invalid SACK-blocks, the duplicate ACKs are not accounted. This
> completly kills the performance, as you can see in our presentation given at
> IETF87: http://tools.ietf.org/agenda/87/slides/slides-87-tcpm-11.pdf
>
> We have a patch that accounts DUP-ACKs with invalid SACK-blocks effectively
> as duplicate acknowledgments. I can send the patches, if the
> netdev-community is interested in accepting these upstream.
>
You mean a netfilter patch, a tcp patch, or both ?
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Christoph Paasch @ 2013-08-19 13:49 UTC (permalink / raw)
To: Eric Dumazet
Cc: Corey Hickey, Jozsef Kadlecsik, Linux Netdev List,
netfilter-devel
In-Reply-To: <1376918657.4226.59.camel@edumazet-glaptop>
On 19/08/13 - 06:24:17, Eric Dumazet wrote:
> On Mon, 2013-08-19 at 14:33 +0200, Christoph Paasch wrote:
> > Hello,
> >
> > I would say, the problem is due to a sequence-number rewriting
> > middlebox, who does not correctly handle the SACK-blocks.
> >
> > In remote.pcap, you see:
> > Packet#10: A Dup-ACK: ACK 1005503816, SACK: 1005505184-1005505648
> > The SACK actually covers Packet#9
> >
> > In tun0.pcap, you have:
> > Packet#9: The one that is SACK'ed: SEQ: 3514869772
> > Packet#11: The Dup-ACK: ACK: 3514868404, SACK: 3570452498-3570452962
> >
> > You can see that the SACK-block is not really aligned with the ACK-numbers.
> >
> > Netfilter is probably dropping the Dup-ACK, because the SACK-block is
> > acknowledging unseen data.
> >
> >
> > There are middleboxes out there that randomize the sequence numbers, due to
> > an old bug in Windows, where the initial sequence number was not
> > sufficiently randomized. There are some of these middleboxes, who simply do
> > not support SACK, thus modify only the sequence numbers of the TCP-header
> > (https://supportforums.cisco.com/docs/DOC-12668#TCP_Sequence_Number_Randomization_and_SACK).
> >
> > This results in a TCP retransmission timeout on the sender, because of
> > the invalid SACK-blocks, the duplicate ACKs are not accounted. This
> > completly kills the performance, as you can see in our presentation given at
> > IETF87: http://tools.ietf.org/agenda/87/slides/slides-87-tcpm-11.pdf
> >
> > We have a patch that accounts DUP-ACKs with invalid SACK-blocks effectively
> > as duplicate acknowledgments. I can send the patches, if the
> > netdev-community is interested in accepting these upstream.
> >
>
> You mean a netfilter patch, a tcp patch, or both ?
It's a TCP-patch, that interprets duplicate-acks with invalid SACK-blocks as
duplicate acks in tcp_sock->sacked_out.
Christoph
^ permalink raw reply
* Re: [patch -next] ipip: dereferencing an ERR_PTR in ip_tunnel_init_net()
From: Dan Carpenter @ 2013-08-19 13:49 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S. Miller, Nicolas Dichtel, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, kernel-janitors
In-Reply-To: <1376917088.4226.50.camel@edumazet-glaptop>
Thanks for the review. I will send a v2 patch shortly.
regards,
dan carpenter
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Eric Dumazet @ 2013-08-19 13:58 UTC (permalink / raw)
To: Christoph Paasch
Cc: Corey Hickey, Jozsef Kadlecsik, Linux Netdev List,
netfilter-devel
In-Reply-To: <20130819134919.GF3583@cpaasch-mac>
On Mon, 2013-08-19 at 15:49 +0200, Christoph Paasch wrote:
>
> It's a TCP-patch, that interprets duplicate-acks with invalid SACK-blocks as
> duplicate acks in tcp_sock->sacked_out.
Yeah, but here, this is conntrack who is blocking the thing.
TCP receiver has no chance to 'fix' it.
See conntrack is one of those buggy middle box as well.
So if you want to properly handle this mess, you'll also have to fix
conntrack.
^ permalink raw reply
* Re: [PATCH] driver:net:stmmac: Disable DMA store and forward mode if platform data force_sf_dma_mode is negative.
From: Giuseppe CAVALLARO @ 2013-08-19 14:29 UTC (permalink / raw)
To: Sonic Zhang; +Cc: netdev, adi-buildroot-devel, Sonic Zhang
In-Reply-To: <CAJxxZ0NFhMMKp2eB+b168=c6+JsmJE6-yva7ZOGKciK3e4b8Yg@mail.gmail.com>
On 8/19/2013 12:51 PM, Sonic Zhang wrote:
> Hi Giuseppe,
>
> On Mon, Aug 19, 2013 at 3:45 PM, Giuseppe CAVALLARO
> <peppe.cavallaro@st.com> wrote:
>> On 8/19/2013 9:31 AM, Sonic Zhang wrote:
>>>
>>> Hi Giuseppe,
>>>
>>> On Mon, Aug 19, 2013 at 2:03 PM, Giuseppe CAVALLARO
>>> <peppe.cavallaro@st.com> wrote:
>>>>
>>>> Hello Sonic
>>>>
>>>>
>>>> On 8/15/2013 9:37 AM, Sonic Zhang wrote:
>>>>>
>>>>>
>>>>> From: Sonic Zhang <sonic.zhang@analog.com>
>>>>>
>>>>> Some synopsys ip implementation doesn't support DMA store and forward
>>>>> mode,
>>>>> such as BF60x. So, define force_sf_dma_mode negative to use DMA
>>>>> thresholds
>>>>> only.
>>>>
>>>>
>>>>
>>>> I think that you should not pass the force_sf_dma_mode platform field
>>>> at all (and it doesn't make sense to force it as negative).
>>>> To use the threshold you should reset tx_coe. In fact, your HW cannot
>>>> perform the Hw csum if SF is not available.
>>>> Note that, the HW cap register (if available) can override (set/reset)
>>>> tx_coe.
>>>
>>>
>>> Even if I reset tx_coe, the SF mode is still set to RX DMA in current
>>> stmmac_dma_operation_mode(). SF mode is not supported in both RX DMA
>>> and TX DMA in Blackfin MAC.
>>
>>
>> yes this is true. the SF is always set for the RX path because I have
>> never had and known HW w/o RX csum (since the 209).
>>
>> So I think the code could be improved to disable/enable the SF also for
>> the RX path.
>>
>>
>>>>
>>>> I tested, long time ago, this scenario on old mac w/o HW cap register
>>>> and w/o SF.
>>>
>>>
>>> Blackfin synopsys MAC IP has the HW cap register with tx_coe set to 1,
>>> but the HW tx_coe doesn't really work. I have the other patch to
>>> disable HW tx_coe in board file and override the HW cap register.
>>
>>
>> AFAIK the HW shouldn't be able to perform the csum in HW w/o SF.
>>
>> Maybe, an easy way could be to use a new field to force the threshold
>> mode. This should also remove the csum in HW (IMO) and program the
>> DMA operation register.
>>
>
> The problem is that HW RX csum works perfectly on Blackfin MAC
> although the SF mode is not supported in RX DMA.
hmm maybe we should ask SYNP. I'll try.
> I may need 2 platform
> fields to force RX DMA threshold and disable HW tx_coe. One field
> doesn't cover both cases well.
concerning tx_coe, I had added it to inform the stmmac that the HW
was (or not) able to do the csum in hw. This was true on chip w/o
the HW cap register. If you have the HW cap reg so let me assume
there is another problem. For example, I worked (time ago) on an HW
where the cap reg declared that the mac was able to perform the csum
in hw but, after debugging it, I discovered that the problem was on
SG. I mean, the HW was able to do the csum in HW but had problems on
fragmented frame (I mean, frames that were split in one more
descriptor).
I will send you the patch I used to fix that... maybe you are in the
same scenario.
Concerning the threshold, just to avoid to complicate the code, we could
keep force_sf_dma_mode and add force_thresh_dma_mode that force both
rx and tx. I do not want to remove the force_sf_dma_mode that is also
used on some platforms (AFAIK).
Do not forget to update the stmmac.txt and devicetree support
What do you think?
I also think that the patch should be prepared on top of net-next.
Peppe
>
> Which 2 fields do you prefer?
>
> Thanks
>
> Sonic
>
>
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Phil Oester @ 2013-08-19 14:35 UTC (permalink / raw)
To: Eric Dumazet
Cc: Christoph Paasch, Corey Hickey, Jozsef Kadlecsik,
Linux Netdev List, netfilter-devel
In-Reply-To: <1376920685.4226.61.camel@edumazet-glaptop>
On Mon, Aug 19, 2013 at 06:58:05AM -0700, Eric Dumazet wrote:
> Yeah, but here, this is conntrack who is blocking the thing.
>
> TCP receiver has no chance to 'fix' it.
>
> See conntrack is one of those buggy middle box as well.
>
> So if you want to properly handle this mess, you'll also have to fix
> conntrack.
Better to fix the box which is randomizing the acks and ignoring
the SACKs. Usually these are older Cisco PIX/ASA devices which just
need a code upgrade.
Phil
^ permalink raw reply
* IFB network driver problems and questions
From: Brad Johnson @ 2013-08-19 14:35 UTC (permalink / raw)
To: netdev
We are trying to use the IFB driver for ingress QoS and are having some
problems getting it to work for us. Even though I have seen it described
as a replacement for IMQ, it appears that it hooks the packets before
netfilter and so marks set with iptables are not seen by tc filters on
the ifb device. This makes it difficult, and in some cases impossible,
to do any kind of complex filtering, such as port ranges and many other
matches that are easy to do with iptables. So my questions are:
1. Is there any way to set marks with iptables and have them seen in the
IFB device?
2. Is there any way to use IFB as an iptables target the same way you
can do a "-j IMQ" target?
3. If the previous answers are 'no', then are there any plans to
implement those features?
Thanks
^ permalink raw reply
* Re: [Patch net-next v3 7/9] fs: use generic union inet_addr and helper functions
From: Christoph Hellwig @ 2013-08-19 14:37 UTC (permalink / raw)
To: Cong Wang
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller, Steve French,
Christine Caulfield, David Teigland, Trond Myklebust,
linux-cifs-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cluster-devel-H+wXaHxf7aLQT0dZR+AlfA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1376907278-26377-8-git-send-email-amwang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> @@ -1900,17 +1901,9 @@ srcip_matches(struct sockaddr *srcaddr, struct sockaddr *rhs)
> {
I think your new sockaddr_equal should be equivalent to to this
srcip_matches, that is it should warn about and return false for unknown
address families.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Christoph Paasch @ 2013-08-19 14:43 UTC (permalink / raw)
To: Eric Dumazet
Cc: Corey Hickey, Jozsef Kadlecsik, Linux Netdev List,
netfilter-devel
In-Reply-To: <1376920685.4226.61.camel@edumazet-glaptop>
On 19/08/13 - 06:58:05, Eric Dumazet wrote:
> On Mon, 2013-08-19 at 15:49 +0200, Christoph Paasch wrote:
> > It's a TCP-patch, that interprets duplicate-acks with invalid SACK-blocks as
> > duplicate acks in tcp_sock->sacked_out.
>
> Yeah, but here, this is conntrack who is blocking the thing.
Yes, of course. I know that here conntrack is blocking the dup-ACKs.
Sorry for having added TCP-stack specific things in a conntrack-thread.
I just wanted to highlight that the TCP-stack has also problems with
sequence-number rewriting middleboxes.
> TCP receiver has no chance to 'fix' it.
>
> See conntrack is one of those buggy middle box as well.
>
> So if you want to properly handle this mess, you'll also have to fix
> conntrack.
^ 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