* [PATCH v3 0/3] net: stmmac: Enable Intel Quark SoC X1000 Ethernet support
From: Andy Shevchenko @ 2015-01-27 19:44 UTC (permalink / raw)
To: Giuseppe Cavallaro, netdev, David S . Miller; +Cc: Andy Shevchenko
This is third version of the patch series [1] to bring network card support to
Intel Quark SoC.
The series has been tested on Intel Galileo board.
Changelog v3:
- rebase on top of recent net-next
- rework an approach to get the custom configuration
- rework an approach how to get unique bus_id
- improve DMI lookup function
[1] http://www.spinics.net/lists/netdev/msg296010.html
Andy Shevchenko (1):
stmmac: pci: introduce Intel Quark X1000 runtime detection
Kweh, Hock Leong (2):
stmmac: pci: add support for Intel Quark X1000
stmmac: pci: add MSI support for Intel Quark X1000
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 113 ++++++++++++++++++++++-
1 file changed, 112 insertions(+), 1 deletion(-)
--
2.1.4
^ permalink raw reply
* [PATCH v3 1/3] stmmac: pci: add support for Intel Quark X1000
From: Andy Shevchenko @ 2015-01-27 19:44 UTC (permalink / raw)
To: Giuseppe Cavallaro, netdev, David S . Miller
Cc: Kweh, Hock Leong, Andy Shevchenko
In-Reply-To: <1422387889-21559-1-git-send-email-andriy.shevchenko@linux.intel.com>
From: "Kweh, Hock Leong" <hock.leong.kweh@intel.com>
The Intel Quark SoC X1000 provides two 10/100 Mbps Ethernet MAC
controllers which may or may not be connected to PHY on board.
This MAC controller only supports RMII PHY. This patch add Quark
PCI ID as well as Quark default platform data info to this driver.
Signed-off-by: Kweh, Hock Leong <hock.leong.kweh@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 51 +++++++++++++++++++++++-
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 054520d..a316187 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -26,6 +26,12 @@
#include <linux/pci.h>
#include "stmmac.h"
+struct stmmac_pci_info {
+ struct pci_dev *pdev;
+ int (*setup)(struct plat_stmmacenet_data *plat,
+ struct stmmac_pci_info *info);
+};
+
static void stmmac_default_data(struct plat_stmmacenet_data *plat)
{
plat->bus_id = 1;
@@ -48,6 +54,38 @@ static void stmmac_default_data(struct plat_stmmacenet_data *plat)
plat->unicast_filter_entries = 1;
}
+static int quark_default_data(struct plat_stmmacenet_data *plat,
+ struct stmmac_pci_info *info)
+{
+ struct pci_dev *pdev = info->pdev;
+
+ plat->bus_id = PCI_DEVID(pdev->bus->number, pdev->devfn);
+ plat->phy_addr = 1;
+ plat->interface = PHY_INTERFACE_MODE_RMII;
+ plat->clk_csr = 2;
+ plat->has_gmac = 1;
+ plat->force_sf_dma_mode = 1;
+
+ plat->mdio_bus_data->phy_reset = NULL;
+ plat->mdio_bus_data->phy_mask = 0;
+
+ plat->dma_cfg->pbl = 16;
+ plat->dma_cfg->burst_len = DMA_AXI_BLEN_256;
+ plat->dma_cfg->fixed_burst = 1;
+
+ /* Set default value for multicast hash bins */
+ plat->multicast_filter_bins = HASH_TABLE_SIZE;
+
+ /* Set default value for unicast filter entries */
+ plat->unicast_filter_entries = 1;
+
+ return 0;
+}
+
+static struct stmmac_pci_info quark_pci_info = {
+ .setup = quark_default_data,
+};
+
/**
* stmmac_pci_probe
*
@@ -63,6 +101,7 @@ static void stmmac_default_data(struct plat_stmmacenet_data *plat)
static int stmmac_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
+ struct stmmac_pci_info *info = (struct stmmac_pci_info *)id->driver_data;
struct plat_stmmacenet_data *plat;
struct stmmac_priv *priv;
int i;
@@ -103,7 +142,15 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
pci_set_master(pdev);
- stmmac_default_data(plat);
+ if (info) {
+ info->pdev = pdev;
+ if (info->setup) {
+ ret = info->setup(plat, info);
+ if (ret)
+ return ret;
+ }
+ } else
+ stmmac_default_data(plat);
priv = stmmac_dvr_probe(&pdev->dev, plat, pcim_iomap_table(pdev)[i]);
if (IS_ERR(priv)) {
@@ -155,11 +202,13 @@ static int stmmac_pci_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(stmmac_pm_ops, stmmac_pci_suspend, stmmac_pci_resume);
#define STMMAC_VENDOR_ID 0x700
+#define STMMAC_QUARK_ID 0x0937
#define STMMAC_DEVICE_ID 0x1108
static const struct pci_device_id stmmac_id_table[] = {
{PCI_DEVICE(STMMAC_VENDOR_ID, STMMAC_DEVICE_ID)},
{PCI_DEVICE(PCI_VENDOR_ID_STMICRO, PCI_DEVICE_ID_STMICRO_MAC)},
+ {PCI_VDEVICE(INTEL, STMMAC_QUARK_ID), (kernel_ulong_t)&quark_pci_info},
{}
};
--
2.1.4
^ permalink raw reply related
* [PATCH v3 3/3] stmmac: pci: add MSI support for Intel Quark X1000
From: Andy Shevchenko @ 2015-01-27 19:44 UTC (permalink / raw)
To: Giuseppe Cavallaro, netdev, David S . Miller
Cc: Kweh, Hock Leong, Andy Shevchenko
In-Reply-To: <1422387889-21559-1-git-send-email-andriy.shevchenko@linux.intel.com>
From: "Kweh, Hock Leong" <hock.leong.kweh@intel.com>
In Intel Quark SoC X1000, both of the Ethernet controllers support
MSI interrupt handling. This patch enables them to use MSI interrupt
servicing in stmmac_pci for Intel Quark X1000.
Signed-off-by: Kweh, Hock Leong <hock.leong.kweh@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 50f3c50..3bca908 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -212,6 +212,8 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
} else
stmmac_default_data(plat);
+ pci_enable_msi(pdev);
+
priv = stmmac_dvr_probe(&pdev->dev, plat, pcim_iomap_table(pdev)[i]);
if (IS_ERR(priv)) {
dev_err(&pdev->dev, "%s: main driver probe failed\n", __func__);
--
2.1.4
^ permalink raw reply related
* [PATCH v3 2/3] stmmac: pci: introduce Intel Quark X1000 runtime detection
From: Andy Shevchenko @ 2015-01-27 19:44 UTC (permalink / raw)
To: Giuseppe Cavallaro, netdev, David S . Miller
Cc: Andy Shevchenko, Kweh, Hock Leong
In-Reply-To: <1422387889-21559-1-git-send-email-andriy.shevchenko@linux.intel.com>
This patch introduces run-time board detection through DMI and MAC-PHY
configuration function used by quark_default_data() during initialization. It
fills up the phy_addr for Galileo and Galileo Gen2 boards to indicate that the
Ethernet MAC controller is or is not connected to any PHY.
The implementation takes into consideration for future expansion in Quark
series boards that may have different PHY address that is linked to its MAC
controllers.
This piece of work is derived from Bryan O'Donoghue's initial work for Quark
X1000 enabling.
Signed-off-by: Kweh, Hock Leong <hock.leong.kweh@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 62 +++++++++++++++++++++++-
1 file changed, 61 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index a316187..50f3c50 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -24,14 +24,50 @@
*******************************************************************************/
#include <linux/pci.h>
+#include <linux/dmi.h>
+
#include "stmmac.h"
+/*
+ * This struct is used to associate PCI Function of MAC controller on a board,
+ * discovered via DMI, with the address of PHY connected to the MAC. The
+ * negative value of the address means that MAC controller is not connected
+ * with PHY.
+ */
+struct stmmac_pci_dmi_data {
+ const char *name;
+ unsigned int func;
+ int phy_addr;
+};
+
struct stmmac_pci_info {
struct pci_dev *pdev;
int (*setup)(struct plat_stmmacenet_data *plat,
struct stmmac_pci_info *info);
+ struct stmmac_pci_dmi_data *dmi;
};
+static int stmmac_pci_find_phy_addr(struct stmmac_pci_info *info)
+{
+ const char *name = dmi_get_system_info(DMI_BOARD_NAME);
+ unsigned int func = PCI_FUNC(info->pdev->devfn);
+ struct stmmac_pci_dmi_data *dmi;
+
+ /*
+ * Galileo boards with old firmware don't support DMI. We always return
+ * 1 here, so at least first found MAC controller would be probed.
+ */
+ if (!name)
+ return 1;
+
+ for (dmi = info->dmi; dmi->name && *dmi->name; dmi++) {
+ if (!strcmp(dmi->name, name) && dmi->func == func)
+ return dmi->phy_addr;
+ }
+
+ return -ENODEV;
+}
+
static void stmmac_default_data(struct plat_stmmacenet_data *plat)
{
plat->bus_id = 1;
@@ -58,9 +94,18 @@ static int quark_default_data(struct plat_stmmacenet_data *plat,
struct stmmac_pci_info *info)
{
struct pci_dev *pdev = info->pdev;
+ int ret;
+
+ /*
+ * Refuse to load the driver and register net device if MAC controller
+ * does not connect to any PHY interface.
+ */
+ ret = stmmac_pci_find_phy_addr(info);
+ if (ret < 0)
+ return ret;
plat->bus_id = PCI_DEVID(pdev->bus->number, pdev->devfn);
- plat->phy_addr = 1;
+ plat->phy_addr = ret;
plat->interface = PHY_INTERFACE_MODE_RMII;
plat->clk_csr = 2;
plat->has_gmac = 1;
@@ -82,8 +127,23 @@ static int quark_default_data(struct plat_stmmacenet_data *plat,
return 0;
}
+static struct stmmac_pci_dmi_data quark_pci_dmi_data[] = {
+ {
+ .name = "Galileo",
+ .func = 6,
+ .phy_addr = 1,
+ },
+ {
+ .name = "GalileoGen2",
+ .func = 6,
+ .phy_addr = 1,
+ },
+ {}
+};
+
static struct stmmac_pci_info quark_pci_info = {
.setup = quark_default_data,
+ .dmi = quark_pci_dmi_data,
};
/**
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net-next 06/10] net/mlx4_core: Fix struct mlx4_vhcr_cmd to make implicit padding explicit
From: Jack Morgenstein @ 2015-01-27 19:50 UTC (permalink / raw)
To: David Miller; +Cc: David.Laight, amirv, netdev, ogerlitz, yevgenyp
In-Reply-To: <20150127.111334.501141232585900738.davem@davemloft.net>
On Tue, 27 Jan 2015 11:13:34 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> Indeed, I'm really sick of seeing these packed structures being
> created all over the place.
>
> They are to be used in absolutely extreme cases where no other
> solution is possible.
The V2 of this patch does not have "packed".
-Jack
^ permalink raw reply
* Interaction between GSO and TSQ for single TCP stream
From: Tom Herbert @ 2015-01-27 19:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Netdev List
Eric,
I am looking at why we are unable to achieve line rate throughput with
a single connection using UDP encapsulation that supports GSO/GRO. I
discovered that even for a non-encpasulated TCP connection I'm not
able to get line rate using GSO/GRO (but do with TSO/LRO). There seems
to be some interaction between TSQ and GSO. Setting
tcp_limit_output_bytes to 1000000 gets single connection up to line
rate for both native and encapsulated TCP.
Some data:
- netperf TCP_STREAM for a single connection no encapsulation
Using TSO/LRO
9412.44 Gbps
Using GSO/GRO (ethtool -K eth0 gso on gro on tso off lro off)
9286.08 Gbps
Using GSO/GRO with larger limit (echo 1000000 >
/proc/sys/net/ipv4/tcp_limit_output_bytes)
9412.75
- netperf TCP_STREAM for a single connection for GUE-IPIP encapsulation with RCO
Using GSO/GRO
8842.89 Gbps
Using GSO/GRO with larger limit (echo 1000000 >
/proc/sys/net/ipv4/tcp_limit_output_bytes)
9143.99 Gbps
Any ideas on how to address this?
Thanks,
Tom
^ permalink raw reply
* Re: [PATCH 7/7] net: wireless: wcn36xx: handle new trigger_ba format
From: Eugene Krasnikov @ 2015-01-27 19:58 UTC (permalink / raw)
To: Andy Green; +Cc: Kalle Valo, wcn36xx, linux-wireless, netdev
In-Reply-To: <20150118051117.31866.68634.stgit@114-36-241-182.dynamic.hinet.net>
arg... it looks like the code is starting to have to many
if(chip_version) cases. Mabe we should concider separate files for
chip specific logic.
2015-01-18 5:11 GMT+00:00 Andy Green <andy.green@linaro.org>:
> wcn3620 has a new message structure for the reply to trigger_ba
> We don't know what to do with the candidate list he sends back,
> but we can at least accept and ignore it nicely instead of dying.
>
> Signed-off-by: Andy Green <andy.green@linaro.org>
> ---
> drivers/net/wireless/ath/wcn36xx/smd.c | 28 ++++++++++++++++++++++++++--
> drivers/net/wireless/ath/wcn36xx/smd.h | 9 +++++++++
> 2 files changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c b/drivers/net/wireless/ath/wcn36xx/smd.c
> index 819741c..dc24e1b 100644
> --- a/drivers/net/wireless/ath/wcn36xx/smd.c
> +++ b/drivers/net/wireless/ath/wcn36xx/smd.c
> @@ -243,8 +243,31 @@ static int wcn36xx_smd_rsp_status_check(void *buf, size_t len)
> rsp = (struct wcn36xx_fw_msg_status_rsp *)
> (buf + sizeof(struct wcn36xx_hal_msg_header));
>
> - if (WCN36XX_FW_MSG_RESULT_SUCCESS != rsp->status)
> + if (WCN36XX_FW_MSG_RESULT_SUCCESS != rsp->status) {
> + pr_err("%s: bad status, len = %d\n", __func__, len);
> + return rsp->status;
> + }
> +
> + return 0;
> +}
> +
> +static int wcn36xx_smd_rsp_status_check_bav2(struct wcn36xx *wcn, void *buf,
> + size_t len)
> +{
> + struct wcn36xx_fw_msg_status_rspv2 *rsp;
> +
> + if (wcn->chip_version != WCN36XX_CHIP_3620)
> + return wcn36xx_smd_rsp_status_check(buf, len);
> +
> + if (len < sizeof(struct wcn36xx_hal_msg_header) + sizeof(*rsp))
> + return -EIO;
> +
> + rsp = buf + sizeof(struct wcn36xx_hal_msg_header);
> +
> + if (WCN36XX_FW_MSG_RESULT_SUCCESS != rsp->status) {
> + pr_err("%s: bad status, len = %d\n", __func__, len);
> return rsp->status;
> + }
>
> return 0;
> }
> @@ -1884,7 +1907,8 @@ int wcn36xx_smd_trigger_ba(struct wcn36xx *wcn, u8 sta_index)
> wcn36xx_err("Sending hal_trigger_ba failed\n");
> goto out;
> }
> - ret = wcn36xx_smd_rsp_status_check(wcn->hal_buf, wcn->hal_rsp_len);
> + ret = wcn36xx_smd_rsp_status_check_bav2(wcn, wcn->hal_buf,
> + wcn->hal_rsp_len);
> if (ret) {
> wcn36xx_err("hal_trigger_ba response failed err=%d\n", ret);
> goto out;
> diff --git a/drivers/net/wireless/ath/wcn36xx/smd.h b/drivers/net/wireless/ath/wcn36xx/smd.h
> index 008d034..432d3b8 100644
> --- a/drivers/net/wireless/ath/wcn36xx/smd.h
> +++ b/drivers/net/wireless/ath/wcn36xx/smd.h
> @@ -44,6 +44,15 @@ struct wcn36xx_fw_msg_status_rsp {
> u32 status;
> } __packed;
>
> +/* wcn3620 returns this for tigger_ba */
> +
> +struct wcn36xx_fw_msg_status_rspv2 {
> + u8 bss_id[6];
> + u32 status __packed;
> + u16 count_following_candidates __packed;
> + /* candidate list follows */
> +};
> +
> struct wcn36xx_hal_ind_msg {
> struct list_head list;
> u8 *msg;
>
--
Best regards,
Eugene
^ permalink raw reply
* Re: [PATCH 4/7] net: wireless: wcn36xx: introduce WCN36XX_HAL_AVOID_FREQ_RANGE_IND
From: Eugene Krasnikov @ 2015-01-27 20:01 UTC (permalink / raw)
To: Andy Green; +Cc: Kalle Valo, wcn36xx, linux-wireless, netdev
In-Reply-To: <20150118051100.31866.37997.stgit@114-36-241-182.dynamic.hinet.net>
Do you know when is this message used? sounds important.
2015-01-18 5:11 GMT+00:00 Andy Green <andy.green@linaro.org>:
> WCN3620 firmware introduces a new async indication, we need to
> add it as a known message type so we can accept it
>
> Signed-off-by: Andy Green <andy.green@linaro.org>
> ---
> drivers/net/wireless/ath/wcn36xx/hal.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/wcn36xx/hal.h b/drivers/net/wireless/ath/wcn36xx/hal.h
> index a1f1127..b947de0 100644
> --- a/drivers/net/wireless/ath/wcn36xx/hal.h
> +++ b/drivers/net/wireless/ath/wcn36xx/hal.h
> @@ -345,6 +345,8 @@ enum wcn36xx_hal_host_msg_type {
> WCN36XX_HAL_DHCP_START_IND = 189,
> WCN36XX_HAL_DHCP_STOP_IND = 190,
>
> + WCN36XX_HAL_AVOID_FREQ_RANGE_IND = 233,
> +
> WCN36XX_HAL_MSG_MAX = WCN36XX_HAL_MSG_TYPE_MAX_ENUM_SIZE
> };
>
>
--
Best regards,
Eugene
^ permalink raw reply
* Re: Interaction between GSO and TSQ for single TCP stream
From: Eric Dumazet @ 2015-01-27 20:02 UTC (permalink / raw)
To: Tom Herbert, Neal Cardwell, Yuchung Cheng; +Cc: Linux Netdev List
In-Reply-To: <CA+mtBx8QSg+3VSiDgY6iqiJaQgScSd9FP-uxH8S5zGGv7tN1Yw@mail.gmail.com>
On Tue, Jan 27, 2015 at 11:57 AM, Tom Herbert <therbert@google.com> wrote:
> Eric,
>
> I am looking at why we are unable to achieve line rate throughput with
> a single connection using UDP encapsulation that supports GSO/GRO. I
> discovered that even for a non-encpasulated TCP connection I'm not
> able to get line rate using GSO/GRO (but do with TSO/LRO). There seems
> to be some interaction between TSQ and GSO. Setting
> tcp_limit_output_bytes to 1000000 gets single connection up to line
> rate for both native and encapsulated TCP.
>
> Some data:
>
> - netperf TCP_STREAM for a single connection no encapsulation
> Using TSO/LRO
> 9412.44 Gbps
> Using GSO/GRO (ethtool -K eth0 gso on gro on tso off lro off)
> 9286.08 Gbps
> Using GSO/GRO with larger limit (echo 1000000 >
> /proc/sys/net/ipv4/tcp_limit_output_bytes)
> 9412.75
>
> - netperf TCP_STREAM for a single connection for GUE-IPIP encapsulation with RCO
> Using GSO/GRO
> 8842.89 Gbps
> Using GSO/GRO with larger limit (echo 1000000 >
> /proc/sys/net/ipv4/tcp_limit_output_bytes)
> 9143.99 Gbps
>
> Any ideas on how to address this?
>
> Thanks,
> Tom
Hi Tom.
Yes, Eyal Perry reported the issue a while back, we plan to send
upstream patches to fix the issue today.
Make sure you tweaked coalescing parameters if you use mlx4 :
ethtool -C eth0 tx-usecs 4 tx-frames 4
Otherwise, the NIC accumulates too many packets before sending an
interrupt for TX completion.
Then you can either wait the patches, or try the one I sent :
http://permalink.gmane.org/gmane.linux.network/347023
^ permalink raw reply
* Re: Interaction between GSO and TSQ for single TCP stream
From: Tom Herbert @ 2015-01-27 20:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Neal Cardwell, Yuchung Cheng, Linux Netdev List
In-Reply-To: <CANn89iJCOuQfixdSp6TsPxpyvTxQSTLBJLgnsvbrbG2Am_p0-Q@mail.gmail.com>
On Tue, Jan 27, 2015 at 12:02 PM, Eric Dumazet <edumazet@google.com> wrote:
> On Tue, Jan 27, 2015 at 11:57 AM, Tom Herbert <therbert@google.com> wrote:
>> Eric,
>>
>> I am looking at why we are unable to achieve line rate throughput with
>> a single connection using UDP encapsulation that supports GSO/GRO. I
>> discovered that even for a non-encpasulated TCP connection I'm not
>> able to get line rate using GSO/GRO (but do with TSO/LRO). There seems
>> to be some interaction between TSQ and GSO. Setting
>> tcp_limit_output_bytes to 1000000 gets single connection up to line
>> rate for both native and encapsulated TCP.
>>
>> Some data:
>>
>> - netperf TCP_STREAM for a single connection no encapsulation
>> Using TSO/LRO
>> 9412.44 Gbps
>> Using GSO/GRO (ethtool -K eth0 gso on gro on tso off lro off)
>> 9286.08 Gbps
>> Using GSO/GRO with larger limit (echo 1000000 >
>> /proc/sys/net/ipv4/tcp_limit_output_bytes)
>> 9412.75
>>
>> - netperf TCP_STREAM for a single connection for GUE-IPIP encapsulation with RCO
>> Using GSO/GRO
>> 8842.89 Gbps
>> Using GSO/GRO with larger limit (echo 1000000 >
>> /proc/sys/net/ipv4/tcp_limit_output_bytes)
>> 9143.99 Gbps
>>
>> Any ideas on how to address this?
>>
>> Thanks,
>> Tom
>
> Hi Tom.
>
> Yes, Eyal Perry reported the issue a while back, we plan to send
> upstream patches to fix the issue today.
>
Awesome, looking forward to seeing them!
> Make sure you tweaked coalescing parameters if you use mlx4 :
>
> ethtool -C eth0 tx-usecs 4 tx-frames 4
>
It's bnx2x.
> Otherwise, the NIC accumulates too many packets before sending an
> interrupt for TX completion.
>
> Then you can either wait the patches, or try the one I sent :
> http://permalink.gmane.org/gmane.linux.network/347023
^ permalink raw reply
* Re: [PATCH v1] stmmac: prevent probe drivers to crash kernel
From: David Miller @ 2015-01-27 20:24 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: peppe.cavallaro, netdev
In-Reply-To: <1422376683-30555-1-git-send-email-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Tue, 27 Jan 2015 18:38:03 +0200
> In the case when alloc_netdev fails we return NULL to a caller. But there is no
> check for NULL in the probe drivers. This patch changes NULL to an error
> pointer. The function description is amended to reflect what we may get
> returned.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied, thank you.
^ permalink raw reply
* [PATCH] net: don't OOPS on socket aio
From: David Miller @ 2015-01-27 20:26 UTC (permalink / raw)
To: netdev; +Cc: hch
From: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/socket.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index a2c33a4..418795c 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -869,9 +869,6 @@ static ssize_t sock_splice_read(struct file *file, loff_t *ppos,
static struct sock_iocb *alloc_sock_iocb(struct kiocb *iocb,
struct sock_iocb *siocb)
{
- if (!is_sync_kiocb(iocb))
- BUG();
-
siocb->kiocb = iocb;
iocb->private = siocb;
return siocb;
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH net 0/2] netns: audit netdevice creation with IFLA_NET_NS_[PID|FD]
From: Alexander Aring @ 2015-01-27 20:26 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev, davem, arvid.brodin, linux-wpan
In-Reply-To: <54C7A5B7.60103@6wind.com>
On Tue, Jan 27, 2015 at 03:50:31PM +0100, Nicolas Dichtel wrote:
> Le 27/01/2015 15:06, Alexander Aring a écrit :
> >Hi,
> >
> >On Tue, Jan 27, 2015 at 02:28:47PM +0100, Nicolas Dichtel wrote:
> >...
> [snip]
> >>
> >>I don't know how wpan0 is created and if this interface can be created directly
> >>in another netns than init_net.
> >>
> >
> >no it can't. The wpan0 interface can be created via the 802.15.4
> >userspace tools and we don't have such option for namespaces. It
> >should be always to init_net while creation.
> Even with 'ip netns exec foo iwpan ...'?
>
I did a quick test:
diff --git a/net/mac802154/iface.c b/net/mac802154/iface.c
index 6fb6bdf..df55b42 100644
--- a/net/mac802154/iface.c
+++ b/net/mac802154/iface.c
@@ -590,6 +590,11 @@ ieee802154_if_add(struct ieee802154_local *local, const char *name,
list_add_tail_rcu(&sdata->list, &local->interfaces);
mutex_unlock(&local->iflist_mtx);
+ if (net_eq(dev_net(ndev), &init_net))
+ printk(KERN_INFO "it's init_net\n");
+ else
+ printk(KERN_INFO "it's not init_net\n");
With this patch and running:
ip netns exec foo iwpan phy phy0 interface add bar%d type node
I got a:
[ 52.032956] it's init_net
It's also init_net when I run with "ip netns exec foo iwpan ..."
> >
> >>>
> >>>
> >>>Summarize:
> >>>
> >>>I would add the dev->features |= NETIF_F_NETNS_LOCAL; while wpan
> >>>interface generation and add only the !net_eq(src_net, &init_net) check
> >>>above. I suppose that src_net is the net namespace from "underlaying"
> >>>interface wpan by calling:
> >>>
> >>>$ ip link add link wpan0 name lowpan0 type lowpan
> >>No. src_net is the netns where the ip command is launched. With this patch, my
> >
> >ah, and when no "ip netns" is given it's default to init_net?
> The default netns is the netns where your shell is running :)
Now, I understood how basically that works (I think).
> It may be different from init_net when you are playing on a virtual machine. On
> a physical machine, it's usually init_net.
>
ok.
> >
> >
> >Okay, then I agree with that both interfaces should be set
> >
> >dev->features |= NETIF_F_NETNS_LOCAL
> Ok.
>
> >
> >because both interfaces should started with "init_net" as default
> >namespace. For wpan interface this should always be in "init_net",
> >because we don't set anything while creation.
> Not sure this is true. It's probably possible to create it directly in another
> netns (with 'ip netns exec' or because your system is a virtual machine that
> runs over a namespaces construction (see docker [0], lxc [1], etc).
>
> [0] https://www.docker.com/
> [1] https://linuxcontainers.org/
>
ah, ok.
> >
> >For 6LoWPAN interface this should also always in the same namespace like
> >the wpan interface and not diffrent namespace between link (wpan) and
> >virtual (6LoWPAN) interface.
> >
> >Do you agree with that?
> Yes.
>
> But I still wonder if we should add a check about dev_net(dev) != init_net in
> net/ieee802154/6lowpan/core.c.
> If my understanding is correct:
> - wpan can be created directly in a netns != init_net
> - 6lowpan must be in the same netns than wpan
> - code under net/ieee802154 only works in init_net, thus 6lowpan only works
> in init_net.
>
> Do you agree?
yes. I will put the last item on my ToDo list if we can do more netns
stuff there.
> What about this (based on net-next)?
>
There are some little issues, see below.
> From 5ca1c46c68e4e4381b2f7e284f5dadeb28a53b2f Mon Sep 17 00:00:00 2001
> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Date: Tue, 27 Jan 2015 11:26:20 +0100
> Subject: [PATCH] wpan/6lowpan: fix netns settings
>
use "ieee802154:" instead "wpan/6lowpan:".
Can you rebase this patch on bluetooth-next?
> 6LoWPAN currently doesn't supports x-netns and works only in init_net.
>
> With this patch, we ensure that:
> - the wpan interface cannot be moved to another netns;
> - the 6lowpan interface cannot be moved to another netns;
> - the wpan interface is in the same netns than the 6lowpan interface;
> - the 6lowpan interface is in init_net.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
> net/ieee802154/6lowpan/core.c | 6 ++++--
> net/mac802154/iface.c | 1 +
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c
> index 055fbb71ba6f..dfd3c6007f60 100644
> --- a/net/ieee802154/6lowpan/core.c
> +++ b/net/ieee802154/6lowpan/core.c
> @@ -126,6 +126,7 @@ static void lowpan_setup(struct net_device *dev)
> dev->header_ops = &lowpan_header_ops;
> dev->ml_priv = &lowpan_mlme;
> dev->destructor = free_netdev;
> + dev->features |= NETIF_F_NETNS_LOCAL;
> }
>
> static int lowpan_validate(struct nlattr *tb[], struct nlattr *data[])
> @@ -148,10 +149,11 @@ static int lowpan_newlink(struct net *src_net, struct
> net_device *dev,
>
> pr_debug("adding new link\n");
>
> - if (!tb[IFLA_LINK])
> + if (!tb[IFLA_LINK] ||
> + !net_eq(dev_net(dev), &init_net))
> return -EINVAL;
> /* find and hold real wpan device */
> - real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
> + real_dev = dev_get_by_index(dev_net(dev), nla_get_u32(tb[IFLA_LINK]));
> if (!real_dev)
> return -ENODEV;
> if (real_dev->type != ARPHRD_IEEE802154) {
> diff --git a/net/mac802154/iface.c b/net/mac802154/iface.c
> index 6fb6bdf9868c..b67da8d578b4 100644
> --- a/net/mac802154/iface.c
> +++ b/net/mac802154/iface.c
> @@ -475,6 +475,7 @@ static void ieee802154_if_setup(struct net_device *dev)
> dev->mtu = IEEE802154_MTU;
> dev->tx_queue_len = 300;
> dev->flags = IFF_NOARP | IFF_BROADCAST;
> + dev->features |= NETIF_F_NETNS_LOCAL;
We should set this inside the cfg802154_netdev_notifier_call function
and NETDEV_REGISTER case. This can be found in "net/ieee802154/core.c". [0]
The branch "net/mac802154" affects 802.15.4 SoftMAC interfaces only. We
currently support SoftMAC only, but further we support HardMAC drivers.
The HardMAC drivers doesn't use the "net/mac802154" branch and call
netdev_register in driver layer.
When we do it in cfg802154_netdev_notifier_call then this will be set
for SoftMAC and HardMAC drivers (when we have a HardMAC driver). The
same behaviour can also be found in wireless implementation. [1]
- Alex
[0] http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/net/ieee802154/core.c#n227
[1] http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/net/wireless/core.c#n1000
^ permalink raw reply related
* Re: [PATCH 2/2] net wireless wcn36xx adapt wcnss platform to select module by DT
From: Eugene Krasnikov @ 2015-01-27 20:27 UTC (permalink / raw)
To: Andy Green; +Cc: Kalle Valo, wcn36xx, linux-wireless, netdev
In-Reply-To: <CAAfg0W6TWxi7Lp_nZZ7peuHvuYfBckeqRQaeo42snG=z2pMeag@mail.gmail.com>
What i mean is that it's not clear who knows what chip is this,
whether wcn36xx or wcn36xx_msm. Previously the assumption was that SMD
command will tell what interface to use. Now we are moving towards
wcn36xx_msm telling what chip is installed. Both approaches will work.
If it less work to do then fine.
Sorry for any confusion.
2015-01-19 9:34 GMT+00:00 Andy Green <andy.green@linaro.org>:
> On 19 January 2015 at 17:02, Eugene Krasnikov <k.eugene.e@gmail.com> wrote:
>> The idea is definitely better than just checking for AC support. But
>> the question is whether platform/hardware/firmware support that?
>
> Sorry I don't understand what might be unsupported.
>
> - We don't ask the firmware, we tell the driver what chip it is from
> the outside. There's nothing for the firmware to support.
>
> - Platform supports a set of ops via platform_data already. This
> just adds one op to get the chip type from the platform code.
>
> - What can't the hardware support? The hardware physically is a
> 3620, 3660 or 3680. We just tell the driver what it is when we
> instantiate the device. We don't ask anything of the hardware.
>
> I expected to have a debate about whether to move the dt support to
> wcn36xx directly which is also reasonable... there's no question
> adding an op will work or not, it will work for all cases like this.
> But it also implies there must be the "device faking" business in -msm
> code, one day that will also go upstream and then it might be
> considered a bit strange.
>
> I did it like this now because it's the minimum change from the
> current situation.
>
> -Andy
>
>> 2015-01-19 9:00 GMT+00:00 Andy Green <andy.green@linaro.org>:
>>> On 19 January 2015 at 16:49, Eugene Krasnikov <k.eugene.e@gmail.com> wrote:
>>>> Have you tested this code on any device other than wcn3620?
>>>
>>> No... the only hardware I have is 3620. But the only code we're
>>> adding to mainline is the patch with the ops to get the chip type.
>>>
>>> The two-patch series just shows one way to set that (which will
>>> certainly work for all three defined compatible types, if it works for
>>> one). And this code cannot go upstream.
>>>
>>> So the only decision to make is around whether adding the platform op
>>> is a good way (or, eg, directly add DT support to wcn36xx and
>>> eliminate the 'device regeneration' part of the OOT -msm code).
>>>
>>> At the moment the detect code does not work for 3620, so something
>>> needs to be done.
>>>
>>> -Andy
>>>
>>>> 2015-01-19 8:44 GMT+00:00 Andy Green <andy.green@linaro.org>:
>>>>> On 19 January 2015 at 16:34, Eugene Krasnikov <k.eugene.e@gmail.com> wrote:
>>>>>
>>>>>> So how do we insmod wcn36xx_msm with a parameter specifying what type
>>>>>> of hardware do we use?
>>>>>
>>>>> The type of chip is defined in the DT "compatible" which also delivers
>>>>> the resource information.
>>>>>
>>>>> qcom,wcn36xx@0a000000 {
>>>>> compatible = "qcom,wcn3620";
>>>>> reg = <0x0a000000 0x280000>;
>>>>> reg-names = "wcnss_mmio";
>>>>>
>>>>> interrupts = <0 145 0 0 146 0>;
>>>>> interrupt-names = "wcnss_wlantx_irq", "wcnss_wlanrx_irq";
>>>>> ...
>>>>>
>>>>> This bit based on your code can't go in mainline until there's some
>>>>> kind of PIL support.
>>>>>
>>>>> So the only things we can discuss about it for mainline purpose is
>>>>> whether using a platform ops is a good way to interface to the
>>>>> mainline driver.
>>>>>
>>>>> If you're OK with that and you want a module parameter then this can
>>>>> grow a module parameter and prefer to deliver the chip type from that
>>>>> if given, without modifying the platform op interface.
>>>>>
>>>>> But with or without a module parameter this can't be upstreamed right
>>>>> now due to PIL.
>>>>>
>>>>> -Andy
>>>>>
>>>>>> 2015-01-18 5:16 GMT+00:00 Andy Green <andy.green@linaro.org>:
>>>>>>> Simplify the resource handling and use DT to indicate which chip type
>>>>>>> we are dealing with
>>>>>>>
>>>>>>> Signed-off-by: Andy Green <andy.green@linaro.org>
>>>>>>> ---
>>>>>>> drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c | 101 ++++++++++++------------
>>>>>>> 1 file changed, 52 insertions(+), 49 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c b/drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c
>>>>>>> index f6f6c83..c9250e0 100644
>>>>>>> --- a/drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c
>>>>>>> +++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c
>>>>>>> @@ -42,7 +42,10 @@ struct wcn36xx_msm {
>>>>>>> struct completion smd_compl;
>>>>>>> smd_channel_t *smd_ch;
>>>>>>> struct pinctrl *pinctrl;
>>>>>>> -} wmsm;
>>>>>>> + enum wcn36xx_chip_type chip_type;
>>>>>>> +};
>>>>>>> +
>>>>>>> +static struct wcn36xx_msm wmsm;
>>>>>>>
>>>>>>> static int wcn36xx_msm_smsm_change_state(u32 clear_mask, u32 set_mask)
>>>>>>> {
>>>>>>> @@ -217,14 +220,47 @@ int wcn36xx_msm_powerup(const struct subsys_desc *desc)
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> +static const struct of_device_id wcn36xx_msm_match_table[] = {
>>>>>>> + { .compatible = "qcom,wcn3660", .data = (void *)WCN36XX_CHIP_3660 },
>>>>>>> + { .compatible = "qcom,wcn3680", .data = (void *)WCN36XX_CHIP_3680 },
>>>>>>> + { .compatible = "qcom,wcn3620", .data = (void *)WCN36XX_CHIP_3620 },
>>>>>>> + { }
>>>>>>> +};
>>>>>>> +
>>>>>>> +static int wcn36xx_msm_get_chip_type(void)
>>>>>>> +{
>>>>>>> + return wmsm.chip_type;
>>>>>>> +}
>>>>>>> +
>>>>>>> +static struct wcn36xx_msm wmsm = {
>>>>>>> + .ctrl_ops = {
>>>>>>> + .open = wcn36xx_msm_smd_open,
>>>>>>> + .close = wcn36xx_msm_smd_close,
>>>>>>> + .tx = wcn36xx_msm_smd_send_and_wait,
>>>>>>> + .get_hw_mac = wcn36xx_msm_get_hw_mac,
>>>>>>> + .smsm_change_state = wcn36xx_msm_smsm_change_state,
>>>>>>> + .get_chip_type = wcn36xx_msm_get_chip_type,
>>>>>>> + },
>>>>>>> +};
>>>>>>> +
>>>>>>> static int wcn36xx_msm_probe(struct platform_device *pdev)
>>>>>>> {
>>>>>>> int ret;
>>>>>>> - struct resource *wcnss_memory;
>>>>>>> - struct resource *tx_irq;
>>>>>>> - struct resource *rx_irq;
>>>>>>> + const struct of_device_id *of_id;
>>>>>>> + struct resource *r;
>>>>>>> struct resource res[3];
>>>>>>> struct pinctrl_state *ps;
>>>>>>> + static const char const *rnames[] = {
>>>>>>> + "wcnss_mmio", "wcnss_wlantx_irq", "wcnss_wlanrx_irq" };
>>>>>>> + static const int rtype[] = {
>>>>>>> + IORESOURCE_MEM, IORESOURCE_IRQ, IORESOURCE_IRQ };
>>>>>>> + int n;
>>>>>>> +
>>>>>>> + of_id = of_match_node(wcn36xx_msm_match_table, pdev->dev.of_node);
>>>>>>> + if (!of_id)
>>>>>>> + return -EINVAL;
>>>>>>> +
>>>>>>> + wmsm.chip_type = (enum wcn36xx_chip_type)of_id->data;
>>>>>>>
>>>>>>> wmsm.pinctrl = devm_pinctrl_get(&pdev->dev);
>>>>>>> if (IS_ERR_OR_NULL(wmsm.pinctrl))
>>>>>>> @@ -240,52 +276,23 @@ static int wcn36xx_msm_probe(struct platform_device *pdev)
>>>>>>>
>>>>>>> if (IS_ERR_OR_NULL(pil))
>>>>>>> pil = subsystem_get("wcnss");
>>>>>>> - if (IS_ERR_OR_NULL(pil))
>>>>>>> - return PTR_ERR(pil);
>>>>>>> + if (IS_ERR_OR_NULL(pil))
>>>>>>> + return PTR_ERR(pil);
>>>>>>>
>>>>>>> wmsm.core = platform_device_alloc("wcn36xx", -1);
>>>>>>>
>>>>>>> - //dev_err(&pdev->dev, "%s starting\n", __func__);
>>>>>>> -
>>>>>>> - memset(res, 0x00, sizeof(res));
>>>>>>> - wmsm.ctrl_ops.open = wcn36xx_msm_smd_open;
>>>>>>> - wmsm.ctrl_ops.close = wcn36xx_msm_smd_close;
>>>>>>> - wmsm.ctrl_ops.tx = wcn36xx_msm_smd_send_and_wait;
>>>>>>> - wmsm.ctrl_ops.get_hw_mac = wcn36xx_msm_get_hw_mac;
>>>>>>> - wmsm.ctrl_ops.smsm_change_state = wcn36xx_msm_smsm_change_state;
>>>>>>> - wcnss_memory =
>>>>>>> - platform_get_resource_byname(pdev,
>>>>>>> - IORESOURCE_MEM,
>>>>>>> - "wcnss_mmio");
>>>>>>> - if (wcnss_memory == NULL) {
>>>>>>> - dev_err(&wmsm.core->dev,
>>>>>>> - "Failed to get wcnss wlan memory map.\n");
>>>>>>> - ret = -ENOMEM;
>>>>>>> - return ret;
>>>>>>> - }
>>>>>>> - memcpy(&res[0], wcnss_memory, sizeof(*wcnss_memory));
>>>>>>> -
>>>>>>> - tx_irq = platform_get_resource_byname(pdev,
>>>>>>> - IORESOURCE_IRQ,
>>>>>>> - "wcnss_wlantx_irq");
>>>>>>> - if (tx_irq == NULL) {
>>>>>>> - dev_err(&wmsm.core->dev, "Failed to get wcnss tx_irq");
>>>>>>> - ret = -ENOMEM;
>>>>>>> - return ret;
>>>>>>> - }
>>>>>>> - memcpy(&res[1], tx_irq, sizeof(*tx_irq));
>>>>>>> -
>>>>>>> - rx_irq = platform_get_resource_byname(pdev,
>>>>>>> - IORESOURCE_IRQ,
>>>>>>> - "wcnss_wlanrx_irq");
>>>>>>> - if (rx_irq == NULL) {
>>>>>>> - dev_err(&wmsm.core->dev, "Failed to get wcnss rx_irq");
>>>>>>> - ret = -ENOMEM;
>>>>>>> - return ret;
>>>>>>> + for (n = 0; n < ARRAY_SIZE(rnames); n++) {
>>>>>>> + r = platform_get_resource_byname(pdev, rtype[n], rnames[n]);
>>>>>>> + if (!r) {
>>>>>>> + dev_err(&wmsm.core->dev,
>>>>>>> + "Missing resource %s'\n", rnames[n]);
>>>>>>> + ret = -ENOMEM;
>>>>>>> + return ret;
>>>>>>> + }
>>>>>>> + res[n] = *r;
>>>>>>> }
>>>>>>> - memcpy(&res[2], rx_irq, sizeof(*rx_irq));
>>>>>>>
>>>>>>> - platform_device_add_resources(wmsm.core, res, ARRAY_SIZE(res));
>>>>>>> + platform_device_add_resources(wmsm.core, res, n);
>>>>>>>
>>>>>>> ret = platform_device_add_data(wmsm.core, &wmsm.ctrl_ops,
>>>>>>> sizeof(wmsm.ctrl_ops));
>>>>>>> @@ -319,10 +326,6 @@ static int wcn36xx_msm_remove(struct platform_device *pdev)
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> -static const struct of_device_id wcn36xx_msm_match_table[] = {
>>>>>>> - { .compatible = "qcom,wcn36xx" },
>>>>>>> - { }
>>>>>>> -};
>>>>>>> MODULE_DEVICE_TABLE(of, wcn36xx_msm_match_table);
>>>>>>>
>>>>>>> static struct platform_driver wcn36xx_msm_driver = {
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best regards,
>>>>>> Eugene
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Eugene
>>
>>
>>
>> --
>> Best regards,
>> Eugene
--
Best regards,
Eugene
^ permalink raw reply
* Loan Offer
From: Frank Moses @ 2015-01-27 13:04 UTC (permalink / raw)
To: Recipients
I am Frank Moses a private lender located in USA.I can help you with a loan you are looking for @ 3% interest rate,For Urgent Response Email: frankloanmoses@gmail.com
Frank Moses.
Email: frankloanmoses@gmail.com
Telephone:(781)-369-5127
^ permalink raw reply
* [PATCH net-next 0/5] fix stretch ACK bugs in TCP CUBIC and Reno
From: Neal Cardwell @ 2015-01-27 20:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Neal Cardwell
This patch series fixes the TCP CUBIC and Reno congestion control
modules to properly handle stretch ACKs in their respective additive
increase modes, and in the transitions from slow start to additive
increase.
This finishes the project started by commit 9f9843a751d0a2057 ("tcp:
properly handle stretch acks in slow start"), which fixed behavior for
TCP congestion control when handling stretch ACKs in slow start mode.
Motivation: In the Jan 2015 netdev thread 'BW regression after "tcp:
refine TSO autosizing"', Eyal Perry documented a regression that Eric
Dumazet determined was caused by improper handling of TCP stretch
ACKs.
Background: LRO, GRO, delayed ACKs, and middleboxes can cause "stretch
ACKs" that cover more than the RFC-specified maximum of 2
packets. These stretch ACKs can cause serious performance shortfalls
in common congestion control algorithms, like Reno and CUBIC, which
were designed and tuned years ago with receiver hosts that were not
using LRO or GRO, and were instead ACKing every other packet.
Testing: at Google we have been using this approach for handling
stretch ACKs for CUBIC datacenter and Internet traffic for several
years, with good results.
Neal Cardwell (5):
tcp: stretch ACK fixes prep
tcp: fix the timid additive increase on stretch ACKs
tcp: fix stretch ACK bugs in Reno
tcp: fix stretch ACK bugs in CUBIC
tcp: fix timing issue in CUBIC slope calculation
include/net/tcp.h | 4 ++--
net/ipv4/tcp_bic.c | 2 +-
net/ipv4/tcp_cong.c | 32 ++++++++++++++++++++------------
net/ipv4/tcp_cubic.c | 38 +++++++++++++++++---------------------
net/ipv4/tcp_scalable.c | 3 ++-
net/ipv4/tcp_veno.c | 2 +-
net/ipv4/tcp_yeah.c | 2 +-
7 files changed, 44 insertions(+), 39 deletions(-)
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply
* [PATCH net-next 1/5] tcp: stretch ACK fixes prep
From: Neal Cardwell @ 2015-01-27 20:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Neal Cardwell, Yuchung Cheng, Eric Dumazet
In-Reply-To: <1422390883-15603-1-git-send-email-ncardwell@google.com>
LRO, GRO, delayed ACKs, and middleboxes can cause "stretch ACKs" that
cover more than the RFC-specified maximum of 2 packets. These stretch
ACKs can cause serious performance shortfalls in common congestion
control algorithms that were designed and tuned years ago with
receiver hosts that were not using LRO or GRO, and were instead
politely ACKing every other packet.
This patch series fixes Reno and CUBIC to handle stretch ACKs.
This patch prepares for the upcoming stretch ACK bug fix patches. It
adds an "acked" parameter to tcp_cong_avoid_ai() to allow for future
fixes to tcp_cong_avoid_ai() to correctly handle stretch ACKs, and
changes all congestion control algorithms to pass in 1 for the ACKed
count. It also changes tcp_slow_start() to return the number of packet
ACK "credits" that were not processed in slow start mode, and can be
processed by the congestion control module in additive increase mode.
In future patches we will fix tcp_cong_avoid_ai() to handle stretch
ACKs, and fix Reno and CUBIC handling of stretch ACKs in slow start
and additive increase mode.
Reported-by: Eyal Perry <eyalpe@mellanox.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/tcp.h | 4 ++--
net/ipv4/tcp_bic.c | 2 +-
net/ipv4/tcp_cong.c | 11 +++++++----
net/ipv4/tcp_cubic.c | 2 +-
net/ipv4/tcp_scalable.c | 3 ++-
net/ipv4/tcp_veno.c | 2 +-
net/ipv4/tcp_yeah.c | 2 +-
7 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index b8fdc6b..9021f7b 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -843,8 +843,8 @@ void tcp_get_available_congestion_control(char *buf, size_t len);
void tcp_get_allowed_congestion_control(char *buf, size_t len);
int tcp_set_allowed_congestion_control(char *allowed);
int tcp_set_congestion_control(struct sock *sk, const char *name);
-void tcp_slow_start(struct tcp_sock *tp, u32 acked);
-void tcp_cong_avoid_ai(struct tcp_sock *tp, u32 w);
+int tcp_slow_start(struct tcp_sock *tp, u32 acked);
+void tcp_cong_avoid_ai(struct tcp_sock *tp, u32 w, u32 acked);
u32 tcp_reno_ssthresh(struct sock *sk);
void tcp_reno_cong_avoid(struct sock *sk, u32 ack, u32 acked);
diff --git a/net/ipv4/tcp_bic.c b/net/ipv4/tcp_bic.c
index bb395d4..c037644 100644
--- a/net/ipv4/tcp_bic.c
+++ b/net/ipv4/tcp_bic.c
@@ -150,7 +150,7 @@ static void bictcp_cong_avoid(struct sock *sk, u32 ack, u32 acked)
tcp_slow_start(tp, acked);
else {
bictcp_update(ca, tp->snd_cwnd);
- tcp_cong_avoid_ai(tp, ca->cnt);
+ tcp_cong_avoid_ai(tp, ca->cnt, 1);
}
}
diff --git a/net/ipv4/tcp_cong.c b/net/ipv4/tcp_cong.c
index 63c29db..75d0141 100644
--- a/net/ipv4/tcp_cong.c
+++ b/net/ipv4/tcp_cong.c
@@ -360,25 +360,28 @@ int tcp_set_congestion_control(struct sock *sk, const char *name)
* ABC caps N to 2. Slow start exits when cwnd grows over ssthresh and
* returns the leftover acks to adjust cwnd in congestion avoidance mode.
*/
-void tcp_slow_start(struct tcp_sock *tp, u32 acked)
+int tcp_slow_start(struct tcp_sock *tp, u32 acked)
{
u32 cwnd = tp->snd_cwnd + acked;
if (cwnd > tp->snd_ssthresh)
cwnd = tp->snd_ssthresh + 1;
+ acked -= cwnd - tp->snd_cwnd;
tp->snd_cwnd = min(cwnd, tp->snd_cwnd_clamp);
+
+ return acked;
}
EXPORT_SYMBOL_GPL(tcp_slow_start);
/* In theory this is tp->snd_cwnd += 1 / tp->snd_cwnd (or alternative w) */
-void tcp_cong_avoid_ai(struct tcp_sock *tp, u32 w)
+void tcp_cong_avoid_ai(struct tcp_sock *tp, u32 w, u32 acked)
{
if (tp->snd_cwnd_cnt >= w) {
if (tp->snd_cwnd < tp->snd_cwnd_clamp)
tp->snd_cwnd++;
tp->snd_cwnd_cnt = 0;
} else {
- tp->snd_cwnd_cnt++;
+ tp->snd_cwnd_cnt += acked;
}
}
EXPORT_SYMBOL_GPL(tcp_cong_avoid_ai);
@@ -402,7 +405,7 @@ void tcp_reno_cong_avoid(struct sock *sk, u32 ack, u32 acked)
tcp_slow_start(tp, acked);
/* In dangerous area, increase slowly. */
else
- tcp_cong_avoid_ai(tp, tp->snd_cwnd);
+ tcp_cong_avoid_ai(tp, tp->snd_cwnd, 1);
}
EXPORT_SYMBOL_GPL(tcp_reno_cong_avoid);
diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c
index 6b60024..df4bc4d 100644
--- a/net/ipv4/tcp_cubic.c
+++ b/net/ipv4/tcp_cubic.c
@@ -320,7 +320,7 @@ static void bictcp_cong_avoid(struct sock *sk, u32 ack, u32 acked)
tcp_slow_start(tp, acked);
} else {
bictcp_update(ca, tp->snd_cwnd);
- tcp_cong_avoid_ai(tp, ca->cnt);
+ tcp_cong_avoid_ai(tp, ca->cnt, 1);
}
}
diff --git a/net/ipv4/tcp_scalable.c b/net/ipv4/tcp_scalable.c
index 6824afb..333bcb2 100644
--- a/net/ipv4/tcp_scalable.c
+++ b/net/ipv4/tcp_scalable.c
@@ -25,7 +25,8 @@ static void tcp_scalable_cong_avoid(struct sock *sk, u32 ack, u32 acked)
if (tp->snd_cwnd <= tp->snd_ssthresh)
tcp_slow_start(tp, acked);
else
- tcp_cong_avoid_ai(tp, min(tp->snd_cwnd, TCP_SCALABLE_AI_CNT));
+ tcp_cong_avoid_ai(tp, min(tp->snd_cwnd, TCP_SCALABLE_AI_CNT),
+ 1);
}
static u32 tcp_scalable_ssthresh(struct sock *sk)
diff --git a/net/ipv4/tcp_veno.c b/net/ipv4/tcp_veno.c
index a4d2d2d..112151e 100644
--- a/net/ipv4/tcp_veno.c
+++ b/net/ipv4/tcp_veno.c
@@ -159,7 +159,7 @@ static void tcp_veno_cong_avoid(struct sock *sk, u32 ack, u32 acked)
/* In the "non-congestive state", increase cwnd
* every rtt.
*/
- tcp_cong_avoid_ai(tp, tp->snd_cwnd);
+ tcp_cong_avoid_ai(tp, tp->snd_cwnd, 1);
} else {
/* In the "congestive state", increase cwnd
* every other rtt.
diff --git a/net/ipv4/tcp_yeah.c b/net/ipv4/tcp_yeah.c
index cd72732..17d3566 100644
--- a/net/ipv4/tcp_yeah.c
+++ b/net/ipv4/tcp_yeah.c
@@ -92,7 +92,7 @@ static void tcp_yeah_cong_avoid(struct sock *sk, u32 ack, u32 acked)
} else {
/* Reno */
- tcp_cong_avoid_ai(tp, tp->snd_cwnd);
+ tcp_cong_avoid_ai(tp, tp->snd_cwnd, 1);
}
/* The key players are v_vegas.beg_snd_una and v_beg_snd_nxt.
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH net-next 2/5] tcp: fix the timid additive increase on stretch ACKs
From: Neal Cardwell @ 2015-01-27 20:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Neal Cardwell, Yuchung Cheng, Eric Dumazet
In-Reply-To: <1422390883-15603-1-git-send-email-ncardwell@google.com>
tcp_cong_avoid_ai() was too timid (snd_cwnd increased too slowly) on
"stretch ACKs" -- cases where the receiver ACKed more than 1 packet in
a single ACK. For example, suppose w is 10 and we get a stretch ACK
for 20 packets, so acked is 20. We ought to increase snd_cwnd by 2
(since acked/w = 20/10 = 2), but instead we were only increasing cwnd
by 1. This patch fixes that behavior.
Reported-by: Eyal Perry <eyalpe@mellanox.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/tcp_cong.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/tcp_cong.c b/net/ipv4/tcp_cong.c
index 75d0141..ec78f56 100644
--- a/net/ipv4/tcp_cong.c
+++ b/net/ipv4/tcp_cong.c
@@ -373,16 +373,19 @@ int tcp_slow_start(struct tcp_sock *tp, u32 acked)
}
EXPORT_SYMBOL_GPL(tcp_slow_start);
-/* In theory this is tp->snd_cwnd += 1 / tp->snd_cwnd (or alternative w) */
+/* In theory this is tp->snd_cwnd += 1 / tp->snd_cwnd (or alternative w),
+ * for every packet that was ACKed.
+ */
void tcp_cong_avoid_ai(struct tcp_sock *tp, u32 w, u32 acked)
{
+ tp->snd_cwnd_cnt += acked;
if (tp->snd_cwnd_cnt >= w) {
- if (tp->snd_cwnd < tp->snd_cwnd_clamp)
- tp->snd_cwnd++;
- tp->snd_cwnd_cnt = 0;
- } else {
- tp->snd_cwnd_cnt += acked;
+ u32 delta = tp->snd_cwnd_cnt / w;
+
+ tp->snd_cwnd_cnt -= delta * w;
+ tp->snd_cwnd += delta;
}
+ tp->snd_cwnd = min(tp->snd_cwnd, tp->snd_cwnd_clamp);
}
EXPORT_SYMBOL_GPL(tcp_cong_avoid_ai);
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH net-next 3/5] tcp: fix stretch ACK bugs in Reno
From: Neal Cardwell @ 2015-01-27 20:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Neal Cardwell, Yuchung Cheng, Eric Dumazet
In-Reply-To: <1422390883-15603-1-git-send-email-ncardwell@google.com>
Change Reno to properly handle stretch ACKs in additive increase mode
by passing in the count of ACKed packets to tcp_cong_avoid_ai().
In addition, if snd_cwnd crosses snd_ssthresh during slow start
processing, and we then exit slow start mode, we need to carry over
any remaining "credit" for packets ACKed and apply that to additive
increase by passing this remaining "acked" count to
tcp_cong_avoid_ai().
Reported-by: Eyal Perry <eyalpe@mellanox.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/tcp_cong.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/tcp_cong.c b/net/ipv4/tcp_cong.c
index ec78f56..319718d 100644
--- a/net/ipv4/tcp_cong.c
+++ b/net/ipv4/tcp_cong.c
@@ -404,11 +404,13 @@ void tcp_reno_cong_avoid(struct sock *sk, u32 ack, u32 acked)
return;
/* In "safe" area, increase. */
- if (tp->snd_cwnd <= tp->snd_ssthresh)
- tcp_slow_start(tp, acked);
+ if (tp->snd_cwnd <= tp->snd_ssthresh) {
+ acked = tcp_slow_start(tp, acked);
+ if (!acked)
+ return;
+ }
/* In dangerous area, increase slowly. */
- else
- tcp_cong_avoid_ai(tp, tp->snd_cwnd, 1);
+ tcp_cong_avoid_ai(tp, tp->snd_cwnd, acked);
}
EXPORT_SYMBOL_GPL(tcp_reno_cong_avoid);
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH net-next 4/5] tcp: fix stretch ACK bugs in CUBIC
From: Neal Cardwell @ 2015-01-27 20:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Neal Cardwell, Yuchung Cheng, Eric Dumazet
In-Reply-To: <1422390883-15603-1-git-send-email-ncardwell@google.com>
Change CUBIC to properly handle stretch ACKs in additive increase mode
by passing in the count of ACKed packets to tcp_cong_avoid_ai().
In addition, because we are now precisely accounting for stretch ACKs,
including delayed ACKs, we can now remove the delayed ACK tracking and
estimation code that tracked recent delayed ACK behavior in
ca->delayed_ack.
Reported-by: Eyal Perry <eyalpe@mellanox.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/tcp_cubic.c | 30 +++++++++---------------------
1 file changed, 9 insertions(+), 21 deletions(-)
diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c
index df4bc4d..e036958 100644
--- a/net/ipv4/tcp_cubic.c
+++ b/net/ipv4/tcp_cubic.c
@@ -93,9 +93,7 @@ struct bictcp {
u32 epoch_start; /* beginning of an epoch */
u32 ack_cnt; /* number of acks */
u32 tcp_cwnd; /* estimated tcp cwnd */
-#define ACK_RATIO_SHIFT 4
-#define ACK_RATIO_LIMIT (32u << ACK_RATIO_SHIFT)
- u16 delayed_ack; /* estimate the ratio of Packets/ACKs << 4 */
+ u16 unused;
u8 sample_cnt; /* number of samples to decide curr_rtt */
u8 found; /* the exit point is found? */
u32 round_start; /* beginning of each round */
@@ -114,7 +112,6 @@ static inline void bictcp_reset(struct bictcp *ca)
ca->bic_K = 0;
ca->delay_min = 0;
ca->epoch_start = 0;
- ca->delayed_ack = 2 << ACK_RATIO_SHIFT;
ca->ack_cnt = 0;
ca->tcp_cwnd = 0;
ca->found = 0;
@@ -205,12 +202,12 @@ static u32 cubic_root(u64 a)
/*
* Compute congestion window to use.
*/
-static inline void bictcp_update(struct bictcp *ca, u32 cwnd)
+static inline void bictcp_update(struct bictcp *ca, u32 cwnd, u32 acked)
{
u32 delta, bic_target, max_cnt;
u64 offs, t;
- ca->ack_cnt++; /* count the number of ACKs */
+ ca->ack_cnt += acked; /* count the number of ACKed packets */
if (ca->last_cwnd == cwnd &&
(s32)(tcp_time_stamp - ca->last_time) <= HZ / 32)
@@ -221,7 +218,7 @@ static inline void bictcp_update(struct bictcp *ca, u32 cwnd)
if (ca->epoch_start == 0) {
ca->epoch_start = tcp_time_stamp; /* record beginning */
- ca->ack_cnt = 1; /* start counting */
+ ca->ack_cnt = acked; /* start counting */
ca->tcp_cwnd = cwnd; /* syn with cubic */
if (ca->last_max_cwnd <= cwnd) {
@@ -301,7 +298,6 @@ static inline void bictcp_update(struct bictcp *ca, u32 cwnd)
}
}
- ca->cnt = (ca->cnt << ACK_RATIO_SHIFT) / ca->delayed_ack;
if (ca->cnt == 0) /* cannot be zero */
ca->cnt = 1;
}
@@ -317,11 +313,12 @@ static void bictcp_cong_avoid(struct sock *sk, u32 ack, u32 acked)
if (tp->snd_cwnd <= tp->snd_ssthresh) {
if (hystart && after(ack, ca->end_seq))
bictcp_hystart_reset(sk);
- tcp_slow_start(tp, acked);
- } else {
- bictcp_update(ca, tp->snd_cwnd);
- tcp_cong_avoid_ai(tp, ca->cnt, 1);
+ acked = tcp_slow_start(tp, acked);
+ if (!acked)
+ return;
}
+ bictcp_update(ca, tp->snd_cwnd, acked);
+ tcp_cong_avoid_ai(tp, ca->cnt, acked);
}
static u32 bictcp_recalc_ssthresh(struct sock *sk)
@@ -416,15 +413,6 @@ static void bictcp_acked(struct sock *sk, u32 cnt, s32 rtt_us)
struct bictcp *ca = inet_csk_ca(sk);
u32 delay;
- if (icsk->icsk_ca_state == TCP_CA_Open) {
- u32 ratio = ca->delayed_ack;
-
- ratio -= ca->delayed_ack >> ACK_RATIO_SHIFT;
- ratio += cnt;
-
- ca->delayed_ack = clamp(ratio, 1U, ACK_RATIO_LIMIT);
- }
-
/* Some calls are for duplicates without timetamps */
if (rtt_us < 0)
return;
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH net-next 5/5] tcp: fix timing issue in CUBIC slope calculation
From: Neal Cardwell @ 2015-01-27 20:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Neal Cardwell, Yuchung Cheng, Eric Dumazet
In-Reply-To: <1422390883-15603-1-git-send-email-ncardwell@google.com>
This patch fixes a bug in CUBIC that causes cwnd to increase slightly
too slowly when multiple ACKs arrive in the same jiffy.
If cwnd is supposed to increase at a rate of more than once per jiffy,
then CUBIC was sometimes too slow. Because the bic_target is
calculated for a future point in time, calculated with time in
jiffies, the cwnd can increase over the course of the jiffy while the
bic_target calculated as the proper CUBIC cwnd at time
t=tcp_time_stamp+rtt does not increase, because tcp_time_stamp only
increases on jiffy tick boundaries.
So since the cnt is set to:
ca->cnt = cwnd / (bic_target - cwnd);
as cwnd increases but bic_target does not increase due to jiffy
granularity, the cnt becomes too large, causing cwnd to increase
too slowly.
For example:
- suppose at the beginning of a jiffy, cwnd=40, bic_target=44
- so CUBIC sets:
ca->cnt = cwnd / (bic_target - cwnd) = 40 / (44 - 40) = 40/4 = 10
- suppose we get 10 acks, each for 1 segment, so tcp_cong_avoid_ai()
increases cwnd to 41
- so CUBIC sets:
ca->cnt = cwnd / (bic_target - cwnd) = 41 / (44 - 41) = 41 / 3 = 13
So now CUBIC will wait for 13 packets to be ACKed before increasing
cwnd to 42, insted of 10 as it should.
The fix is to avoid adjusting the slope (determined by ca->cnt)
multiple times within a jiffy, and instead skip to compute the Reno
cwnd, the "TCP friendliness" code path.
Reported-by: Eyal Perry <eyalpe@mellanox.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/tcp_cubic.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c
index e036958..4f91141 100644
--- a/net/ipv4/tcp_cubic.c
+++ b/net/ipv4/tcp_cubic.c
@@ -213,6 +213,13 @@ static inline void bictcp_update(struct bictcp *ca, u32 cwnd, u32 acked)
(s32)(tcp_time_stamp - ca->last_time) <= HZ / 32)
return;
+ /* The CUBIC function can update ca->cnt at most once per jiffy.
+ * On all cwnd reduction events, ca->epoch_start is set to 0,
+ * which will force a recalculation of ca->cnt.
+ */
+ if (ca->epoch_start && tcp_time_stamp == ca->last_time)
+ goto tcp_friendliness;
+
ca->last_cwnd = cwnd;
ca->last_time = tcp_time_stamp;
@@ -280,6 +287,7 @@ static inline void bictcp_update(struct bictcp *ca, u32 cwnd, u32 acked)
if (ca->last_max_cwnd == 0 && ca->cnt > 20)
ca->cnt = 20; /* increase cwnd 5% per RTT */
+tcp_friendliness:
/* TCP Friendly */
if (tcp_friendliness) {
u32 scale = beta_scale;
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [GIT] Networking
From: David Miller @ 2015-01-27 20:36 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Don't OOPS on socket AIO, from Christoph Hellwig.
2) Scheduled scans should be aborted upon RFKILL, from Emmanuel Grumbach.
3) Fix sleep in atomic context in kvaser_usb, from Ahmed S. Darwish.
4) Fix RCU locking across copy_to_user() in bpf code, from Alexei
Starovoitov.
5) Lots of crash, memory leak, short TX packet et al. bug fixes in sh_eth
from Ben Hutchings.
6) Fix memory corruption in SCTP wrt. INIT collitions, from Daniel
Borkmann.
7) Fix return value logic for poll handlers in netxen, enic, and
bnx2x. From Eric Dumazet and Govindarajulu Varadarajan.
8) Header length calculation fix in mac80211 from Fred Chou.
9) mv643xx_eth doesn't handle highmem correctly in non-TSO code
paths. From Ezequiel Garcia.
10) udp_diag has bogus logic in it's hash chain skipping, copy
same fix tcp diag used. From Herbert Xu.
11) amd-xgbe programs wrong rx flow control register, from Thomas
Lendacky.
12) Fix race leading to use after free in ping receive path,
from Subash Abhinov Kasiviswanathan.
13) Cache redirect routes otherwise we can get a heavy backlog
of rcu jobs liberating DST_NOCACHE entries. From Hannes
Frederic Sowa.
Please pull, thanks a lot!
The following changes since commit 06efe0e54018cb19cf0807447dc3ac747ffcfd1c:
Merge tag 'pinctrl-v3.19-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl (2015-01-20 21:23:41 +1200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
for you to fetch changes up to 06539d3071067ff146a9bffd1c801fa56d290909:
net: don't OOPS on socket aio (2015-01-27 12:25:33 -0800)
----------------------------------------------------------------
Ahmed S. Darwish (4):
can: kvaser_usb: Do not sleep in atomic context
can: kvaser_usb: Send correct context to URB completion
can: kvaser_usb: Retry the first bulk transfer on -ETIMEDOUT
can: kvaser_usb: Fix state handling upon BUS_ERROR events
Alexei Starovoitov (2):
bpf: rcu lock must not be held when calling copy_to_user()
samples: bpf: relax test_maps check
Andy Shevchenko (1):
stmmac: prevent probe drivers to crash kernel
Ben Hutchings (8):
sh_eth: Fix padding of short frames on TX
sh_eth: Detach net device when stopping queue to resize DMA rings
sh_eth: Fix crash or memory leak when resizing rings on device that is down
sh_eth: Fix serialisation of interrupt disable with interrupt & NAPI handlers
sh_eth: Remove RX overflow log messages
sh_eth: Ensure DMA engines are stopped before freeing buffers
sh_eth: Check for DMA mapping errors on transmit
sh_eth: Fix DMA-API usage for RX buffers
Christoph Hellwig (1):
net: don't OOPS on socket aio
Daniel Borkmann (3):
net: cls_bpf: fix size mismatch on filter preparation
net: cls_bpf: fix auto generation of per list handles
net: sctp: fix slab corruption from use after free on INIT collisions
David S. Miller (10):
Merge tag 'wireless-drivers-for-davem-2015-01-20' of git://git.kernel.org/.../kvalo/wireless-drivers
Merge branch 's390'
Merge tag 'linux-can-fixes-for-3.19-20150121' of git://git.kernel.org/.../mkl/linux-can
Merge branch 'cls_bpf'
Merge branch 'sh_eth'
Merge branch 'bpf'
Merge tag 'mac80211-for-davem-2015-01-23' of git://git.kernel.org/.../jberg/mac80211
Merge tag 'linux-can-fixes-for-3.19-20150127' of git://git.kernel.org/.../mkl/linux-can
Merge branch 'sh_eth'
Merge branch 'master' of git://git.kernel.org/.../klassert/ipsec
David Spinadel (1):
iwlwifi: mvm: fix EBS on single scan
Emmanuel Grumbach (2):
iwlwifi: mvm: drop non VO frames when flushing
iwlwifi: mvm: abort scheduled scan upon RFKILL
Eric Dumazet (1):
netxen: fix netxen_nic_poll() logic
Eugene Crosser (1):
qeth: clean up error handling
Eyal Shapira (1):
iwlwifi: mvm: set the tx cmd tid for BAR frame correctly
Ezequiel Garcia (1):
net: mv643xx_eth: Fix highmem support in non-TSO egress path
Felix Fietkau (1):
ath9k: fix race condition in irq processing during hardware reset
Fred Chou (1):
mac80211: correct header length calculation
Govindarajulu Varadarajan (2):
enic: fix rx napi poll return value
bnx2x: fix napi poll return value for repoll
Hannes Frederic Sowa (2):
ipv4: try to cache dst_entries which would cause a redirect
ipv6: replacing a rt6_info needs to purge possible propagated rt6_infos too
Herbert Xu (1):
udp_diag: Fix socket skipping within chain
Johannes Berg (1):
nl80211: fix per-station group key get/del and memory leak
Kalle Valo (2):
Merge tag 'iwlwifi-for-kalle-2015-01-13' of https://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Merge tag 'iwlwifi-for-kalle-2015-01-15' of https://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Lendacky, Thomas (1):
amd-xgbe: Use proper Rx flow control register
Luciano Coelho (1):
mac80211: only roll back station states for WDS when suspending
Mahesh Bandewar (1):
ipvlan: fix incorrect usage of IS_ERR() macro in IPv6 code path.
Martin KaFai Lau (1):
ipv6: Fix __ip6_route_redirect
Mathy Vanhoef (1):
mac80211: properly set CCK flag in radiotap
Mugunthan V N (1):
drivers: net: cpsw: discard dual emac default vlan configuration
Nimrod Andy (1):
ARM: dts: imx6sx: correct i.MX6sx sdb board enet phy address
Sasha Levin (1):
net: llc: use correct size for sysctl timeout entries
Steffen Klassert (2):
xfrm6: Fix transport header offset in _decode_session6.
xfrm6: Fix the nexthdr offset in _decode_session6.
Thomas Richter (1):
390/qeth: Fix locking warning during qeth device setup
Viktor Babrian (1):
can: c_can: end pending transmission on network stop (ifdown)
Vivien Didelot (1):
net: dsa: set slave MII bus PHY mask
subashab@codeaurora.org (1):
ping: Fix race in free in receive path
arch/arm/boot/dts/imx6sx-sdb.dts | 8 +--
drivers/net/can/c_can/c_can.c | 3 +
drivers/net/can/usb/kvaser_usb.c | 28 ++++-----
drivers/net/ethernet/amd/xgbe/xgbe-common.h | 9 +--
drivers/net/ethernet/amd/xgbe/xgbe-dev.c | 4 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 2 +-
drivers/net/ethernet/cisco/enic/enic_main.c | 2 +-
drivers/net/ethernet/marvell/mv643xx_eth.c | 59 +++++++++++++++----
drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c | 5 +-
drivers/net/ethernet/renesas/sh_eth.c | 164 ++++++++++++++++++++++++++++++++++++-----------------
drivers/net/ethernet/renesas/sh_eth.h | 1 +
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 +-
drivers/net/ethernet/ti/cpsw.c | 22 ++++++++
drivers/net/ipvlan/ipvlan_core.c | 6 +-
drivers/net/wireless/ath/ath9k/main.c | 7 +--
drivers/net/wireless/iwlwifi/iwl-fw-file.h | 2 +
drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h | 7 ++-
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 20 +++----
drivers/net/wireless/iwlwifi/mvm/scan.c | 53 +++++++++++++----
drivers/net/wireless/iwlwifi/mvm/tx.c | 11 +++-
drivers/s390/net/qeth_core_main.c | 117 ++++++++++++++++++++++++++++++++------
drivers/s390/net/qeth_l2_main.c | 220 +++++++++++++++++++++++++++++++++++------------------------------------
drivers/s390/net/qeth_l3_main.c | 50 ++++++++++++----
include/net/ip.h | 11 ++--
kernel/bpf/syscall.c | 25 +++++---
net/dsa/slave.c | 1 +
net/ipv4/ip_forward.c | 3 +-
net/ipv4/ping.c | 5 +-
net/ipv4/route.c | 9 +--
net/ipv4/udp_diag.c | 4 +-
net/ipv6/ip6_fib.c | 45 ++++++++-------
net/ipv6/route.c | 6 +-
net/ipv6/xfrm6_policy.c | 10 +++-
net/llc/sysctl_net_llc.c | 8 +--
net/mac80211/pm.c | 29 +++++-----
net/mac80211/rx.c | 2 +-
net/sched/cls_bpf.c | 15 ++++-
net/sctp/associola.c | 1 -
net/socket.c | 3 -
net/wireless/nl80211.c | 9 ++-
net/wireless/util.c | 6 ++
samples/bpf/test_maps.c | 4 +-
42 files changed, 667 insertions(+), 334 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/2] rhashtable: Introduce rhashtable_walk_*
From: Herbert Xu @ 2015-01-27 20:36 UTC (permalink / raw)
To: Patrick McHardy
Cc: Thomas Graf, David Miller, David.Laight, ying.xue, paulmck,
netdev, netfilter-devel
In-Reply-To: <20150127130950.GA3950@acer.localdomain>
On Tue, Jan 27, 2015 at 01:09:50PM +0000, Patrick McHardy wrote:
>
> Actually I have a patchset queued that adds runtime additions and
> removals, both active and timeout based. So netfilter won't have
> pure synchronous behaviour anymore.
Can you show us the patchset?
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/2] rhashtable: Introduce rhashtable_walk_*
From: Herbert Xu @ 2015-01-27 20:39 UTC (permalink / raw)
To: Thomas Graf
Cc: David Miller, David.Laight, ying.xue, kaber, paulmck, netdev,
netfilter-devel
In-Reply-To: <20150127114028.GG22262@casper.infradead.org>
On Tue, Jan 27, 2015 at 11:40:28AM +0000, Thomas Graf wrote:
>
> This is unrelated to resize run control though, the reason is that
> I'm converting tcp_hashinfo et al and they require a hybrid approach.
> The tables may be too big to construct a parallel data structure, we
> don't want to hold off inserts or deletes while the expensive dump
> is underway. Even though we can't build a shadow structure while
> locking everybody else out, we still want to provide a way to somehow
> achieve consistent information. I think that NLM_F_INTR with fallback
> to restarting the dump is a good option and very easy to implement. In
> that case, we want to lock out resize from dumping iterations but
> still allow parallel insert/delete.
Well I guess Dave needs to make the call. Do we want to allow
lockless walks over the hash table or not?
Personally I don't think a linked list is that big a deal. But then
you guys were agonsing over a single pointer so who knows.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Does arping update arp table?
From: David Ahern @ 2015-01-27 20:46 UTC (permalink / raw)
To: Murali Karicheri, netdev; +Cc: David Miller
In-Reply-To: <54C7E5B5.8060401@ti.com>
On 1/27/15 12:23 PM, Murali Karicheri wrote:
> However this command doesn't update the arp table on my Keystone EVM
> based on v3.19.x and also newer ubuntu machine based on v3.11. Is this
> expected behavior? I believe the arp response resulting from a arping
> command is controlled through per interface accept sys control like as
> in gratuitous arp. Please repond.
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_accept
^ 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