Hi!


Here are three simple patches for net-next aka to-be-2.6.35.

The following changes since commit 3a5b27bf6f29574d667230c7e76e4b83fe3014e0:
  Linus Torvalds (1):
        Merge branch 'for-linus' of git://gitorious.org/linux-omap-dss2/linux

are available in the git repository at:

  git://dev.medozas.de/linux net

Jan Engelhardt (3):
      net: tcp: make hybla selectable as default congestion module
      net: tcp: make veno selectable as default congestion module
      net: core: add IFLA_STATS64 support

 include/linux/if_link.h |   33 +++++++++++++++++++++++++++++++++
 net/core/rtnetlink.c    |   42 +++++++++++++++++++++++++++++++++++++++++-
 net/ipv4/Kconfig        |    8 ++++++++
 3 files changed, 82 insertions(+), 1 deletions(-)
--

[ message continues ]

`ip -s link` shows interface counters truncated to 32 bit. This is
because interface statistics are transported only in 32-bit quantity
to userspace. This commit adds a new IFLA_STATS64 attribute that
exports them in full 64 bit.

References: http://lkml.indiana.edu/hypermail/linux/kernel/0307.3/0215.html
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
 include/linux/if_link.h |   33 +++++++++++++++++++++++++++++++++
 net/core/rtnetlink.c    |   42 +++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 74 insertions(+), 1 deletions(-)

diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index c9bf92c..cfd420b 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -37,6 +37,38 @@ struct rtnl_link_stats {
 	__u32	tx_compressed;
 };
 
+struct rtnl_link_stats64 {
+	__u64	rx_packets;		/* total packets received	*/
+	__u64	tx_packets;		/* total packets transmitted	*/
+	__u64	rx_bytes;		/* total bytes received 	*/
+	__u64	tx_bytes;		/* total bytes transmitted	*/
+	__u64	rx_errors;		/* bad packets received		*/
+	__u64	tx_errors;		/* packet transmit problems	*/
+	__u64	rx_dropped;		/* no space in linux buffers	*/
+	__u64	tx_dropped;		/* no space available in linux	*/
+	__u64	multicast;		/* multicast packets received	*/
+	__u64	collisions;
+
+	/* detailed rx_errors: */
+	__u64	rx_length_errors;
+	__u64	rx_over_errors;		/* receiver ring buff overflow	*/
+	__u64	rx_crc_errors;		/* recved pkt with crc error	*/
+	__u64	rx_frame_errors;	/* recv'd frame alignment error */
+	__u64	rx_fifo_errors;		/* recv'r fifo overrun		*/
+	__u64	rx_missed_errors;	/* receiver missed packet	*/
+
+	/* detailed tx_errors */
+	__u64	tx_aborted_errors;
+	__u64	tx_carrier_errors;
+	__u64	tx_fifo_errors;
+	__u64	tx_heartbeat_errors;
+	__u64	tx_window_errors;
+
+	/* for cslip etc */
+	__u64	rx_compressed;
+	__u64	tx_compressed;
+};
+
 /* The struct should be in sync with struct ifmap */
 struct rtnl_link_ifmap {
 	__u64	mem_start;
@@ -83,6 +115,7 @@ enum ...
[ message continues ]

Why calling dev_get_stats(dev) a second time ?


--

[ message continues ]

On Thu, 11 Mar 2010 20:57:29 +0100

What is the point since net_device_stats has only 32 bit counters.
The last time this came up the issue was is that is not possible
to atomically increment a 64 bit counter on most 32 bit platforms.
--

[ message continues ]

From: Stephen Hemminger <shemminger@vyatta.com>

On 64-bit it has 64-bit counters, yet we only report 32-bit
counters to userspace via netlink even in that case.

That's what Jan is fixing here.
--

[ message continues ]

On a side note, is it perhaps possible to use jiffies-like magic to
also have 64-bit counters on 32-bit, or is that still too expensive?
--

[ message continues ]

From: Jan Engelhardt <jengelh@medozas.de>

I think there might still be atomicity issues.

We've been telling people to poll periodically in userspace to avoid
these problems, but that has limitations as network speeds increase.
--

[ message continues ]

On Thu, 11 Mar 2010 12:26:39 -0800 (PST)

That make sense, but maybe we shouldn't send IFLA_STATS64 on
32bit platforms.

--

[ message continues ]

From: Stephen Hemminger <shemminger@vyatta.com>

Let's at least be optimistic that we'll be able to support 64-bit
stats on 32-bit at some point :-)
--

