netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH] net: core/dev: fix sparse warning
From: Lad, Prabhakar @ 2015-02-04 12:50 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David S. Miller, netdev, LKML, Eric Dumazet
In-Reply-To: <1423053695.907.117.camel@edumazet-glaptop2.roam.corp.google.com>

On Wed, Feb 4, 2015 at 12:41 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2015-02-04 at 12:25 +0000, Lad Prabhakar wrote:
>> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>>
>> this patch fixes following sparse warning:
>> net/core/dev.c: In function 'validate_xmit_skb_list':
>> net/core/dev.c:2720: warning: 'tail' may be used uninitialized in this function
>>
>> Although its a false positive, as head is assigned to NULL in the
>> beginning, due which later in the loop tail is assigned to skb->prev.
>>
>> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
>> ---
>>  net/core/dev.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 8ce0d1a..c736467 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -2717,7 +2717,7 @@ out_null:
>>
>>  struct sk_buff *validate_xmit_skb_list(struct sk_buff *skb, struct net_device *dev)
>>  {
>> -     struct sk_buff *next, *head = NULL, *tail;
>> +     struct sk_buff *next, *head = NULL, *tail = NULL;
>>
>>       for (; skb != NULL; skb = next) {
>>               next = skb->next;
>
> Which gcc/sparse versions are you using ?
>
I tried it on gcc 4.3.3 and sparse with 0.4.5-rc1 version.

Regards,
--Prabhakar Lad

^ permalink raw reply

* [PATCH 3/3] ethtool: Add support to get expansion ROM version in ethtool getdrvinfo
From: Hariprasad Shenai @ 2015-02-04 12:49 UTC (permalink / raw)
  To: netdev; +Cc: davem, ben, leedom, anish, nirranjan, kumaras, Hariprasad Shenai
In-Reply-To: <1423054176-26420-1-git-send-email-hariprasad@chelsio.com>

Rename the reserved1 field of ethtool_drvinfo to erom_version, and use it to get
the expansion ROM version of the adapter.

Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
 ethtool-copy.h |    3 ++-
 ethtool.c      |    2 ++
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/ethtool-copy.h b/ethtool-copy.h
index 61b78fc..e2df0e5 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -148,6 +148,7 @@ static __inline__ __u32 ethtool_cmd_speed(const struct ethtool_cmd *ep)
  *	not be an empty string.
  * @version: Driver version string; may be an empty string
  * @fw_version: Firmware version string; may be an empty string
+ * @erom_version: Expansion ROM version string; may be an empty string
  * @bus_info: Device bus address.  This should match the dev_name()
  *	string for the underlying bus device, if there is one.  May be
  *	an empty string.
@@ -176,7 +177,7 @@ struct ethtool_drvinfo {
 	char	version[32];
 	char	fw_version[ETHTOOL_FWVERS_LEN];
 	char	bus_info[ETHTOOL_BUSINFO_LEN];
-	char	reserved1[32];
+	char	erom_version[32];
 	char	reserved2[12];
 	__u32	n_priv_flags;
 	__u32	n_stats;
diff --git a/ethtool.c b/ethtool.c
index bf583f3..b7d2206 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -701,6 +701,7 @@ static int dump_drvinfo(struct ethtool_drvinfo *info)
 		"driver: %.*s\n"
 		"version: %.*s\n"
 		"firmware-version: %.*s\n"
+		"expansion-rom-version: %.*s\n"
 		"bus-info: %.*s\n"
 		"supports-statistics: %s\n"
 		"supports-test: %s\n"
@@ -710,6 +711,7 @@ static int dump_drvinfo(struct ethtool_drvinfo *info)
 		(int)sizeof(info->driver), info->driver,
 		(int)sizeof(info->version), info->version,
 		(int)sizeof(info->fw_version), info->fw_version,
+		(int)sizeof(info->erom_version), info->erom_version,
 		(int)sizeof(info->bus_info), info->bus_info,
 		info->n_stats ? "yes" : "no",
 		info->testinfo_len ? "yes" : "no",
-- 
1.7.1

^ permalink raw reply related

* [PATCH net-next 2/3] cxgb4: Add support in cxgb4 to get expansion rom version via ethtool
From: Hariprasad Shenai @ 2015-02-04 12:49 UTC (permalink / raw)
  To: netdev; +Cc: davem, ben, leedom, anish, nirranjan, kumaras, Hariprasad Shenai
In-Reply-To: <1423054176-26420-1-git-send-email-hariprasad@chelsio.com>

Add support to get option/expansion rom version flashed in the adapter via
ethtool getdrvinfo function.

Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h      |    1 +
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c |    9 +++++
 drivers/net/ethernet/chelsio/cxgb4/t4_hw.c      |   37 +++++++++++++++++++++++
 drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h   |    8 +++++
 4 files changed, 55 insertions(+), 0 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 55019c9..63231bf 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -1120,6 +1120,7 @@ int t4_fw_upgrade(struct adapter *adap, unsigned int mbox,
 unsigned int t4_flash_cfg_addr(struct adapter *adapter);
 int t4_get_fw_version(struct adapter *adapter, u32 *vers);
 int t4_get_tp_version(struct adapter *adapter, u32 *vers);
+int t4_get_exprom_version(struct adapter *adapter, u32 *vers);
 int t4_prep_fw(struct adapter *adap, struct fw_info *fw_info,
 	       const u8 *fw_data, unsigned int fw_size,
 	       struct fw_hdr *card_fw, enum dev_state state, int *reset);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 041742b..16639c7 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -1419,6 +1419,7 @@ static int get_eeprom_len(struct net_device *dev)
 static void get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
 {
 	struct adapter *adapter = netdev2adap(dev);
+	u32 exprom_vers;
 
 	strlcpy(info->driver, KBUILD_MODNAME, sizeof(info->driver));
 	strlcpy(info->version, DRV_VERSION, sizeof(info->version));
@@ -1436,6 +1437,14 @@ static void get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
 			FW_HDR_FW_VER_MINOR_G(adapter->params.tp_vers),
 			FW_HDR_FW_VER_MICRO_G(adapter->params.tp_vers),
 			FW_HDR_FW_VER_BUILD_G(adapter->params.tp_vers));
+
+	if (!t4_get_exprom_version(adapter, &exprom_vers))
+		snprintf(info->erom_version, sizeof(info->erom_version),
+			 "%u.%u.%u.%u",
+			 FW_HDR_FW_VER_MAJOR_G(exprom_vers),
+			 FW_HDR_FW_VER_MINOR_G(exprom_vers),
+			 FW_HDR_FW_VER_MICRO_G(exprom_vers),
+			 FW_HDR_FW_VER_BUILD_G(exprom_vers));
 }
 
 static void get_strings(struct net_device *dev, u32 stringset, u8 *data)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index ea16c62..ae69796 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -948,6 +948,43 @@ int t4_get_tp_version(struct adapter *adapter, u32 *vers)
 			     1, vers, 0);
 }
 
+/**
+ *	t4_get_exprom_version - return the Expansion ROM version (if any)
+ *	@adapter: the adapter
+ *	@vers: where to place the version
+ *
+ *	Reads the Expansion ROM header from FLASH and returns the version
+ *	number (if present) through the @vers return value pointer.  We return
+ *	this in the Firmware Version Format since it's convenient.  Return
+ *	0 on success, -ENOENT if no Expansion ROM is present.
+ */
+int t4_get_exprom_version(struct adapter *adap, u32 *vers)
+{
+	struct exprom_header {
+		unsigned char hdr_arr[16];	/* must start with 0x55aa */
+		unsigned char hdr_ver[4];	/* Expansion ROM version */
+	} *hdr;
+	u32 exprom_header_buf[DIV_ROUND_UP(sizeof(struct exprom_header),
+					   sizeof(u32))];
+	int ret;
+
+	ret = t4_read_flash(adap, FLASH_EXP_ROM_START,
+			    ARRAY_SIZE(exprom_header_buf), exprom_header_buf,
+			    0);
+	if (ret)
+		return ret;
+
+	hdr = (struct exprom_header *)exprom_header_buf;
+	if (hdr->hdr_arr[0] != 0x55 || hdr->hdr_arr[1] != 0xaa)
+		return -ENOENT;
+
+	*vers = (FW_HDR_FW_VER_MAJOR_V(hdr->hdr_ver[0]) |
+		 FW_HDR_FW_VER_MINOR_V(hdr->hdr_ver[1]) |
+		 FW_HDR_FW_VER_MICRO_V(hdr->hdr_ver[2]) |
+		 FW_HDR_FW_VER_BUILD_V(hdr->hdr_ver[3]));
+	return 0;
+}
+
 /* Is the given firmware API compatible with the one the driver was compiled
  * with?
  */
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
index 1e72cda..c009627 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
@@ -3012,21 +3012,29 @@ enum fw_hdr_chip {
 
 #define FW_HDR_FW_VER_MAJOR_S	24
 #define FW_HDR_FW_VER_MAJOR_M	0xff
+#define FW_HDR_FW_VER_MAJOR_V(x) \
+	((x) << FW_HDR_FW_VER_MAJOR_S)
 #define FW_HDR_FW_VER_MAJOR_G(x) \
 	(((x) >> FW_HDR_FW_VER_MAJOR_S) & FW_HDR_FW_VER_MAJOR_M)
 
 #define FW_HDR_FW_VER_MINOR_S	16
 #define FW_HDR_FW_VER_MINOR_M	0xff
+#define FW_HDR_FW_VER_MINOR_V(x) \
+	((x) << FW_HDR_FW_VER_MINOR_S)
 #define FW_HDR_FW_VER_MINOR_G(x) \
 	(((x) >> FW_HDR_FW_VER_MINOR_S) & FW_HDR_FW_VER_MINOR_M)
 
 #define FW_HDR_FW_VER_MICRO_S	8
 #define FW_HDR_FW_VER_MICRO_M	0xff
+#define FW_HDR_FW_VER_MICRO_V(x) \
+	((x) << FW_HDR_FW_VER_MICRO_S)
 #define FW_HDR_FW_VER_MICRO_G(x) \
 	(((x) >> FW_HDR_FW_VER_MICRO_S) & FW_HDR_FW_VER_MICRO_M)
 
 #define FW_HDR_FW_VER_BUILD_S	0
 #define FW_HDR_FW_VER_BUILD_M	0xff
+#define FW_HDR_FW_VER_BUILD_V(x) \
+	((x) << FW_HDR_FW_VER_BUILD_S)
 #define FW_HDR_FW_VER_BUILD_G(x) \
 	(((x) >> FW_HDR_FW_VER_BUILD_S) & FW_HDR_FW_VER_BUILD_M)
 
-- 
1.7.1

^ permalink raw reply related

* [PATCH net-next 1/3] ethtool: rename reserved1 memeber in ethtool_drvinfo for expansion ROM version
From: Hariprasad Shenai @ 2015-02-04 12:49 UTC (permalink / raw)
  To: netdev; +Cc: davem, ben, leedom, anish, nirranjan, kumaras, Hariprasad Shenai
In-Reply-To: <1423054176-26420-1-git-send-email-hariprasad@chelsio.com>

Renamed the reserved1 member of struct ethtool_drvinfo to erom_version to get
expansion/option ROM version of the adapter if present.

Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
 include/uapi/linux/ethtool.h |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 5f66d9c..bd80f0f 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -148,6 +148,7 @@ static inline __u32 ethtool_cmd_speed(const struct ethtool_cmd *ep)
  *	not be an empty string.
  * @version: Driver version string; may be an empty string
  * @fw_version: Firmware version string; may be an empty string
+ * @erom_version: Expansion ROM version string; may be an empty string
  * @bus_info: Device bus address.  This should match the dev_name()
  *	string for the underlying bus device, if there is one.  May be
  *	an empty string.
@@ -176,7 +177,7 @@ struct ethtool_drvinfo {
 	char	version[32];
 	char	fw_version[ETHTOOL_FWVERS_LEN];
 	char	bus_info[ETHTOOL_BUSINFO_LEN];
-	char	reserved1[32];
+	char	erom_version[32];
 	char	reserved2[12];
 	__u32	n_priv_flags;
 	__u32	n_stats;
-- 
1.7.1

^ permalink raw reply related

* [PATCH net-next 0/3] Add support in ethtool to get expansion ROM version
From: Hariprasad Shenai @ 2015-02-04 12:49 UTC (permalink / raw)
  To: netdev; +Cc: davem, ben, leedom, anish, nirranjan, kumaras, Hariprasad Shenai

Hi

This series adds support to get expansion ROM version via ethtool getdrvinfo.
PATCH 1/3 ("ethtool: rename reserved1 memeber in ethtool_drvinfo for expansion
    ROM version") is created against net-next tree. 
PATCH 2/3 ("cxgb4: Add support in cxgb4 to get expansion rom version via
ethtool") is created against net-next tree. 
PATCH 3/3 ("ethtool: Add support to get expansion ROM version in ethtool
getdrvinfo") is created against ethtool tree.

We have included all the maintainers of respective trees. Kindly review the
change and let us know in case of any review comments.

Thanks

Hariprasad Shenai (3):
  ethtool: rename reserved1 memeber in ethtool_drvinfo for expansion
    ROM version
  cxgb4: Add support in cxgb4 to get expansion rom version via ethtool
  ethtool: Add support to get expansion ROM version in ethtool getdrvinfo

 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h      |    1 +
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c |    9 +++++
 drivers/net/ethernet/chelsio/cxgb4/t4_hw.c      |   37 +++++++++++++++++++++++
 drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h   |    8 +++++
 include/uapi/linux/ethtool.h                    |    3 +-
 5 files changed, 57 insertions(+), 1 deletions(-)
---
 ethtool-copy.h |    3 ++-
 ethtool.c      |    2 ++
 2 files changed, 4 insertions(+), 1 deletions(-)

^ permalink raw reply

* Re: low vxlan throughput with tso enabled
From: Reiner Herrmann @ 2015-02-04 12:42 UTC (permalink / raw)
  To: Rick Jones, netdev; +Cc: svens, Vittorio Curcio
In-Reply-To: <54D0F8FF.1090204@hp.com>

On 02/03/2015 05:36 PM, Rick Jones wrote:
> I've been under the impression that one generally wants the MTU of a tunnel interface to be no more than the MTU of the physical interface over which it runs, less the 
> size of the encapsulation headers used by the tunnel.  What happens when you make the MTU of the tunnel interface 1400 bytes instead of 1500?
Lowering the MTU also brings throughput back to normal, but I'm interested in
why disabling TSO also seems to help (even with the same MTU).

^ permalink raw reply

* Re: [PATCH] net: core/dev: fix sparse warning
From: Eric Dumazet @ 2015-02-04 12:41 UTC (permalink / raw)
  To: Lad Prabhakar; +Cc: David S. Miller, netdev, linux-kernel, Eric Dumazet
In-Reply-To: <1423052746-3688-1-git-send-email-prabhakar.csengg@gmail.com>

On Wed, 2015-02-04 at 12:25 +0000, Lad Prabhakar wrote:
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
> 
> this patch fixes following sparse warning:
> net/core/dev.c: In function 'validate_xmit_skb_list':
> net/core/dev.c:2720: warning: 'tail' may be used uninitialized in this function
> 
> Although its a false positive, as head is assigned to NULL in the
> beginning, due which later in the loop tail is assigned to skb->prev.
> 
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> ---
>  net/core/dev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 8ce0d1a..c736467 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2717,7 +2717,7 @@ out_null:
>  
>  struct sk_buff *validate_xmit_skb_list(struct sk_buff *skb, struct net_device *dev)
>  {
> -	struct sk_buff *next, *head = NULL, *tail;
> +	struct sk_buff *next, *head = NULL, *tail = NULL;
>  
>  	for (; skb != NULL; skb = next) {
>  		next = skb->next;

Which gcc/sparse versions are you using ?

I do not see this warning here.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --disable-libmudflap --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) 

$ sparse --version
0.4.5-rc1
 

^ permalink raw reply

* Re: Throughput regression with `tcp: refine TSO autosizing`
From: Eric Dumazet @ 2015-02-04 12:38 UTC (permalink / raw)
  To: Michal Kazior; +Cc: linux-wireless, Network Development, eyalpe
In-Reply-To: <CA+BoTQ=BDcQ779uKCuX+f40=4npXVF4MTQnpjKimNYAxPsxBoQ@mail.gmail.com>

On Wed, 2015-02-04 at 13:22 +0100, Michal Kazior wrote:
> On 4 February 2015 at 12:57, Eric Dumazet <eric.dumazet@gmail.com> wrote:

> 
> > To disable gso you would have to use :
> >
> > ethtool -K wlan1 gso off
> 
> Oh, thanks! This works. However I can't turn it on:
> 
> ; ethtool -K wlan1 gso on
> Could not change any device features
> 
> ..so I guess it makes no sense to re-run tests because:
> 
> ; ethtool -k wlan1 | grep generic
>         tx-checksum-ip-generic: on [fixed]
> generic-segmentation-offload: off [requested on]
> generic-receive-offload: on
> 
> And this seems to never change.

GSO requires SG (Scatter Gather)

Are you sure this hardware has no SG support ?

^ permalink raw reply

* Re: low vxlan throughput with tso enabled
From: Reiner Herrmann @ 2015-02-04 12:34 UTC (permalink / raw)
  To: Tom Herbert; +Cc: Linux Netdev List, svens, Vittorio Curcio
In-Reply-To: <CA+mtBx-7Q1O8KMgmcoKnHurj7DP-4jugkKuqt3b=XaMga2-NEg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6220 bytes --]

On 02/03/2015 05:26 PM, Tom Herbert wrote:
> On Tue, Feb 3, 2015 at 7:50 AM, Reiner Herrmann
> <reiner.herrmann@sophos.com> wrote:
>> I have a vxlan tunnel established between two network interfaces, which
>> both have a MTU of 1500. The vxlan interfaces have the same MTU.
>> With TSO enabled, I observe low throughput with TCP connections (<100 kB/s).
>> Disabling TSO works around this issue and throughput is as expected.
>> Can someone please explain how TSO is influencing the tunnel to cause
>> such a difference?
> Please provide more information. What NIC? What is the link rate? What
> are you running to test. Also report 'ethtool -k' of both tunnel and
> Ethernet interfaces, and tcpdump on the interfaces (to see GSO
> packets).

Both are GBit NICs (it can be reproduced with different GBit NICs).
One has a link rate of 100 Mbps, the other 1000 Mbps.

To test the throughput, I'm using iperf (in TCP mode) between the two vxlan
interfaces.
I attached captures of the Ethernet interfaces from both devices, one with TSO
enabled on both vxlan interfaces (low throughput), and one with TSO disabled
on the vxlan interface of the iperf client (high throughput).

And below is the ethtool information you asked for.
Thank you for having a look.


Endpoint 1:
===========

Features for eth0:
rx-checksumming: on
tx-checksumming: on
     tx-checksum-ipv4: off [fixed]
     tx-checksum-ip-generic: on
     tx-checksum-ipv6: off [fixed]
     tx-checksum-fcoe-crc: off [fixed]
     tx-checksum-sctp: off [fixed]
scatter-gather: on
     tx-scatter-gather: on
     tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
     tx-tcp-segmentation: on
     tx-tcp-ecn-segmentation: off [fixed]
     tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]

Features for vxlan0:
rx-checksumming: on
tx-checksumming: on
     tx-checksum-ipv4: off [fixed]
     tx-checksum-ip-generic: on
     tx-checksum-ipv6: off [fixed]
     tx-checksum-fcoe-crc: off [fixed]
     tx-checksum-sctp: off [fixed]
scatter-gather: on
     tx-scatter-gather: on
     tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
     tx-tcp-segmentation: on
     tx-tcp-ecn-segmentation: on
     tx-tcp6-segmentation: on
udp-fragmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: on [fixed]
netns-local: on [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: on
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]


Endpoint 2:
===========

Features for eth0:
rx-checksumming: on
tx-checksumming: on
     tx-checksum-ipv4: off [fixed]
     tx-checksum-ip-generic: on
     tx-checksum-ipv6: off [fixed]
     tx-checksum-fcoe-crc: off [fixed]
     tx-checksum-sctp: off [fixed]
scatter-gather: on
     tx-scatter-gather: on
     tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
     tx-tcp-segmentation: on
     tx-tcp-ecn-segmentation: off [fixed]
     tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
busy-poll: off [fixed]

Features for vxlan0:
rx-checksumming: on
tx-checksumming: on
     tx-checksum-ipv4: off [fixed]
     tx-checksum-ip-generic: on
     tx-checksum-ipv6: off [fixed]
     tx-checksum-fcoe-crc: off [fixed]
     tx-checksum-sctp: off [fixed]
scatter-gather: on
     tx-scatter-gather: on
     tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
     tx-tcp-segmentation: on
     tx-tcp-ecn-segmentation: on
     tx-tcp6-segmentation: on
udp-fragmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: on [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: on
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
busy-poll: off [fixed]



[-- Attachment #2: device1_eth0_tso_off.pcap.xz --]
[-- Type: application/x-xz, Size: 338104 bytes --]

[-- Attachment #3: device1_eth0_tso_on.pcap.xz --]
[-- Type: application/x-xz, Size: 31604 bytes --]

[-- Attachment #4: device2_eth0_tso_off.pcap.xz --]
[-- Type: application/x-xz, Size: 334164 bytes --]

[-- Attachment #5: device2_eth0_tso_on.pcap.xz --]
[-- Type: application/x-xz, Size: 35744 bytes --]

^ permalink raw reply

* [PATCH] net: ethernet: ti/cpsw-common.c: fix sparse warning
From: Lad Prabhakar @ 2015-02-04 12:31 UTC (permalink / raw)
  To: David S. Miller, netdev; +Cc: linux-kernel, Tony Lindgren, Lad, Prabhakar

From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>

this patch fixes following sparse warning:

cpsw-common.c:23:5: warning: symbol 'cpsw_am33xx_cm_get_macid' was not declared. Should it be static?

Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
 drivers/net/ethernet/ti/cpsw-common.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/ti/cpsw-common.c b/drivers/net/ethernet/ti/cpsw-common.c
index 763ada1..f595094 100644
--- a/drivers/net/ethernet/ti/cpsw-common.c
+++ b/drivers/net/ethernet/ti/cpsw-common.c
@@ -17,6 +17,8 @@
 #include <linux/regmap.h>
 #include <linux/mfd/syscon.h>
 
+#include "cpsw.h"
+
 #define AM33XX_CTRL_MAC_LO_REG(offset, id) ((offset) + 0x8 * (id))
 #define AM33XX_CTRL_MAC_HI_REG(offset, id) ((offset) + 0x8 * (id) + 0x4)
 
-- 
1.9.1

^ permalink raw reply related

* [PATCH] net: core/dev: fix sparse warning
From: Lad Prabhakar @ 2015-02-04 12:25 UTC (permalink / raw)
  To: David S. Miller, netdev; +Cc: linux-kernel, Eric Dumazet, Lad, Prabhakar

From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>

this patch fixes following sparse warning:
net/core/dev.c: In function 'validate_xmit_skb_list':
net/core/dev.c:2720: warning: 'tail' may be used uninitialized in this function

Although its a false positive, as head is assigned to NULL in the
beginning, due which later in the loop tail is assigned to skb->prev.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
 net/core/dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 8ce0d1a..c736467 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2717,7 +2717,7 @@ out_null:
 
 struct sk_buff *validate_xmit_skb_list(struct sk_buff *skb, struct net_device *dev)
 {
-	struct sk_buff *next, *head = NULL, *tail;
+	struct sk_buff *next, *head = NULL, *tail = NULL;
 
 	for (; skb != NULL; skb = next) {
 		next = skb->next;
-- 
1.9.1

^ permalink raw reply related

* Re: Throughput regression with `tcp: refine TSO autosizing`
From: Michal Kazior @ 2015-02-04 12:22 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: linux-wireless, Network Development, eyalpe
In-Reply-To: <1423051045.907.108.camel@edumazet-glaptop2.roam.corp.google.com>

On 4 February 2015 at 12:57, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2015-02-04 at 12:35 +0100, Michal Kazior wrote:
>
>> > (Or maybe wifi drivers should start to use skb->xmit_more as a signal to end aggregation)
>>
>> This could work if your firmware/device supports this kind of thing.
>> To my understanding ath10k firmware doesn't.
>
> This is a pure software signal. You do not need firmware support.
>
> Idea is the following :
>
> Your driver gets a train of messages, coming from upper layers (TCP, IP,
> qdisc)
>
> It can know that a packet is not the last one, by looking at
> skb->xmit_more.
>
> Basically, aggregation logic could use this signal as a very clear
> indicator you got the end of a train -> force the xmit right now.

There's no way to tell ath10k firmware: "xmit right now". The firmware
does all tx aggregation logic by itself. Host driver just submits a
frame and hopes it'll get out soon. It's not even a tx-ring you'd
expect. Each frame has a host assigned id which firmware then uses in
tx completion.


> To disable gso you would have to use :
>
> ethtool -K wlan1 gso off

Oh, thanks! This works. However I can't turn it on:

; ethtool -K wlan1 gso on
Could not change any device features

..so I guess it makes no sense to re-run tests because:

; ethtool -k wlan1 | grep generic
        tx-checksum-ip-generic: on [fixed]
generic-segmentation-offload: off [requested on]
generic-receive-offload: on

And this seems to never change.


Michał

^ permalink raw reply

* [PATCH] netxen: Delete an unnecessary check before the function call "kfree"
From: SF Markus Elfring @ 2015-02-04 12:21 UTC (permalink / raw)
  To: Manish Chopra, Rajesh Borundia, Sony Chacko, netdev
  Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <5317A59D.4@users.sourceforge.net>

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 4 Feb 2015 13:17:48 +0100

The kfree() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
index a47fe67..7d1b524 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
@@ -176,9 +176,7 @@ netxen_alloc_sds_rings(struct netxen_recv_context *recv_ctx, int count)
 static void
 netxen_free_sds_rings(struct netxen_recv_context *recv_ctx)
 {
-	if (recv_ctx->sds_rings != NULL)
-		kfree(recv_ctx->sds_rings);
-
+	kfree(recv_ctx->sds_rings);
 	recv_ctx->sds_rings = NULL;
 }
 
-- 
2.2.2

^ permalink raw reply related

* Re: Invalid timestamp? causing tight ack loop (hundreds of thousands of packets / sec)
From: Eric Dumazet @ 2015-02-04 12:20 UTC (permalink / raw)
  To: Avery Fay; +Cc: netdev, Neal Cardwell
In-Reply-To: <CAO-X30shOhH7tN+msRvbLreeUvZesKARqyU0Lnm3_xoeea9uaQ@mail.gmail.com>

On Wed, 2015-02-04 at 00:35 -0800, Avery Fay wrote:
> Sure, https://dl.dropboxusercontent.com/u/9777748/loop.pcap.gz

Nice, something is really broken on this peer (not a linux one for
sure), or some really buggy middlebox.

The strange [P.] frame with no payload has a wrong sequence number
anyway, so we send back a duplicate ack.

  1   0.000000 128.61.57.205 -> 174.36.240.86 TCP 74 34574 > https [SYN] Seq=0 Win=65535 Len=0 MSS=1380 SACK_PERM=1 TSval=3985707 TSecr=0 WS=256
  2   0.000008 174.36.240.86 -> 128.61.57.205 TCP 74 https > 34574 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=3311875276 TSecr=3985707 WS=128
  3   0.019057 128.61.57.205 -> 174.36.240.86 TCP 66 34574 > https [ACK] Seq=1 Ack=1 Win=87808 Len=0 TSval=3985710 TSecr=3311875276
  4   0.019111 128.61.57.205 -> 174.36.240.86 TCP 66 [TCP Dup ACK 3#1] 34574 > https [ACK] Seq=1 Ack=1 Win=87808 Len=0 TSval=3985710 TSecr=3311875276
  5   0.037637 128.61.57.205 -> 174.36.240.86 SSL 292 Client Hello
  6   0.037644 174.36.240.86 -> 128.61.57.205 TCP 66 https > 34574 [ACK] Seq=1 Ack=227 Win=30080 Len=0 TSval=3311875285 TSecr=3985712
  7   0.037699 174.36.240.86 -> 128.61.57.205 TLSv1.2 2802 Server Hello
  8   0.037706 174.36.240.86 -> 128.61.57.205 TLSv1.2 585 Certificate
  9   0.074710 174.36.240.86 -> 128.61.57.205 TCP 585 [TCP Retransmission] https > 34574 [PSH, ACK] Seq=2737 Ack=227 Win=30080 Len=519 TSval=3311875295 TSecr=3985712[Reassembly error, protocol TCP: New fragment overlaps ol
d data (retransmission?)]
 10   0.294707 174.36.240.86 -> 128.61.57.205 TLSv1.2 1434 [TCP Retransmission] Server Hello
 11   0.734711 174.36.240.86 -> 128.61.57.205 TLSv1.2 1434 [TCP Retransmission] Server Hello
 12   1.614707 174.36.240.86 -> 128.61.57.205 TLSv1.2 1434 [TCP Retransmission] Server Hello
 13   3.378705 174.36.240.86 -> 128.61.57.205 TLSv1.2 1434 [TCP Retransmission] Server Hello
 14   6.910707 174.36.240.86 -> 128.61.57.205 TLSv1.2 1434 [TCP Retransmission] Server Hello
 15  10.097427 128.61.57.205 -> 174.36.240.86 TCP 66 34574 > https [FIN, ACK] Seq=227 Ack=1 Win=87808 Len=0 TSval=3986717 TSecr=3311875285
 16  10.097456 174.36.240.86 -> 128.61.57.205 TCP 66 https > 34574 [FIN, ACK] Seq=3256 Ack=228 Win=30080 Len=0 TSval=3311877800 TSecr=3986717
 17  10.111945 128.61.57.205 -> 174.36.240.86 TCP 78 [TCP Dup ACK 15#1] 34574 > https [PSH, ACK] Seq=228 Ack=1 Win=87808 Len=0 TSval=3985712 TSecr=3311875276 SLE=3256 SRE=3256
 18  10.111950 174.36.240.86 -> 128.61.57.205 TCP 66 [TCP Dup ACK 16#1] https > 34574 [ACK] Seq=3257 Ack=228 Win=30080 Len=0 TSval=3311877804 TSecr=3986717
 19  10.111952 128.61.57.205 -> 174.36.240.86 TCP 66 [TCP Dup ACK 15#2] 34574 > https [PSH, ACK] Seq=228 Ack=1 Win=87808 Len=0 TSval=3985712 TSecr=3311875276
 20  10.111955 174.36.240.86 -> 128.61.57.205 TCP 66 [TCP Dup ACK 16#2] https > 34574 [ACK] Seq=3257 Ack=228 Win=30080 Len=0 TSval=3311877804 TSecr=3986717
 21  10.126312 128.61.57.205 -> 174.36.240.86 TCP 86 [TCP Dup ACK 15#3] 34574 > https [PSH, ACK] Seq=228 Ack=1 Win=87808 Len=0 TSval=3985712 TSecr=3311875276 SLE=3257 SRE=3257 SLE=3256 SRE=3256
 22  10.126317 174.36.240.86 -> 128.61.57.205 TCP 66 [TCP Dup ACK 16#3] https > 34574 [ACK] Seq=3257 Ack=228 Win=30080 Len=0 TSval=3311877807 TSecr=3986717
 23  10.126360 128.61.57.205 -> 174.36.240.86 TCP 66 [TCP Dup ACK 15#4] 34574 > https [PSH, ACK] Seq=228 Ack=1 Win=87808 Len=0 TSval=3985712 TSecr=3311875276
 24  10.126362 174.36.240.86 -> 128.61.57.205 TCP 66 [TCP Dup ACK 16#4] https > 34574 [ACK] Seq=3257 Ack=228 Win=30080 Len=0 TSval=3311877807 TSecr=3986717
 25  10.126364 128.61.57.205 -> 174.36.240.86 TCP 66 [TCP Dup ACK 15#5] 34574 > https [PSH, ACK] Seq=228 Ack=1 Win=87808 Len=0 TSval=3985712 TSecr=3311875276
 26  10.126365 174.36.240.86 -> 128.61.57.205 TCP 66 [TCP Dup ACK 16#5] https > 34574 [ACK] Seq=3257 Ack=228 Win=30080 Len=0 TSval=3311877807 TSecr=3986717
 27  10.126366 128.61.57.205 -> 174.36.240.86 TCP 66 [TCP Dup ACK 15#6] 34574 > https [PSH, ACK] Seq=228 Ack=1 Win=87808 Len=0 TSval=3985712 TSecr=3311875276
 28  10.126367 174.36.240.86 -> 128.61.57.205 TCP 66 [TCP Dup ACK 16#6] https > 34574 [ACK] Seq=3257 Ack=228 Win=30080 Len=0 TSval=3311877807 TSecr=3986717
 29  10.140709 128.61.57.205 -> 174.36.240.86 TCP 66 [TCP Dup ACK 15#7] 34574 > https [PSH, ACK] Seq=228 Ack=1 Win=87808 Len=0 TSval=3985712 TSecr=3311875276
 30  10.140714 174.36.240.86 -> 128.61.57.205 TCP 66 [TCP Dup ACK 16#7] https > 34574 [ACK] Seq=3257 Ack=228 Win=30080 Len=0 TSval=3311877811 TSecr=3986717

Neal patches definitely would solve this issue.

^ permalink raw reply

* RE: [PATCH v2] net: bluetooth: hci_sock: Use 'const void *' instead of 'void *' for 2nd parameter of hci_test_bit()
From: David Laight @ 2015-02-04 12:13 UTC (permalink / raw)
  To: 'Chen Gang S', Joe Perches
  Cc: marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org,
	gustavo-THi1TnShQwVAfugRpC6u6w@public.gmane.org,
	johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	David S. Miller,
	linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <54D03996.1070503-/B7AUNIrSHOPt1CcHtbs0g@public.gmane.org>

From: Gang S
> On 2/3/15 10:32, Chen Gang S wrote:
> > On 2/3/15 05:20, Joe Perches wrote:
> >> On Tue, 2015-02-03 at 05:14 +0800, Chen Gang S wrote:
> >>> hci_test_bit() does not modify 2nd parameter, so it is better to let it
> >>> be constant, or may cause build warning. The related warning (with
> >>> allmodconfig under xtensa):
> >> []
> >>> diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
> >> []
> >>> @@ -46,7 +46,7 @@ struct hci_pinfo {
> >>>  	unsigned short    channel;
> >>>  };
> >>>
> >>> -static inline int hci_test_bit(int nr, void *addr)
> >>> +static inline int hci_test_bit(int nr, const void *addr)
> >>>  {
> >>>  	return *((__u32 *) addr + (nr >> 5)) & ((__u32) 1 << (nr & 31));
> >>>  }
> >>
> >> It's probably better to use const __u32 * here too, but the
> >> real thing I wonder is whether or not there's an issue with
> >> one of the 2 uses of this function.
> >>
> >> One of them passes a unsigned long *, the other a u32 *.
> >>
> >> $ git grep -w hci_test_bit
> >> net/bluetooth/hci_sock.c:static inline int hci_test_bit(int nr, void *addr)
> >> net/bluetooth/hci_sock.c:       if (!hci_test_bit(flt_event, &flt->event_mask))
> >> net/bluetooth/hci_sock.c:                    !hci_test_bit(ocf & HCI_FLT_OCF_BITS,
> >> net/bluetooth/hci_sock.c-                                  &hci_sec_filter.ocf_mask[ogf])) &&
> >>
> >> hci_sec_filter.ocf_mask is __u32
> >> but flt->event_mask is unsigned long.
> >>
> >> Any possible issue here on 64-bit systems?
> >>
> >
> > For me, it can not cause issue on 64-bit systems. hci_test_bit() treats
> > 'addr' as "__u32 *", and has to use the pointer to do something.
> >
> 
> 'event_mask' is intended to type cast to "__u32 *" within 'hci_sock.c'.
> So for me, "const __u32 *" is better than "const void *" for 2nd
> parameter of hci_test_bit().
> 
> If what I said above is correct, and also if necessary, I shall patch v3
> for it.

How are the bits set in the first place?
If the array is ever indexed as long [] then the code above is unlikely
to be testing the correct bits.

	David

^ permalink raw reply

* [PATCH] net: fec: Delete unnecessary checks before the function call "kfree"
From: SF Markus Elfring @ 2015-02-04 12:00 UTC (permalink / raw)
  To: netdev; +Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <5317A59D.4@users.sourceforge.net>

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 4 Feb 2015 12:56:42 +0100

The kfree() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/net/ethernet/freescale/fec_main.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 1c7a7e4..29fd7e3 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2584,12 +2584,9 @@ static void fec_enet_free_queue(struct net_device *ndev)
 		}
 
 	for (i = 0; i < fep->num_rx_queues; i++)
-		if (fep->rx_queue[i])
-			kfree(fep->rx_queue[i]);
-
+		kfree(fep->rx_queue[i]);
 	for (i = 0; i < fep->num_tx_queues; i++)
-		if (fep->tx_queue[i])
-			kfree(fep->tx_queue[i]);
+		kfree(fep->tx_queue[i]);
 }
 
 static int fec_enet_alloc_queue(struct net_device *ndev)
-- 
2.2.2

^ permalink raw reply related

* Re: [PATCH net-next] i40e: mark constant as ULL
From: Jeff Kirsher @ 2015-02-04 11:59 UTC (permalink / raw)
  To: Stefan Assmann; +Cc: netdev, davem, e1000-devel
In-Reply-To: <1423050064-25087-1-git-send-email-sassmann@kpanic.de>

[-- Attachment #1: Type: text/plain, Size: 325 bytes --]

On Wed, 2015-02-04 at 12:41 +0100, Stefan Assmann wrote:
> This avoids a compile error on 32bit.
> 
> Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
> ---
>  drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks Stefan, I will add your patch to my queue.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply

* RE: [PATCH v2] net: bluetooth: hci_sock: Use 'const void *' instead of 'void *' for 2nd parameter of hci_test_bit()
From: David Laight @ 2015-02-04 11:59 UTC (permalink / raw)
  To: 'Chen Gang S', marcel@holtmann.org, gustavo@padovan.org,
	johan.hedberg@gmail.com
  Cc: David S. Miller, linux-bluetooth@vger.kernel.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <54CFE8BE.5030700@sunrus.com.cn>

From: Chen Gang S
> -static inline int hci_test_bit(int nr, void *addr)
> +static inline int hci_test_bit(int nr, const void *addr)
>  {
>  	return *((__u32 *) addr + (nr >> 5)) & ((__u32) 1 << (nr & 31));
>  }

Is there a 'standard' function lurking that will do the above.
On x86 the cpus 'bit test' instruction will handle bit numbers
greater than the word size - so it can be a single instruction.

	David


^ permalink raw reply

* Re: Throughput regression with `tcp: refine TSO autosizing`
From: Eric Dumazet @ 2015-02-04 11:57 UTC (permalink / raw)
  To: Michal Kazior
  Cc: linux-wireless, Network Development,
	eyalpe-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb
In-Reply-To: <CA+BoTQmvUuFdfYF=wVMYxrf_nQZB5GCV=LvDZVvfs-3hAE4WKw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Wed, 2015-02-04 at 12:35 +0100, Michal Kazior wrote:

> > (Or maybe wifi drivers should start to use skb->xmit_more as a signal to end aggregation)
> 
> This could work if your firmware/device supports this kind of thing.
> To my understanding ath10k firmware doesn't.

This is a pure software signal. You do not need firmware support.

Idea is the following :

Your driver gets a train of messages, coming from upper layers (TCP, IP,
qdisc)

It can know that a packet is not the last one, by looking at
skb->xmit_more.

Basically, aggregation logic could use this signal as a very clear
indicator you got the end of a train -> force the xmit right now.

To disable gso you would have to use :

ethtool -K wlan1 gso off



--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: [PATCH v3 2/3] genetlink: disallow subscribing to unknown mcast groups
From: Bjørn Mork @ 2015-02-04 11:55 UTC (permalink / raw)
  To: Johannes Berg; +Cc: netdev, Jeff Layton, Sedat Dilek, Johannes Berg
In-Reply-To: <1421404634-8973-2-git-send-email-johannes@sipsolutions.net>

Johannes Berg <johannes@sipsolutions.net> writes:

> diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
> index 2e11061ef885..c18d3f5624b2 100644
> --- a/net/netlink/genetlink.c
> +++ b/net/netlink/genetlink.c
> @@ -985,7 +985,7 @@ static struct genl_multicast_group genl_ctrl_groups[] = {
>  
>  static int genl_bind(struct net *net, int group)
>  {
> -	int i, err = 0;
> +	int i, err = -ENOENT;
>  
>  	down_read(&cb_lock);
>  	for (i = 0; i < GENL_FAM_TAB_SIZE; i++) {

This change cause serious problems for acpid, as reported on
https://bugzilla.kernel.org/show_bug.cgi?id=92121

The end user visible result is that acpid fails to detect events like AC
power disconnect, battery alarms etc, which can be a bit of a problem if
you trust a battery alarm to trigger an emergency hibernation.  As I
happen to do...

Given the timing, I request that this patch is reverted for v3.19.
Thanks.

Sample acpid debug output, tracing the socket calls, running on a plain
v3.19-rc7:

nemi:/tmp# strace -s 128 -e trace=socket,bind,sendmsg,recvmsg -f acpid -l -d
socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3
Deprecated /proc/acpi/event was not found.  Trying netlink and the input layer...
input layer /dev/input/event0 (AT Translated Set 2 keyboard) opened successfully, fd 4
input layer /dev/input/event1 (Lid Switch) opened successfully, fd 5
input layer /dev/input/event10 (HDA Intel Dock Headphone) opened successfully, fd 6
input layer /dev/input/event11 (HDA Intel Headphone) opened successfully, fd 7
input layer /dev/input/event2 (Sleep Button) opened successfully, fd 8
input layer /dev/input/event3 (Power Button) opened successfully, fd 9
input layer /dev/input/event4 (ThinkPad Extra Buttons) opened successfully, fd 10
input layer /dev/input/event6 (Video Bus) opened successfully, fd 11
input layer /dev/input/event8 (HDA Intel Mic) opened successfully, fd 12
input layer /dev/input/event9 (HDA Intel Dock Mic) opened successfully, fd 13
inotify fd: 14
inotify wd: 1
socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_GENERIC) = 15
bind(15, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
sendmsg(15, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"$\0\0\0\20\0\5\0\21\10\322T\0\0\0\0\3\0\0\0\17\0\2\0acpi_event\0\0", 36}], msg_controllen=0, msg_flags=0}, 0) = 36
recvmsg(15, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"h\0\0\0\20\0\0\0\21\10\322T\314l\0\0\1\2\0\0\17\0\2\0acpi_event\0\0\6\0\1\0\23\0\0\0\10\0\3\0\1\0\0\0\10\0\4\0\0\0\0\0\10\0\5\0\1\0\0\0$\0\7\0 \0\1\0\10\0\2\0\2\0\0\0\22\0\1\0acpi_mc_group\0\0\0", 16384}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 104
socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_GENERIC) = 15
bind(15, {sa_family=AF_NETLINK, pid=0, groups=00000002}, 12) = -1 ENOENT (No such file or directory)
Cannot bind netlink socket: No such file or directory
acpid: cannot open generic netlink socket
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 16
bind(16, {sa_family=AF_LOCAL, sun_path="/var/run/acpid.socket"}, 110) = 0
acpid: starting up with netlink and the input layer
parsing conf file /etc/acpi/events/powerbtn-acpi-support
acpid: skipping non-file /etc/acpi/events/CVS
parsing conf file /etc/acpi/events/any
parsing conf file /etc/acpi/events/generic-hibernatebtn
parsing conf file /etc/acpi/events/low_battery
parsing conf file /etc/acpi/events/lidbtn
parsing conf file /etc/acpi/events/sleepbtn
acpid: 6 rules loaded
acpid: waiting for events: event logging is on



Bjørn

^ permalink raw reply

* Re: [PATCH net v4] net: ipv6: allow explicitly choosing optimistic addresses
From: Lorenzo Colitti @ 2015-02-04 11:53 UTC (permalink / raw)
  To: Erik Kline; +Cc: netdev@vger.kernel.org, Hannes Frederic Sowa
In-Reply-To: <1423047683-16267-1-git-send-email-ek@google.com>

On Wed, Feb 4, 2015 at 8:01 PM, Erik Kline <ek@google.com> wrote:
> +               /* Decouple optimistic from tentative for evaluation here.
> +                * Ban optimistic addresses explicitly, when required.
> +                */

I don't find this comment particularly useful, but I suppose there's
no harm in having it.

> +               ifp_flags = (ifp->flags&IFA_F_OPTIMISTIC)
> +                           ? (ifp->flags&~IFA_F_TENTATIVE)
> +                           : ifp->flags;
>                 if (ipv6_addr_equal(&ifp->addr, addr) &&
> -                   !(ifp->flags&IFA_F_TENTATIVE) &&
> +                   !(ifp_flags&banned_flags) &&
>                     (dev == NULL || ifp->idev->dev == dev ||

That looks correct now. It's also nicer than what I had proposed.

Adding the new ipv6_chk_addr_and_flags function is definitely less
churn than the alternative of updating all the callers of
ipv6_chk_addr (19 files) to pass in the extra argument. Not sure which
is preferred, the churn or the new function.

Acked-by: Lorenzo Colitti <lorenzo@google.com>

^ permalink raw reply

* [PATCH net-next] i40e: mark constant as ULL
From: Stefan Assmann @ 2015-02-04 11:41 UTC (permalink / raw)
  To: netdev; +Cc: davem, e1000-devel, jeffrey.t.kirsher, sassmann

This avoids a compile error on 32bit.

Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
---
 drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c b/drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c
index 4627588..f221ace 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c
@@ -908,7 +908,7 @@ static void i40e_write_qword(u8 *hmc_bits,
 	if (ce_info->width < 64)
 		mask = ((u64)1 << ce_info->width) - 1;
 	else
-		mask = 0xFFFFFFFFFFFFFFFF;
+		mask = 0xFFFFFFFFFFFFFFFFULL;
 
 	/* don't swizzle the bits until after the mask because the mask bits
 	 * will be in a different bit position on big endian machines
-- 
2.1.0

^ permalink raw reply related

* [PATCH] myri10ge: Delete an unnecessary check before the function call "kfree"
From: SF Markus Elfring @ 2015-02-04 11:36 UTC (permalink / raw)
  To: Hyong-Youb Kim, netdev; +Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <5317A59D.4@users.sourceforge.net>

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 4 Feb 2015 12:32:14 +0100

The kfree() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
index 71af98b..1412f5a 100644
--- a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
+++ b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
@@ -4226,8 +4226,7 @@ static void myri10ge_remove(struct pci_dev *pdev)
 		mtrr_del(mgp->mtrr, mgp->iomem_base, mgp->board_span);
 #endif
 	myri10ge_free_slices(mgp);
-	if (mgp->msix_vectors != NULL)
-		kfree(mgp->msix_vectors);
+	kfree(mgp->msix_vectors);
 	dma_free_coherent(&pdev->dev, sizeof(*mgp->cmd),
 			  mgp->cmd, mgp->cmd_bus);
 
-- 
2.2.2

^ permalink raw reply related

* Re: Throughput regression with `tcp: refine TSO autosizing`
From: Michal Kazior @ 2015-02-04 11:35 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: linux-wireless, Network Development, eyalpe
In-Reply-To: <1422973660.907.10.camel@edumazet-glaptop2.roam.corp.google.com>

On 3 February 2015 at 15:27, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2015-02-03 at 12:50 +0100, Michal Kazior wrote:
[...]
>> IOW:
>>  - stretch acks / TSO defer don't seem to help much (when compared to
>> throughput results from yesterday)
>>  - GRO helps
>>  - disabling A-MSDU on sender helps
>>  - net/master+GRO still doesn't reach the performance from before the
>> regression (~600mbps w/ GRO)
>>
>> You can grab logs and dumps here: http://www.filedropper.com/test2tar
>>
>
> Thanks for these traces.
>
> There is absolutely a problem at the sender, as we can see a big 2ms
> delay between reception of ACK and send of following packets.
> TCP stack should generate them immediately.
> Are you using some kind of netem qdisc ?

Both systems have identical setup:

; tc qdisc
qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap  1 2 2 2 1
2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth1 root refcnt 2 bands 3 priomap  1 2 2 2 1
2 0 0 1 1 1 1 1 1 1 1
qdisc mq 0: dev wlan1 root
qdisc pfifo_fast 0: dev wlan1 parent :1 bands 3 priomap  1 2 2 2 1 2 0
0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev wlan1 parent :2 bands 3 priomap  1 2 2 2 1 2 0
0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev wlan1 parent :3 bands 3 priomap  1 2 2 2 1 2 0
0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev wlan1 parent :4 bands 3 priomap  1 2 2 2 1 2 0
0 1 1 1 1 1 1 1 1


> These 2ms delays, in a flow with a 5ms RTT are terrible.
>
> 06:54:57.408391 IP 192.168.1.2.5001 > 192.168.1.3.51645: Flags [.], ack 4294899240, win 11268, options [nop,nop,TS val 1053302 ecr 1052250], length 0
> 06:54:57.408418 IP 192.168.1.2.5001 > 192.168.1.3.51645: Flags [.], ack 4294910824, win 11268, options [nop,nop,TS val 1053303 ecr 1052251], length 0
> 06:54:57.408431 IP 192.168.1.2.5001 > 192.168.1.3.51645: Flags [.], ack 4294936888, win 11268, options [nop,nop,TS val 1053303 ecr 1052251], length 0
> 06:54:57.408453 IP 192.168.1.2.5001 > 192.168.1.3.51645: Flags [.], ack 4294962952, win 11268, options [nop,nop,TS val 1053303 ecr 1052251], length 0
> 06:54:57.408474 IP 192.168.1.2.5001 > 192.168.1.3.51645: Flags [.], ack 0, win 11268, options [nop,nop,TS val 1053303 ecr 1052251], length 0
> <this 2ms delay is not generated by TCP stack.>
> 06:54:57.410243 IP 192.168.1.3.51645 > 192.168.1.2.5001: Flags [.], seq 82536:83984, ack 1, win 457, options [nop,nop,TS val 1052256 ecr 1053303], length 1448
[...]
>
> Are packets TX completed after a timer or something ?

As far as ath10k is concerned - no timers here. Not sure about
firmware itself though.


> Some very heavy stuff might run from tasklet (or other softirq triggered) event.
>
> BTW, traces tend to show that you 'receive' multiple ACK in the same burst,
> its not clear if they are delayed at one side or the other.
>
> GRO should delay only GRO candidates. ACK packets are not GRO candidates.
>
> Have you tried to disable GSO on sender ?

I assume I do that via ethtool? This is my current setup on both systems:

; ethtool -k wlan1
Features for wlan1:
rx-checksumming: off [fixed]
tx-checksumming: on
        tx-checksum-ipv4: off [fixed]
        tx-checksum-ip-generic: on [fixed]
        tx-checksum-ipv6: off [fixed]
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: off
        tx-scatter-gather: off [fixed]
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
        tx-tcp-segmentation: off [fixed]
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp6-segmentation: off [fixed]
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: off [requested on]
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: on [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
busy-poll: off [fixed]

; ethtool -K wlan1 generic-segmentation-offload off
ethtool: bad command line argument(s)
For more information run ethtool -h


> (Or maybe wifi drivers should start to use skb->xmit_more as a signal to end aggregation)

This could work if your firmware/device supports this kind of thing.
To my understanding ath10k firmware doesn't.


Michał

^ permalink raw reply

* [PATCH net 1/1] qlcnic: Fix NAPI poll routine for Tx completion
From: Shahed Shaikh @ 2015-02-04 10:41 UTC (permalink / raw)
  To: davem; +Cc: netdev, Dept-GELinuxNICDev, Shahed Shaikh

From: Shahed Shaikh <shahed.shaikh@qlogic.com>

After d75b1ade567f ("net: less interrupt masking in NAPI")
driver's NAPI poll routine is expected to return
exact budget value if it wants to be re-called.

Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Fixes: d75b1ade567f ("net: less interrupt masking in NAPI")
---
Hi Dave,

Please apply this patch to net

Thanks,
Shahed
---
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c |   27 +++++++++++++++++++++--
 1 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
index 18e5de7..4e1f58c 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
@@ -967,7 +967,12 @@ static int qlcnic_poll(struct napi_struct *napi, int budget)
 	tx_complete = qlcnic_process_cmd_ring(adapter, tx_ring,
 					      budget);
 	work_done = qlcnic_process_rcv_ring(sds_ring, budget);
-	if ((work_done < budget) && tx_complete) {
+
+	/* Check if we need a repoll */
+	if (!tx_complete)
+		work_done = budget;
+
+	if (work_done < budget) {
 		napi_complete(&sds_ring->napi);
 		if (test_bit(__QLCNIC_DEV_UP, &adapter->state)) {
 			qlcnic_enable_sds_intr(adapter, sds_ring);
@@ -992,6 +997,9 @@ static int qlcnic_tx_poll(struct napi_struct *napi, int budget)
 		napi_complete(&tx_ring->napi);
 		if (test_bit(__QLCNIC_DEV_UP, &adapter->state))
 			qlcnic_enable_tx_intr(adapter, tx_ring);
+	} else {
+		/* As qlcnic_process_cmd_ring() returned 0, we need a repoll*/
+		work_done = budget;
 	}
 
 	return work_done;
@@ -1950,7 +1958,12 @@ static int qlcnic_83xx_msix_sriov_vf_poll(struct napi_struct *napi, int budget)
 
 	tx_complete = qlcnic_process_cmd_ring(adapter, tx_ring, budget);
 	work_done = qlcnic_83xx_process_rcv_ring(sds_ring, budget);
-	if ((work_done < budget) && tx_complete) {
+
+	/* Check if we need a repoll */
+	if (!tx_complete)
+		work_done = budget;
+
+	if (work_done < budget) {
 		napi_complete(&sds_ring->napi);
 		qlcnic_enable_sds_intr(adapter, sds_ring);
 	}
@@ -1973,7 +1986,12 @@ static int qlcnic_83xx_poll(struct napi_struct *napi, int budget)
 
 	tx_complete = qlcnic_process_cmd_ring(adapter, tx_ring, budget);
 	work_done = qlcnic_83xx_process_rcv_ring(sds_ring, budget);
-	if ((work_done < budget) && tx_complete) {
+
+	/* Check if we need a repoll */
+	if (!tx_complete)
+		work_done = budget;
+
+	if (work_done < budget) {
 		napi_complete(&sds_ring->napi);
 		qlcnic_enable_sds_intr(adapter, sds_ring);
 	}
@@ -1995,6 +2013,9 @@ static int qlcnic_83xx_msix_tx_poll(struct napi_struct *napi, int budget)
 		napi_complete(&tx_ring->napi);
 		if (test_bit(__QLCNIC_DEV_UP , &adapter->state))
 			qlcnic_enable_tx_intr(adapter, tx_ring);
+	} else {
+		/* need a repoll */
+		work_done = budget;
 	}
 
 	return work_done;
-- 
1.7.1

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).