* [PATCH 0/5] net: hwmon fixes
From: Guenter Roeck @ 2013-11-23 6:07 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Jeff Kirsher, Jesse Brandeburg, Bruce Allan,
Carolyn Wyborny, Don Skidmore, Greg Rose, Nithin Nayak Sujir,
Michael Chan, e1000-devel, lm-sensors, Guenter Roeck
The hwmon subsystem is used by various network drivers to report temperature
sensor and other information. Unfortunately, its use is often not correct.
Typical errors are that the mandatory name sysfs attribute is not created,
that the temperature sensor index starts with 0 instead of 1, and/or that
sysfs attributes are created after the hwmon device was created.
The following sequence of patches fixes most of the problems.
The igb patches have been tested with real hardware; the others are compile
tested only.
^ permalink raw reply
* [PATCH 4/5] igb: Start temperature sensor attribute index with 1
From: Guenter Roeck @ 2013-11-23 6:08 UTC (permalink / raw)
To: netdev
Cc: Nithin Nayak Sujir, e1000-devel, Bruce Allan, Jesse Brandeburg,
lm-sensors, Michael Chan, David S. Miller, Guenter Roeck
In-Reply-To: <1385186881-7931-1-git-send-email-linux@roeck-us.net>
Per hwmon ABI, temperature sensor attribute index starts with 1, not 0.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
drivers/net/ethernet/intel/igb/igb_hwmon.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_hwmon.c b/drivers/net/ethernet/intel/igb/igb_hwmon.c
index 2e7ef2d..e0af5bc 100644
--- a/drivers/net/ethernet/intel/igb/igb_hwmon.c
+++ b/drivers/net/ethernet/intel/igb/igb_hwmon.c
@@ -124,22 +124,22 @@ static int igb_add_hwmon_attr(struct igb_adapter *adapter,
case IGB_HWMON_TYPE_LOC:
igb_attr->dev_attr.show = igb_hwmon_show_location;
snprintf(igb_attr->name, sizeof(igb_attr->name),
- "temp%u_label", offset);
+ "temp%u_label", offset + 1);
break;
case IGB_HWMON_TYPE_TEMP:
igb_attr->dev_attr.show = igb_hwmon_show_temp;
snprintf(igb_attr->name, sizeof(igb_attr->name),
- "temp%u_input", offset);
+ "temp%u_input", offset + 1);
break;
case IGB_HWMON_TYPE_CAUTION:
igb_attr->dev_attr.show = igb_hwmon_show_cautionthresh;
snprintf(igb_attr->name, sizeof(igb_attr->name),
- "temp%u_max", offset);
+ "temp%u_max", offset + 1);
break;
case IGB_HWMON_TYPE_MAX:
igb_attr->dev_attr.show = igb_hwmon_show_maxopthresh;
snprintf(igb_attr->name, sizeof(igb_attr->name),
- "temp%u_crit", offset);
+ "temp%u_crit", offset + 1);
break;
default:
rc = -EPERM;
--
1.7.9.7
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* Re: Fw: [Bug 65261] New: Packet loss or excessive packet delay repeatedly for some seconds
From: Hannes Frederic Sowa @ 2013-11-23 4:33 UTC (permalink / raw)
To: arno; +Cc: netdev, stephen
In-Reply-To: <20131120122316.77ce76c5@nehalam.linuxnetplumber.net>
On Wed, Nov 20, 2013 at 12:23:16PM -0800, Stephen Hemminger wrote:
>
>
> Begin forwarded message:
>
> Date: Wed, 20 Nov 2013 05:57:59 -0800
> From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
> To: "stephen@networkplumber.org" <stephen@networkplumber.org>
> Subject: [Bug 65261] New: Packet loss or excessive packet delay repeatedly for some seconds
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=65261
>
> Bug ID: 65261
> Summary: Packet loss or excessive packet delay repeatedly for
> some seconds
> Product: Networking
> Version: 2.5
> Kernel Version: 3.10.19
> Hardware: x86-64
> OS: Linux
> Tree: Mainline
> Status: NEW
> Severity: high
> Priority: P1
> Component: IPV4
> Assignee: shemminger@linux-foundation.org
> Reporter: arno@wagner.name
> Regression: No
>
> Created attachment 115261
> --> https://bugzilla.kernel.org/attachment.cgi?id=115261&action=edit
> Kernel config 3.10.19
>
> I recently upgraded my development-server/firewall/NAT-box from 3.10.17 to
> 3.10.19. Since then I noticed increased DNS lookup failures on a connected
> Windows box and occasional slow updates on putty-SSH logins when scrolling in
> an editor (joe, takes something like an estimated 100-300ms for screen
> updates). These update delays are repeatable for something like 10-20 seconds
> or more, e.g. inserting a line and then deleting again, then vanish. The delays
> make remote editing hard to do when they happen. The DNS lookup failures are
> really annoying.
>
> I have not found a way to reliably trigger the problem.
>
> Going back to 3.10.17 fixed the issue as far as I can tell. (Several hours
> editing source code without it showing up.) The only change between the two
> configurations was that I added the scsi CDROM driver (which should not be able
> to cause this?).
>
> The network connection has an iptables "all pass" on the server side for the
> affected connection. The client side is a Win7 machine. The network link is GbE
> with 2 Switches in there. No packet loss on ping/ping -f. Network hardware is
> Intel 82574L Gigabit card on both sides.
Could you try dropwatch while the packet drops are happening?
Often it is helpful to check ip monitor all if events happen during bursty
losses.
Greetings,
Hannes
^ permalink raw reply
* Re: dynamic TCP algorithms switching
From: yan cui @ 2013-11-23 3:56 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20131122155303.68da12ec@nehalam.linuxnetplumber.net>
Thanks for the quick reply!
Do you have the real-world workload results that demonstrate
that cubic has the best performance among all the available congestion
algorithms? If so, could you please post some?
Thanks, Yan
2013/11/22 Stephen Hemminger <stephen@networkplumber.org>:
> On Fri, 22 Nov 2013 18:21:12 -0500
> yan cui <ccuiyyan@gmail.com> wrote:
>
>> Then, why include so many (current Linux has 10+ TCP congestion algorithms)
>> algorithms? For users who want to deploy their application on Linux
>> and if the applications
>> are system resource intensive, they always want to tune the
>> configurations of the operating systems for the last piece of
>> performance. If they do so, maybe they are confused
>> about which TCP congestion algorithm to use for their environment. So,
>> the only way is to try each algorithm one by one. I understand the
>> setting of the default TCP congestion
>> algorithm to be Cubic means that it works well for most environments.
>> But if others
>> are seldom used, or can be replace with another implementation.
>> Why not just remove from the kernel?
>>
>> Yan
>
> Most are intended for research and testing only.
> Only a few are worth considering in a production environment.
> That is also why there so many qdisc algorithms as well.
>
--
Think big; Dream impossible; Make it happen.
^ permalink raw reply
* Earnestly Confidential
From: CARLOS FERNANDEZ @ 2013-11-23 3:35 UTC (permalink / raw)
Earnestly Confidential
I am Carlos Fernandez, a Banker and credit system programmer with Banco
Santander.
I saw your email address while browsing through the bank D.T.C Screen in
my office
yesterday so I decided to use this very chance to know you. I believe we
should use
every opportunity to know each other better. However, I am contacting you
for obvious reason
which you will understand.
I am sending this mail just to know if this email address is OK,
reply me back so that I will send more details to you.
I have a very important thing to discuss with you, I look forward to
receiving your response at
jscregoffice@postino.net . Have a pleasant day.
Carlos Fernandez
^ permalink raw reply
* Re: [Doubt on Implict BUGs caused LRO] doubt about lro status in v3.12 of torvalds/linux.git
From: Yanfei Wang @ 2013-11-23 3:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, China Kernel, linux-kernel
In-Reply-To: <1385137972.10637.86.camel@edumazet-glaptop2.roam.corp.google.com>
Hi Eric,
Thanks for quick reply. :-)
Also, I am confused that in v3.12 why inet_lro.c file is not found in
/net/ipv4/ directory, while Makefile has "obj-$(CONFIG_INET_LRO) +=
inet_lro.o" and LRO heads file exsits.
If I am wrong, pls correct me, :-)
See the steps 3 for details,(I have repeated it for several times)
----
3. cd net/ipv4,
[backyes@f14 ipv4]$ cat Makefile | grep lro
obj-$(CONFIG_INET_LRO) += inet_lro.o
[backyes@f14 ipv4]$ ls inet_*
inet_connection_sock.c inet_diag.c inet_fragment.c
inet_hashtables.c inet_timewait_sock.c
---
Best regards
Yanfei Wang
On Sat, Nov 23, 2013 at 12:32 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Fri, 2013-11-22 at 23:00 +0800, Yanfei Wang wrote:
>> Hi,
>>
>> Compared to the earlier kernel version, I found that Large receive
>> offload(LRO) is obsolete in latest kernel, and that is verified from
>> other materials about Generic receive offload(GRO).
>>
>> However, I also found some LRO header files and lro-related
>> functions referred by some drivers, and the lro-related function
>> definition is already removed at the same time!
>>
>> TEST steps:
>> 1. my git local db config as follow, url =
>> http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>> 2. git checkout v3.12 -b 3.12
>> 3. cd net/ipv4,
>> [backyes@f14 ipv4]$ cat Makefile | grep lro
>> obj-$(CONFIG_INET_LRO) += inet_lro.o
>> [backyes@f14 ipv4]$ ls inet_*
>> inet_connection_sock.c inet_diag.c inet_fragment.c
>> inet_hashtables.c inet_timewait_sock.c
>> [backyes@f14 ipv4]$
>> Here, Makefile has inet_lro.o config, while the inet_lro.c is removed.
>> 4. lro functions referred by some drivers, as follow,
>> [backyes@f14 linux]$ grep "inet_lro" * -r
>> drivers/net/ethernet/pasemi/pasemi_mac.c:#include <linux/inet_lro.h>
>> drivers/net/ethernet/pasemi/pasemi_mac_ethtool.c:#include <linux/inet_lro.h>
>> drivers/infiniband/hw/nes/nes_hw.c:#include <linux/inet_lro.h>
>> drivers/infiniband/hw/nes/nes_hw.h:#include <linux/inet_lro.h>
>> include/linux/inet_lro.h: * linux/include/linux/inet_lro.h
>> net/ipv4/Makefile:obj-$(CONFIG_INET_LRO) += inet_lro.o
>>
>> so, I understand that the removal of LRO is not clean, which will
>> cause compiler error for some kernel config.
>>
>
> I think you are slightly confused.
>
> LRO is not yet removed.
>
> Feel free to contribute ;)
>
> As long as at least one driver still uses LRO, we can not remove LRO.
>
> Converting a driver means testing the new driver, and owning the
> hardware.
>
>
>
^ permalink raw reply
* Re: gem csum breakage with 018c5bba (Handle CHECKSUM_COMPLETE more adequately ...)
From: Herbert Xu @ 2013-11-23 1:47 UTC (permalink / raw)
To: Alexander Graf
Cc: David Miller, alexander.h.duyck, netdev, edumazet, herbert,
linux-kernel@vger.kernel.org list, Ben Herrenschmidt
In-Reply-To: <B8BCE323-6F65-4D14-BD4A-BFA07C3ED290@suse.de>
On Fri, Nov 22, 2013 at 07:08:16PM +0100, Alexander Graf wrote:
> Hi,
>
> With current Linus' master tree my ibook started emitting a lot of annoying csum calculation warnings. I've bisected it down to the commit seen in the subject line, but I suppose the real problem lies somewhere a lot deeper and only gets revealed thanks to the more clever checksum logic applied now.
>
> Any ideas how to dig further into this?
Sorry, I don't have any docs on this device. Perhaps Dave has
the docs which can tell us what RXDCTRL_TCPCSUM actually returns?
I assume it returns the correct checksum ending at the IP
packet boundary and only goes wrong when extra padding exists.
Hmm, I suppose the question then is what exactly does it do
if the packet isn't an IP packet?
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 iproute2] htb: support 64bit rates
From: Stephen Hemminger @ 2013-11-23 1:36 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1384295647.28458.31.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, 12 Nov 2013 14:34:07 -0800
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Starting from linux-3.13, we can break the 32bit limitation of
> rates on HTB qdisc/classes.
>
> Prior limit was 34.359.738.360 bits per second.
>
> lpq83:~# tc -s qdisc show dev lo ; tc -s class show dev lo
> qdisc htb 1: root refcnt 2 r2q 2000 default 1 direct_packets_stat 0 direct_qlen 6000
> Sent 6591936144493 bytes 149549182 pkt (dropped 0, overlimits 213757419 requeues 0)
> rate 39464Mbit 114938pps backlog 0b 15p requeues 0
> class htb 1:1 root prio 0 rate 50000Mbit ceil 50000Mbit burst 200000b cburst 0b
> Sent 6591942184547 bytes 149549310 pkt (dropped 0, overlimits 0 requeues 0)
> rate 39464Mbit 114938pps backlog 0b 15p requeues 0
> lended: 149549310 borrowed: 0 giants: 0
> tokens: 336 ctokens: -164
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied to net-next-for-3.13 branch
^ permalink raw reply
* Re: [PATCH IPROUTE] ip: Add HSR support
From: Stephen Hemminger @ 2013-11-23 1:33 UTC (permalink / raw)
To: Arvid Brodin; +Cc: netdev@vger.kernel.org, Stephen Hemminger
In-Reply-To: <527D3CCC.3020609@xdin.com>
On Fri, 8 Nov 2013 20:34:36 +0100
Arvid Brodin <arvid.brodin@xdin.com> wrote:
> This patch adds basic support for High-Availability Seamless
> Redundancy (HSR) network devices.
>
> Signed-off-by: Arvid Brodin <arvid.brodin@xdin.com>
Will not apply to current iproute source. The header files have been updated
to be from current upstream (linus), and the IFLA_HSR doesn't match.
Please fix, and resubmit. Note, for iproute2 the header files are updated
perodically by using headers from kernel source (sanitized).
usr/include/linux/if_link.h
/* HSR section */
enum {
IFLA_HSR_UNSPEC,
IFLA_HSR_SLAVE1,
IFLA_HSR_SLAVE2,
IFLA_HSR_MULTICAST_SPEC,
__IFLA_HSR_MAX,
};
#define IFLA_HSR_MAX (__IFLA_HSR_MAX - 1)
^ permalink raw reply
* [ANNOUNCE] iproute2 3.12.0 release
From: Stephen Hemminger @ 2013-11-23 1:20 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
A little late but ready and toasty warm here is iproute2 to go with
3.12.0 (aka One Giant Leap for Frogkind).
In addition to the usual build documentation fixes, this
version includes support for ipv6 on vxlan and GRE.
As well as fair queue packet scheduler.
If you have been sitting on changes to iproute2 that are in
net-next for 3.12 merge window, please submit them now.
Iproute2 package is available at:
http://kernel.org/pub/linux/utils/net/iproute2/iproute2-3.12.0.tar.gz
You can download the source from:
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
Stay Warm!
---
Andreas Henriksson (1):
ss: avoid passing negative numbers to malloc
Christophe Gouault (1):
xfrm: enable to set non-wildcard mark 0 on SAs and SPs
Eric Dumazet (3):
pkt_sched: fq: Fair Queue packet scheduler
tc: support TCA_STATS_RATE_EST64
htb: add support for direct_qlen attribute
Fan Du (1):
xfrm: use memcpy to suppress gcc phony buffer overflow warning.
Hangbin Liu (1):
ipaddrlabel: use uint32_t instead of int32_t
Jamal Hadi Salim (2):
tc: introduce simple action
action: typo nat fix
Nicolas Dichtel (1):
iplink: update available type list
Nigel Kukard (1):
Fix tc stats when using -batch mode
Petr Písař (2):
iproute2: bridge: document mdb
iproute2: bridge: Close file with bridge monitor file
Sami Kerola (1):
ip: make -resolve addr to print names rather than addresses
Stefan Tomanek (1):
ip rule: add route suppression options
Stephen Hemminger (14):
Update kernel headers to net-next for 3.12
Update to 3.11 net-next kernel headers
nstat: add json output format
Update to 3.12-rc1 headers
nstat: revise json output
ifstat: add json output format
lnstat: add json output format
lnstat, nstat, ifstat: update man pages
tc: add default action to kernel headers
ipv6 gre: add entry to ether types
Fix handling of qdis without options
htb: remove old unused duplicate qdisc name
update kernel headers
v3.12.0
WANG Cong (1):
vxlan: add ipv6 support
xeb@mail.ru (2):
iproute2: GRE over IPv6 tunnel support.
iproute2: ip6gre: update man pages
^ permalink raw reply
* ??
From: seyed.jamaly @ 2013-11-23 0:47 UTC (permalink / raw)
To: Recipients
is it safe to discuss with you in this email?
^ permalink raw reply
* Re: dynamic TCP algorithms switching
From: Stephen Hemminger @ 2013-11-22 23:53 UTC (permalink / raw)
To: yan cui; +Cc: netdev, linux-net
In-Reply-To: <CAAVq3rnmWUAzDGy9_nMLsbx++opgZpuYtG34VpZEBbJ2psBnZw@mail.gmail.com>
On Fri, 22 Nov 2013 18:21:12 -0500
yan cui <ccuiyyan@gmail.com> wrote:
> Then, why include so many (current Linux has 10+ TCP congestion algorithms)
> algorithms? For users who want to deploy their application on Linux
> and if the applications
> are system resource intensive, they always want to tune the
> configurations of the operating systems for the last piece of
> performance. If they do so, maybe they are confused
> about which TCP congestion algorithm to use for their environment. So,
> the only way is to try each algorithm one by one. I understand the
> setting of the default TCP congestion
> algorithm to be Cubic means that it works well for most environments.
> But if others
> are seldom used, or can be replace with another implementation.
> Why not just remove from the kernel?
>
> Yan
Most are intended for research and testing only.
Only a few are worth considering in a production environment.
That is also why there so many qdisc algorithms as well.
^ permalink raw reply
* Re: [PATCH 2/5] net: MOXA ART: connect to PHY and add ethtool support
From: Ben Hutchings @ 2013-11-22 23:48 UTC (permalink / raw)
To: Jonas Jensen; +Cc: netdev, davem, linux-arm-kernel, linux-kernel
In-Reply-To: <1385132242-3204-2-git-send-email-jonas.jensen@gmail.com>
On Fri, 2013-11-22 at 15:57 +0100, Jonas Jensen wrote:
> The kernel now has a MDIO bus driver and a phy_driver (RTL8201CP),
> connect to this PHY using OF and add ethtool support.
>
> Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
> ---
>
> Notes:
> Applies to next-20131122
>
> drivers/net/ethernet/moxa/moxart_ether.c | 179 ++++++++++++++++++++++++++++++-
> drivers/net/ethernet/moxa/moxart_ether.h | 1 +
> 2 files changed, 179 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
> index 3c14afd..bcc6005 100644
> --- a/drivers/net/ethernet/moxa/moxart_ether.c
> +++ b/drivers/net/ethernet/moxa/moxart_ether.c
> @@ -26,9 +26,15 @@
> #include <linux/of_irq.h>
> #include <linux/crc32.h>
> #include <linux/crc32c.h>
> +#include <linux/phy.h>
> +#include <linux/of_mdio.h>
>
> #include "moxart_ether.h"
>
> +#define DRV_NAME "moxart-ethernet"
> +#define DRV_VERSION "0.2"
> +#define MOXART_NUM_STATS 16
MOXART_NUM_STATS should be defined as ARRAY_SIZE(ethtool_stats_keys).
[...]
> +static void moxart_get_drvinfo(struct net_device *ndev,
> + struct ethtool_drvinfo *info)
> +{
> + strlcpy(info->driver, DRV_NAME, sizeof(info->driver));
> + strlcpy(info->version, DRV_VERSION, sizeof(info->version));
> + strlcpy(info->bus_info, dev_name(&ndev->dev), sizeof(info->bus_info));
> + info->n_stats = MOXART_NUM_STATS;
[...]
Don't initialise n_stats here; the core will initialise it using your
get_sset_count implementation.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] inet: fix addr_len/msg->msg_namelen assignment in recv_error and rxpmtu functions
From: Hannes Frederic Sowa @ 2013-11-22 23:46 UTC (permalink / raw)
To: netdev; +Cc: spender, mpb.mail, davem, eric.dumazet
Commit bceaa90240b6019ed73b49965eac7d167610be69 ("inet: prevent leakage
of uninitialized memory to user in recv syscalls") conditionally updated
addr_len if the msg_name is written to. The recv_error and rxpmtu
functions relied on the recvmsg functions to set up addr_len before.
As this does not happen any more we have to pass addr_len to those
functions as well and set it to the size of the corresponding sockaddr
length.
This broke traceroute and such.
Fixes: bceaa90240b6 ("inet: prevent leakage of uninitialized memory to user in recv syscalls")
Reported-by: Brad Spengler <spender@grsecurity.net>
Reported-by: Tom Labanowski
Cc: mpb <mpb.mail@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
include/net/ip.h | 2 +-
include/net/ipv6.h | 6 ++++--
include/net/ping.h | 3 ++-
net/ipv4/ip_sockglue.c | 3 ++-
net/ipv4/ping.c | 5 +++--
net/ipv4/raw.c | 2 +-
net/ipv4/udp.c | 2 +-
net/ipv6/datagram.c | 7 +++++--
net/ipv6/ping.c | 3 ++-
net/ipv6/raw.c | 4 ++--
net/ipv6/udp.c | 4 ++--
net/l2tp/l2tp_ip6.c | 2 +-
12 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index 217bc5b..5a25f36 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -473,7 +473,7 @@ int compat_ip_getsockopt(struct sock *sk, int level, int optname,
int ip_ra_control(struct sock *sk, unsigned char on,
void (*destructor)(struct sock *));
-int ip_recv_error(struct sock *sk, struct msghdr *msg, int len);
+int ip_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len);
void ip_icmp_error(struct sock *sk, struct sk_buff *skb, int err, __be16 port,
u32 info, u8 *payload);
void ip_local_error(struct sock *sk, int err, __be32 daddr, __be16 dport,
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 2a5f668..eb198ac 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -776,8 +776,10 @@ int compat_ipv6_getsockopt(struct sock *sk, int level, int optname,
int ip6_datagram_connect(struct sock *sk, struct sockaddr *addr, int addr_len);
-int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len);
-int ipv6_recv_rxpmtu(struct sock *sk, struct msghdr *msg, int len);
+int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len,
+ int *addr_len);
+int ipv6_recv_rxpmtu(struct sock *sk, struct msghdr *msg, int len,
+ int *addr_len);
void ipv6_icmp_error(struct sock *sk, struct sk_buff *skb, int err, __be16 port,
u32 info, u8 *payload);
void ipv6_local_error(struct sock *sk, int err, struct flowi6 *fl6, u32 info);
diff --git a/include/net/ping.h b/include/net/ping.h
index 3f67704..90f4841 100644
--- a/include/net/ping.h
+++ b/include/net/ping.h
@@ -31,7 +31,8 @@
/* Compatibility glue so we can support IPv6 when it's compiled as a module */
struct pingv6_ops {
- int (*ipv6_recv_error)(struct sock *sk, struct msghdr *msg, int len);
+ int (*ipv6_recv_error)(struct sock *sk, struct msghdr *msg, int len,
+ int *addr_len);
int (*ip6_datagram_recv_ctl)(struct sock *sk, struct msghdr *msg,
struct sk_buff *skb);
int (*icmpv6_err_convert)(u8 type, u8 code, int *err);
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 3f85826..ddf32a6 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -386,7 +386,7 @@ void ip_local_error(struct sock *sk, int err, __be32 daddr, __be16 port, u32 inf
/*
* Handle MSG_ERRQUEUE
*/
-int ip_recv_error(struct sock *sk, struct msghdr *msg, int len)
+int ip_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
{
struct sock_exterr_skb *serr;
struct sk_buff *skb, *skb2;
@@ -423,6 +423,7 @@ int ip_recv_error(struct sock *sk, struct msghdr *msg, int len)
serr->addr_offset);
sin->sin_port = serr->port;
memset(&sin->sin_zero, 0, sizeof(sin->sin_zero));
+ *addr_len = sizeof(*sin);
}
memcpy(&errhdr.ee, &serr->ee, sizeof(struct sock_extended_err));
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index 876c6ca..840cf1b 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -841,10 +841,11 @@ int ping_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
if (flags & MSG_ERRQUEUE) {
if (family == AF_INET) {
- return ip_recv_error(sk, msg, len);
+ return ip_recv_error(sk, msg, len, addr_len);
#if IS_ENABLED(CONFIG_IPV6)
} else if (family == AF_INET6) {
- return pingv6_ops.ipv6_recv_error(sk, msg, len);
+ return pingv6_ops.ipv6_recv_error(sk, msg, len,
+ addr_len);
#endif
}
}
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 5cb8ddb..23c3e5b 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -697,7 +697,7 @@ static int raw_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
goto out;
if (flags & MSG_ERRQUEUE) {
- err = ip_recv_error(sk, msg, len);
+ err = ip_recv_error(sk, msg, len, addr_len);
goto out;
}
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 5944d7d..44dfaa0 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1236,7 +1236,7 @@ int udp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
bool slow;
if (flags & MSG_ERRQUEUE)
- return ip_recv_error(sk, msg, len);
+ return ip_recv_error(sk, msg, len, addr_len);
try_again:
skb = __skb_recv_datagram(sk, flags | (noblock ? MSG_DONTWAIT : 0),
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index a454b0f..d690204 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -318,7 +318,7 @@ void ipv6_local_rxpmtu(struct sock *sk, struct flowi6 *fl6, u32 mtu)
/*
* Handle MSG_ERRQUEUE
*/
-int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len)
+int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
{
struct ipv6_pinfo *np = inet6_sk(sk);
struct sock_exterr_skb *serr;
@@ -369,6 +369,7 @@ int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len)
&sin->sin6_addr);
sin->sin6_scope_id = 0;
}
+ *addr_len = sizeof(*sin);
}
memcpy(&errhdr.ee, &serr->ee, sizeof(struct sock_extended_err));
@@ -423,7 +424,8 @@ EXPORT_SYMBOL_GPL(ipv6_recv_error);
/*
* Handle IPV6_RECVPATHMTU
*/
-int ipv6_recv_rxpmtu(struct sock *sk, struct msghdr *msg, int len)
+int ipv6_recv_rxpmtu(struct sock *sk, struct msghdr *msg, int len,
+ int *addr_len)
{
struct ipv6_pinfo *np = inet6_sk(sk);
struct sk_buff *skb;
@@ -457,6 +459,7 @@ int ipv6_recv_rxpmtu(struct sock *sk, struct msghdr *msg, int len)
sin->sin6_port = 0;
sin->sin6_scope_id = mtu_info.ip6m_addr.sin6_scope_id;
sin->sin6_addr = mtu_info.ip6m_addr.sin6_addr;
+ *addr_len = sizeof(*sin);
}
put_cmsg(msg, SOL_IPV6, IPV6_PATHMTU, sizeof(mtu_info), &mtu_info);
diff --git a/net/ipv6/ping.c b/net/ipv6/ping.c
index 8815e31..a83243c 100644
--- a/net/ipv6/ping.c
+++ b/net/ipv6/ping.c
@@ -57,7 +57,8 @@ static struct inet_protosw pingv6_protosw = {
/* Compatibility glue so we can support IPv6 when it's compiled as a module */
-static int dummy_ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len)
+static int dummy_ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len,
+ int *addr_len)
{
return -EAFNOSUPPORT;
}
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index e24ff1d..7fb4e14 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -466,10 +466,10 @@ static int rawv6_recvmsg(struct kiocb *iocb, struct sock *sk,
return -EOPNOTSUPP;
if (flags & MSG_ERRQUEUE)
- return ipv6_recv_error(sk, msg, len);
+ return ipv6_recv_error(sk, msg, len, addr_len);
if (np->rxpmtu && np->rxopt.bits.rxpmtu)
- return ipv6_recv_rxpmtu(sk, msg, len);
+ return ipv6_recv_rxpmtu(sk, msg, len, addr_len);
skb = skb_recv_datagram(sk, flags, noblock, &err);
if (!skb)
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 81eb8cf..bcd5699 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -393,10 +393,10 @@ int udpv6_recvmsg(struct kiocb *iocb, struct sock *sk,
bool slow;
if (flags & MSG_ERRQUEUE)
- return ipv6_recv_error(sk, msg, len);
+ return ipv6_recv_error(sk, msg, len, addr_len);
if (np->rxpmtu && np->rxopt.bits.rxpmtu)
- return ipv6_recv_rxpmtu(sk, msg, len);
+ return ipv6_recv_rxpmtu(sk, msg, len, addr_len);
try_again:
skb = __skb_recv_datagram(sk, flags | (noblock ? MSG_DONTWAIT : 0),
diff --git a/net/l2tp/l2tp_ip6.c b/net/l2tp/l2tp_ip6.c
index cfd6530..d9b437e 100644
--- a/net/l2tp/l2tp_ip6.c
+++ b/net/l2tp/l2tp_ip6.c
@@ -665,7 +665,7 @@ static int l2tp_ip6_recvmsg(struct kiocb *iocb, struct sock *sk,
*addr_len = sizeof(*lsa);
if (flags & MSG_ERRQUEUE)
- return ipv6_recv_error(sk, msg, len);
+ return ipv6_recv_error(sk, msg, len, addr_len);
skb = skb_recv_datagram(sk, flags, noblock, &err);
if (!skb)
--
1.8.3.1
^ permalink raw reply related
* Re: dynamic TCP algorithms switching
From: yan cui @ 2013-11-22 23:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, linux-net
In-Reply-To: <20131122145621.344fa999@nehalam.linuxnetplumber.net>
Then, why include so many (current Linux has 10+ TCP congestion algorithms)
algorithms? For users who want to deploy their application on Linux
and if the applications
are system resource intensive, they always want to tune the
configurations of the operating systems for the last piece of
performance. If they do so, maybe they are confused
about which TCP congestion algorithm to use for their environment. So,
the only way is to try each algorithm one by one. I understand the
setting of the default TCP congestion
algorithm to be Cubic means that it works well for most environments.
But if others
are seldom used, or can be replace with another implementation.
Why not just remove from the kernel?
Yan
2013/11/22 Stephen Hemminger <stephen@networkplumber.org>:
> On Fri, 22 Nov 2013 17:49:58 -0500
> yan cui <ccuiyyan@gmail.com> wrote:
>
>> Hi all:
>>
>> Currently, Linux has kinds of TCP congestion algorithms, such as
>> reno, cubic, bic, hybla, ...., and each TCP congestion algorithm has
>> its target networking environment. I just wonder to know is it
>> possible to do dynamic TCP algorithm switching? In other words, the
>> system has a combined TCP congestion algorithm (say, TCP-auto), and it
>> behaves like one of the integrated TCP congestion algorithms according
>> to different detected networking environment, but can switch to a
>> different one. For example, TCP-auto totally uses the set of
>> congestion control operations in TCP-cubic by default, but when it
>> detects that the current OS uses wireless networking, it switches to
>> some wireless friendly TCP congestion algorithm. Does Linux have some
>> features like that, or do you (networking developers and users) care
>> about it?
>>
>> Best Wishes!
>>
>
> You overestimate the advantage of one verus the other.
> It is possible to control algorithm on per-socket, and per-route
> but other than benchmarking there or bulk transfer for normal net
> traffic Cubic works fine for all environments.
--
Think big; Dream impossible; Make it happen.
^ permalink raw reply
* Re: [PATCH 2/2] e1000: fix possible reset_task running after adapter down
From: Jeff Kirsher @ 2013-11-22 23:14 UTC (permalink / raw)
To: Vladimir Davydov
Cc: Jesse Brandeburg, e1000-devel, netdev, linux-kernel, devel,
Tushar Dave, Patrick McHardy, David S. Miller
In-Reply-To: <a0339f72560eeee5cad54c9363a5b5f196b83933.1385107870.git.vdavydov@parallels.com>
[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]
On Fri, 2013-11-22 at 12:20 +0400, Vladimir Davydov wrote:
> On e1000_down(), we should ensure every asynchronous work is canceled
> before proceeding. Since the watchdog_task can schedule other works
> apart from itself, it should be stopped first, but currently it is
> stopped after the reset_task. This can result in the following race
> leading to the reset_task running after the module unload:
>
> e1000_down_and_stop(): e1000_watchdog():
> ---------------------- -----------------
>
> cancel_work_sync(reset_task)
> schedule_work(reset_task)
> cancel_delayed_work_sync(watchdog_task)
>
> The patch moves cancel_delayed_work_sync(watchdog_task) at the
> beginning
> of e1000_down_and_stop() thus ensuring the race is impossible.
>
> Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
> Cc: Tushar Dave <tushar.n.dave@intel.com>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: David S. Miller <davem@davemloft.net>
> ---
> drivers/net/ethernet/intel/e1000/e1000_main.c | 15 +++++++++++----
> 1 file changed, 11 insertions(+), 4 deletions(-)
I have applied your patch to my queue, thanks!
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] e1000: fix lockdep warning in e1000_reset_task
From: Jeff Kirsher @ 2013-11-22 23:13 UTC (permalink / raw)
To: Vladimir Davydov
Cc: Jesse Brandeburg, e1000-devel, netdev, linux-kernel, devel,
Tushar Dave, Patrick McHardy, David S. Miller
In-Reply-To: <0555e8c422c9d920758399edfa08f72df9120713.1385107870.git.vdavydov@parallels.com>
[-- Attachment #1: Type: text/plain, Size: 7338 bytes --]
On Fri, 2013-11-22 at 12:20 +0400, Vladimir Davydov wrote:
> The patch fixes the following lockdep warning, which is 100%
> reproducible on network restart:
>
> ======================================================
> [ INFO: possible circular locking dependency detected ]
> 3.12.0+ #47 Tainted: GF
> -------------------------------------------------------
> kworker/1:1/27 is trying to acquire lock:
> ((&(&adapter->watchdog_task)->work)){+.+...}, at:
> [<ffffffff8108a5b0>] flush_work+0x0/0x70
>
> but task is already holding lock:
> (&adapter->mutex){+.+...}, at: [<ffffffffa0177c0a>] e1000_reset_task
> +0x4a/0xa0 [e1000]
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (&adapter->mutex){+.+...}:
> [<ffffffff810bdb5d>] lock_acquire+0x9d/0x120
> [<ffffffff816b8cbc>] mutex_lock_nested+0x4c/0x390
> [<ffffffffa017233d>] e1000_watchdog+0x7d/0x5b0 [e1000]
> [<ffffffff8108b972>] process_one_work+0x1d2/0x510
> [<ffffffff8108ca80>] worker_thread+0x120/0x3a0
> [<ffffffff81092c1e>] kthread+0xee/0x110
> [<ffffffff816c3d7c>] ret_from_fork+0x7c/0xb0
>
> -> #0 ((&(&adapter->watchdog_task)->work)){+.+...}:
> [<ffffffff810bd9c0>] __lock_acquire+0x1710/0x1810
> [<ffffffff810bdb5d>] lock_acquire+0x9d/0x120
> [<ffffffff8108a5eb>] flush_work+0x3b/0x70
> [<ffffffff8108b5d8>] __cancel_work_timer+0x98/0x140
> [<ffffffff8108b693>] cancel_delayed_work_sync+0x13/0x20
> [<ffffffffa0170cec>] e1000_down_and_stop+0x3c/0x60 [e1000]
> [<ffffffffa01775b1>] e1000_down+0x131/0x220 [e1000]
> [<ffffffffa0177c12>] e1000_reset_task+0x52/0xa0 [e1000]
> [<ffffffff8108b972>] process_one_work+0x1d2/0x510
> [<ffffffff8108ca80>] worker_thread+0x120/0x3a0
> [<ffffffff81092c1e>] kthread+0xee/0x110
> [<ffffffff816c3d7c>] ret_from_fork+0x7c/0xb0
>
> other info that might help us debug this:
>
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(&adapter->mutex);
>
> lock((&(&adapter->watchdog_task)->work));
> lock(&adapter->mutex);
> lock((&(&adapter->watchdog_task)->work));
>
> *** DEADLOCK ***
>
> 3 locks held by kworker/1:1/27:
> #0: (events){.+.+.+}, at: [<ffffffff8108b906>] process_one_work
> +0x166/0x510
> #1: ((&adapter->reset_task)){+.+...}, at: [<ffffffff8108b906>]
> process_one_work+0x166/0x510
> #2: (&adapter->mutex){+.+...}, at: [<ffffffffa0177c0a>]
> e1000_reset_task+0x4a/0xa0 [e1000]
>
> stack backtrace:
> CPU: 1 PID: 27 Comm: kworker/1:1 Tainted: GF 3.12.0+ #47
> Hardware name: System manufacturer System Product Name/P5B-VM SE, BIOS
> 0501 05/31/2007
> Workqueue: events e1000_reset_task [e1000]
> ffffffff820f6000 ffff88007b9dba98 ffffffff816b54a2 0000000000000002
> ffffffff820f5e50 ffff88007b9dbae8 ffffffff810ba936 ffff88007b9dbac8
> ffff88007b9dbb48 ffff88007b9d8f00 ffff88007b9d8780 ffff88007b9d8f00
> Call Trace:
> [<ffffffff816b54a2>] dump_stack+0x49/0x5f
> [<ffffffff810ba936>] print_circular_bug+0x216/0x310
> [<ffffffff810bd9c0>] __lock_acquire+0x1710/0x1810
> [<ffffffff8108a5b0>] ? __flush_work+0x250/0x250
> [<ffffffff810bdb5d>] lock_acquire+0x9d/0x120
> [<ffffffff8108a5b0>] ? __flush_work+0x250/0x250
> [<ffffffff8108a5eb>] flush_work+0x3b/0x70
> [<ffffffff8108a5b0>] ? __flush_work+0x250/0x250
> [<ffffffff8108b5d8>] __cancel_work_timer+0x98/0x140
> [<ffffffff8108b693>] cancel_delayed_work_sync+0x13/0x20
> [<ffffffffa0170cec>] e1000_down_and_stop+0x3c/0x60 [e1000]
> [<ffffffffa01775b1>] e1000_down+0x131/0x220 [e1000]
> [<ffffffffa0177c12>] e1000_reset_task+0x52/0xa0 [e1000]
> [<ffffffff8108b972>] process_one_work+0x1d2/0x510
> [<ffffffff8108b906>] ? process_one_work+0x166/0x510
> [<ffffffff8108ca80>] worker_thread+0x120/0x3a0
> [<ffffffff8108c960>] ? manage_workers+0x2c0/0x2c0
> [<ffffffff81092c1e>] kthread+0xee/0x110
> [<ffffffff81092b30>] ? __init_kthread_worker+0x70/0x70
> [<ffffffff816c3d7c>] ret_from_fork+0x7c/0xb0
> [<ffffffff81092b30>] ? __init_kthread_worker+0x70/0x70
>
> == The issue background ==
>
> The problem occurs, because e1000_down(), which is called under
> adapter->mutex by e1000_reset_task(), tries to synchronously cancel
> e1000 auxiliary works (reset_task, watchdog_task, phy_info_task,
> fifo_stall_task), which take adapter->mutex in their handlers. So the
> question is what does adapter->mutex protect there?
>
> The adapter->mutex was introduced by commit 0ef4ee ("e1000: convert to
> private mutex from rtnl") as a replacement for rtnl_lock() taken in
> the
> asynchronous handlers. It targeted on fixing a similar lockdep warning
> issued when e1000_down() was called under rtnl_lock(), and it fixed
> it,
> but unfortunately it introduced the lockdep warning described above.
> Anyway, that said the source of this bug is that the asynchronous
> works
> were made to take rtnl_lock() some time ago, so let's look deeper and
> find why it was added there.
>
> The rtnl_lock() was added to asynchronous handlers by commit 338c15
> ("e1000: fix occasional panic on unload") in order to prevent
> asynchronous handlers from execution after the module is unloaded
> (e1000_down() is called) as it follows from the comment to the commit:
>
> > Net drivers in general have an issue where timers fired
> > by mod_timer or work threads with schedule_work are running
> > outside of the rtnl_lock.
> >
> > With no other lock protection these routines are vulnerable
> > to races with driver unload or reset paths.
> >
> > The longer term solution to this might be a redesign with
> > safer locks being taken in the driver to guarantee no
> > reentrance, but for now a safe and effective fix is
> > to take the rtnl_lock in these routines.
>
> I'm not sure if this locking scheme fixed the problem or just made it
> unlikely, although I incline to the latter. Anyway, this was long time
> ago when e1000 auxiliary works were implemented as timers scheduling
> real work handlers in their routines. The e1000_down() function only
> canceled the timers, but left the real handlers running if they were
> running, which could result in work execution after module unload.
> Today, the e1000 driver uses sane delayed works instead of the pair
> timer+work to implement its delayed asynchronous handlers, and the
> e1000_down() synchronously cancels all the works so that the problem
> that commit 338c15 tried to cope with disappeared, and we don't need
> any
> locks in the handlers any more. Moreover, any locking there can
> potentially result in a deadlock.
>
> So, this patch reverts commits 0ef4ee and 338c15.
>
> Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
> Cc: Tushar Dave <tushar.n.dave@intel.com>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: David S. Miller <davem@davemloft.net>
> ---
> drivers/net/ethernet/intel/e1000/e1000.h | 2 --
> drivers/net/ethernet/intel/e1000/e1000_main.c | 36
> +++----------------------
> 2 files changed, 3 insertions(+), 35 deletions(-)
I will apply your patch to my queue, thanks!
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] e1000: prevent oops when adapter is being closed and reset simultaneously
From: Jeff Kirsher @ 2013-11-22 23:03 UTC (permalink / raw)
To: yzhu1; +Cc: LKML, netdev, zhuyj
In-Reply-To: <528F0DB8.7020604@windriver.com>
On Thu, Nov 21, 2013 at 11:54 PM, yzhu1 <Yanjun.Zhu@windriver.com> wrote:
> Hi, maintainers
>
> This change is based on a similar change made to e1000e support in
> commit bb9e44d0d0f4 ("e1000e: prevent oops when adapter is being closed
> and reset simultaneously"). The same issue has also been observed
> on the older e1000 cards.
>
> Here, we have increased the RESET_COUNT value to 50 because there are too
> many accesses to e1000 nic on stress tests to e1000 nic, it is not enough
> to set RESET_COUT 25. Experimentation has shown that it is enough to set
> RESET_COUNT 50.
>
> Please help me to merge this patch. Thanks a lot.
>
> Zhu Yanjun
Please remember to actually include the driver maintainer for the
driver your patch is against (i.e. me).
I will add your patch to my queue.
--
Cheers,
Jeff
^ permalink raw reply
* Re: dynamic TCP algorithms switching
From: Stephen Hemminger @ 2013-11-22 22:56 UTC (permalink / raw)
To: yan cui; +Cc: netdev, linux-net
In-Reply-To: <CAAVq3rnxE92PsJOChr+H52k5QfG7E=hAjsohK4Um0ZRO9TdYuA@mail.gmail.com>
On Fri, 22 Nov 2013 17:49:58 -0500
yan cui <ccuiyyan@gmail.com> wrote:
> Hi all:
>
> Currently, Linux has kinds of TCP congestion algorithms, such as
> reno, cubic, bic, hybla, ...., and each TCP congestion algorithm has
> its target networking environment. I just wonder to know is it
> possible to do dynamic TCP algorithm switching? In other words, the
> system has a combined TCP congestion algorithm (say, TCP-auto), and it
> behaves like one of the integrated TCP congestion algorithms according
> to different detected networking environment, but can switch to a
> different one. For example, TCP-auto totally uses the set of
> congestion control operations in TCP-cubic by default, but when it
> detects that the current OS uses wireless networking, it switches to
> some wireless friendly TCP congestion algorithm. Does Linux have some
> features like that, or do you (networking developers and users) care
> about it?
>
> Best Wishes!
>
You overestimate the advantage of one verus the other.
It is possible to control algorithm on per-socket, and per-route
but other than benchmarking there or bulk transfer for normal net
traffic Cubic works fine for all environments.
^ permalink raw reply
* dynamic TCP algorithms switching
From: yan cui @ 2013-11-22 22:49 UTC (permalink / raw)
To: netdev, linux-net
Hi all:
Currently, Linux has kinds of TCP congestion algorithms, such as
reno, cubic, bic, hybla, ...., and each TCP congestion algorithm has
its target networking environment. I just wonder to know is it
possible to do dynamic TCP algorithm switching? In other words, the
system has a combined TCP congestion algorithm (say, TCP-auto), and it
behaves like one of the integrated TCP congestion algorithms according
to different detected networking environment, but can switch to a
different one. For example, TCP-auto totally uses the set of
congestion control operations in TCP-cubic by default, but when it
detects that the current OS uses wireless networking, it switches to
some wireless friendly TCP congestion algorithm. Does Linux have some
features like that, or do you (networking developers and users) care
about it?
Best Wishes!
--
Think big; Dream impossible; Make it happen.
^ permalink raw reply
* Re: [PATCH] net: sctp: set chunk->tsn_gap_acked at the end of cycle
From: Vlad Yasevich @ 2013-11-22 22:48 UTC (permalink / raw)
To: Chang, nhorman, davem; +Cc: linux-sctp, netdev, linux-kernel
In-Reply-To: <528FAF50.10100@gmail.com>
On 11/22/2013 02:24 PM, Chang wrote:
>
> On 11/22/2013 03:27 PM, Vlad Yasevich wrote:
>> On 11/22/2013 02:49 AM, Chang Xiangzhong wrote:
>>> tsn_gap_acked is an important state flag in chunk, which indicates if
>>> the
>>> chunk has been acked in gap reports before.
>> Actually, this bit indicates simply that the chunk has been acked. It
>> doesn't state whether it's been acked in a gap report or via
>> cumulative tsn.
> Thanks for pointing this out. Sorry for not having made that clear.
>>
>>> SFR-CACC algorithm depends on this
>>> variable. So set this at the end of each iteration, otherwise the
>>> SFR-CACC
>>> algorithm would never be toggled.
>>>
>>> Signed-off-by: Chang Xiangzhong <changxiangzhong@gmail.com>
>>> ---
>>> net/sctp/outqueue.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
>>> index 1b494fa..bff828c 100644
>>> --- a/net/sctp/outqueue.c
>>> +++ b/net/sctp/outqueue.c
>>> @@ -1396,7 +1396,6 @@ static void sctp_check_transmitted(struct
>>> sctp_outq *q,
>>> * while DATA was outstanding).
>>> */
>>> if (!tchunk->tsn_gap_acked) {
>>> - tchunk->tsn_gap_acked = 1;
>>> if (TSN_lt(*highest_new_tsn_in_sack, tsn))
>>> *highest_new_tsn_in_sack = tsn;
>>> bytes_acked += sctp_data_size(tchunk);
>>> @@ -1460,6 +1459,8 @@ static void sctp_check_transmitted(struct
>>> sctp_outq *q,
>>> */
>>> list_add_tail(lchunk, &tlist);
>>> }
>>> +
>>> + tchunk->tsn_gap_acked = 1;
>> The current code will set the state if it hasn't been set yet. Why is
>> this needed?
> Because in line 1420 ~ 1440 The SFR-CACC algorithms use tsn_gap_acked.
> That "if block" would never be triggered because the varaiable's been
> set. That's why I move the "state changing sentence" to the end of the
> iteration.
>> Now there is an issue with tracking highest_new_tsn_in_sack. The spec
>> is a little vague on this, but the highest_new_tsn_in_sack only supposed
>> to track tsns that have not been resent. If a tsn has been reneged, and
>> then sent again, it is not considered 'new' thus should not count
>> toward highest_new_tsn_in_sack. We currently do not track this right.
> I'll try to figure this out.
So the solution that's been proposed before is to move the CACC block up
and merge it with the !tsn_gap_acked block. This requires additional
change though to only mark highest_new_tsn if the chunk has not been
retransmitted (which you've added in a prior patch).
-vlad
>> -vlad
>>
>> -vlad
>>
>>> } else {
>>> if (tchunk->tsn_gap_acked) {
>>> pr_debug("%s: receiver reneged on data TSN:0x%x\n",
>>>
>
^ permalink raw reply
* Re: [PATCH 2/5] net: MOXA ART: connect to PHY and add ethtool support
From: Florian Fainelli @ 2013-11-22 21:14 UTC (permalink / raw)
To: Jonas Jensen
Cc: netdev, David Miller, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1385132242-3204-2-git-send-email-jonas.jensen@gmail.com>
Hello Jonas,
> + if (!priv->phy_dev)
> + return -ENODEV;
This should not be required since you will fail probing the interface
if you cannot connect to the PHY device.
> +
> + return phy_ethtool_gset(priv->phy_dev, cmd);
> +}
> +
> +static int moxart_set_settings(struct net_device *ndev, struct ethtool_cmd *cmd)
> +{
> + struct moxart_mac_priv_t *priv = netdev_priv(ndev);
> +
> + if (!priv->phy_dev)
> + return -ENODEV;
Same here
> +
> + return phy_ethtool_sset(priv->phy_dev, cmd);
> +}
> +
> +static int moxart_nway_reset(struct net_device *ndev)
> +{
> + struct moxart_mac_priv_t *priv = netdev_priv(ndev);
> +
> + if (!priv->phy_dev)
> + return -EINVAL;
And here
[snip]
> + if (!priv->phy_dev)
> + return -ENODEV;
And here
> +
> + return phy_mii_ioctl(priv->phy_dev, ir, cmd);
> +}
> +
> static void moxart_mac_free_memory(struct net_device *ndev)
> {
> struct moxart_mac_priv_t *priv = netdev_priv(ndev);
> @@ -169,6 +314,10 @@ static int moxart_mac_open(struct net_device *ndev)
> moxart_update_mac_address(ndev);
> moxart_mac_setup_desc_ring(ndev);
> moxart_mac_enable(ndev);
> +
> + if (priv->phy_dev)
> + phy_start(priv->phy_dev);
> +
> netif_start_queue(ndev);
>
> netdev_dbg(ndev, "%s: IMR=0x%x, MACCR=0x%x\n",
> @@ -184,6 +333,9 @@ static int moxart_mac_stop(struct net_device *ndev)
>
> napi_disable(&priv->napi);
>
> + if (priv->phy_dev)
> + phy_stop(priv->phy_dev);
> +
> netif_stop_queue(ndev);
>
> /* disable all interrupts */
> @@ -429,12 +581,22 @@ static struct net_device_ops moxart_netdev_ops = {
> .ndo_set_mac_address = moxart_set_mac_address,
> .ndo_validate_addr = eth_validate_addr,
> .ndo_change_mtu = eth_change_mtu,
> + .ndo_do_ioctl = moxart_do_ioctl,
> };
>
> +static void moxart_adjust_link(struct net_device *ndev)
> +{
> +#ifdef DEBUG
> + struct moxart_mac_priv_t *priv = netdev_priv(ndev);
> +
> + phy_print_status(priv->phy_dev);
> +#endif
This is too simplistic, you should at least do the following:
- check for an update in the PHY duplex setting and update the
Ethernet MAC with this new setting
- check for an update in the PHY speed settings and update relevant
MAC registers (RX/TX clock speed, PHY speed etc...)
Also, it is a good practice to retain the previous link
state/duplex/speed, compare them against the phydev values and call
phy_print_status() if there is any change.
> +}
> +
> static int moxart_mac_probe(struct platform_device *pdev)
> {
> struct device *p_dev = &pdev->dev;
> - struct device_node *node = p_dev->of_node;
> + struct device_node *node = p_dev->of_node, *phy_node;
> struct net_device *ndev;
> struct moxart_mac_priv_t *priv;
> struct resource *res;
> @@ -455,6 +617,20 @@ static int moxart_mac_probe(struct platform_device *pdev)
> priv = netdev_priv(ndev);
> priv->ndev = ndev;
>
> + phy_node = of_parse_phandle(node, "phy-handle", 0);
> + if (!phy_node)
> + dev_err(p_dev, "of_parse_phandle failed\n");
> +
> + if (phy_node) {
> + priv->phy_dev = of_phy_connect(priv->ndev, phy_node,
> + &moxart_adjust_link,
> + 0, PHY_INTERFACE_MODE_MII);
Unless the hardware supports anything but MII, this is fine. A nicer
binding would include a "phy-mode" or "phy-connection-type" property
which describes how the Ethernet MAC and PHY are connected to each
other. You can then retrieve that property using of_get_phy_mode().
--
Florian
^ permalink raw reply
* Re: [PATCH 2/5] net: MOXA ART: connect to PHY and add ethtool support
From: Florian Fainelli @ 2013-11-22 21:09 UTC (permalink / raw)
To: Jonas Jensen
Cc: netdev, davem, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CACmBeS3vyLT7MYeTM6OzYvpWdqJgHp=ys0acf-qun14pbc=oXQ@mail.gmail.com>
2013/11/22 Jonas Jensen <jonas.jensen@gmail.com>:
> On 22 November 2013 15:57, Jonas Jensen <jonas.jensen@gmail.com> wrote:
>> drivers/net/ethernet/moxa/moxart_ether.c | 179 ++++++++++++++++++++++++++++++-
>> drivers/net/ethernet/moxa/moxart_ether.h | 1 +
>> 2 files changed, 179 insertions(+), 1 deletion(-)
>
> I see now I forgot to include the devicetree binding document.
>
> I'll wait for comments.
You are doing two things in your patch, so that means two separate patches.
--
Florian
^ permalink raw reply
* Re: Get rxhash fixes and RFS support in tun
From: Tom Herbert @ 2013-11-22 20:09 UTC (permalink / raw)
To: Jason Wang; +Cc: David Miller, Linux Netdev List, Eric Dumazet, Jerry Chu
In-Reply-To: <528D940A.5010803@redhat.com>
On Wed, Nov 20, 2013 at 9:03 PM, Jason Wang <jasowang@redhat.com> wrote:
> On 11/21/2013 04:25 AM, Tom Herbert wrote:
>> This patch series fixes some subtle bugs in tun use of skb->rxhash, all
>> rxhash hash not be cleared appropraitely, and adds support for tun flows
>> to work with RFS.
>>
>>
>> Testing, in particular with tun, hasn't been completed yet.
>
> Interesting work, did you plan to test this with a kvm guest or even a
> multi-queue guest?
>
Yes, I think that is the direction. Once we clean up the hashing in
the stack, next thing will be to extend RPS/RFS and computed hashes
functionality all the way into the guest. I'm not sure yet if the
flow director like mechanism (like in tun) is sufficient, or if we
want to expose aRFS to the guest driver. As I mentioned, first we
need to test RFS integration in tun to see the effect.
> Thanks
^ permalink raw reply
* Re: [PATCH net v3] bonding: disable arp and enable mii monitoring when bond change to no uses arp mode
From: Nikolay Aleksandrov @ 2013-11-22 20:01 UTC (permalink / raw)
To: Ding Tianhong, Andy Gospodarek, Dan Williams, David Miller
Cc: fubar, vfalico, netdev
In-Reply-To: <528F6A1B.70904@huawei.com>
On 11/22/2013 03:28 PM, Ding Tianhong wrote:
> Because the ARP monitoring is not support for 802.3ad, but I still
> could change the mode to 802.3ad from ab mode while ARP monitoring
> is running, it is incorrect.
>
> So add a check for 802.3ad in bonding_store_mode to fix the problem,
> and make a new macro BOND_NO_USES_ARP() to simplify the code.
>
> v2: according to the Dan Williams's suggestion, bond mode is the most
> important bond option, it should override any of the other sub-options.
> So when the mode is changed, the conficting values should be cleared
> or reset, otherwise the user has to duplicate more operations to modify
> the logic. I disable the arp and enable mii monitoring when the bond mode
> is changed to AB, TB and 8023AD if the arp interval is true.
>
> v3: according to the Nik's suggestion, the default value of miimon should need
> a name, there is several place to use it, and the bond_store_arp_interval()
> could use micro BOND_NO_USES_ARP to make the code more simpify.
>
> Suggested-by: Dan Williams <dcbw@redhat.com>
> Suggested-by: Nikolay Aleksandrov <nikolay@redhat.com>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
Reviewed-by: Nikolay Aleksandrov <nikolay@redhat.com>
^ 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