[ message continues ]

I was about to say. There is hope: whenever you least expect it, 
academia comes up with a perfectly foundated theory and plan to solve 
the problem. (N.B.: But the initial implementation generally sucks ;-)
--

[ message continues ]

Somehow I'd prefer to have consistency. Platform-specific 
actions and/or payload I think we already were plagued enough by 
syscalls and iptables. (Just to name two.)
--

[ message continues ]

On Thu, 11 Mar 2010 23:13:18 +0100 (CET)

But if you send 32bit truncated values when 64 bit is expected
then users are going to complain

-- 
--

[ message continues ]

From: Stephen Hemminger <shemminger@vyatta.com>

They already complain, a lot.

This isn't going to change the situation at all, and
I agree with Jan that consistency is the trumping factor
here.
--

[ message continues ]

On Thu, 11 Mar 2010 14:54:12 -0800 (PST)

But if non utilities will already adapt to new/old kernel, so
just don't put out 64 bit values if the platform is 32 bit.
When/if 32 bit platforms support it, great add the extra stats.

-- 
--

[ message continues ]

From: Stephen Hemminger <shemminger@vyatta.com>

How about we just make userland ready for it and:

1) Emitting it now will get it tested even on 32-bit

2) They'll be ready when the drivers can keep track of
   64-bit stats too.

Stephen I've heard your side of the story, I just don't
agree with it :-)
--

[ message continues ]

On Thu, 11 Mar 2010 15:15:29 -0800 (PST)

I'm okay with it. just raising the issue.

-- 
--

[ message continues ]

From: Jan Engelhardt <jengelh@medozas.de>

Applied.
--

[ message continues ]

Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
 net/ipv4/Kconfig |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index 0c94a1a..731c47b 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -587,6 +587,9 @@ choice
 	config DEFAULT_HTCP
 		bool "Htcp" if TCP_CONG_HTCP=y
 
+	config DEFAULT_HYBLA
+		bool "Hybla" if TCP_CONG_HYBLA=y
+
 	config DEFAULT_VEGAS
 		bool "Vegas" if TCP_CONG_VEGAS=y
 
@@ -610,6 +613,7 @@ config DEFAULT_TCP_CONG
 	default "bic" if DEFAULT_BIC
 	default "cubic" if DEFAULT_CUBIC
 	default "htcp" if DEFAULT_HTCP
+	default "hybla" if DEFAULT_HYBLA
 	default "vegas" if DEFAULT_VEGAS
 	default "westwood" if DEFAULT_WESTWOOD
 	default "reno" if DEFAULT_RENO
-- 
1.7.0

--

[ message continues ]

On Thu, 11 Mar 2010 20:57:27 +0100

Hybla seems too experimental to be made default.
--

[ message continues ]

I run Hybla since 2006 on anything that is not connected via
wireless and I did not notice any pressing issues.

Also, the patch does not make hybla the default default (reno remains),
just the default once explicitly selected in a two-step process:

1. CONFIG_TCP_CONG_HYBLA=y
*and*
2. choosing Hybla in CONFIG_DEFAULT_TCP_CONG

I think that is enough of a "safety measure" against any potential
unsuspecting users.
--

[ message continues ]

From: Jan Engelhardt <jengelh@medozas.de>

Applied.
--

[ message continues ]