Netdev List
 help / color / mirror / Atom feed
* [patch 03/16] net: Replace old style lock initializer
From: Thomas Gleixner @ 2009-11-06 22:41 UTC (permalink / raw)
  To: LKML; +Cc: Ingo Molnar, Peter Zijlstra, netdev, David S. Miller
In-Reply-To: <20091106223547.784916750@linutronix.de>

[-- Attachment #1: net-replace-old-style-lock-init.patch --]
[-- Type: text/plain, Size: 747 bytes --]

SPIN_LOCK_UNLOCKED is deprecated. Use DEFINE_SPINLOCK instead.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: netdev@vger.kernel.org
Cc: David S. Miller <davem@davemloft.net>
---
 net/core/drop_monitor.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6/net/core/drop_monitor.c
===================================================================
--- linux-2.6.orig/net/core/drop_monitor.c
+++ linux-2.6/net/core/drop_monitor.c
@@ -41,7 +41,7 @@ static void send_dm_alert(struct work_st
  * netlink alerts
  */
 static int trace_state = TRACE_OFF;
-static spinlock_t trace_state_lock = SPIN_LOCK_UNLOCKED;
+static DEFINE_SPINLOCK(trace_state_lock);
 
 struct per_cpu_dm_data {
 	struct work_struct dm_alert_work;

^ permalink raw reply

* [net-2.6 PATCH 1/3] ixgbe: Fix gso_max_size for 82599 when DCB is enabled
From: Jeff Kirsher @ 2009-11-06 22:55 UTC (permalink / raw)
  To: davem; +Cc: netdev, gospo, Yi Zou, Peter P Waskiewicz Jr, Jeff Kirsher

From: Yi Zou <yi.zou@intel.com>

The 32k gso_max_size when DCB is enabled is for 82598 only, not for 82599.

Signed-off-by: Yi Zou <yi.zou@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---

 drivers/net/ixgbe/ixgbe_main.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index cbb143c..26fc1df 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -2471,7 +2471,10 @@ static void ixgbe_configure(struct ixgbe_adapter *adapter)
 	ixgbe_restore_vlan(adapter);
 #ifdef CONFIG_IXGBE_DCB
 	if (adapter->flags & IXGBE_FLAG_DCB_ENABLED) {
-		netif_set_gso_max_size(netdev, 32768);
+		if (hw->mac.type == ixgbe_mac_82598EB)
+			netif_set_gso_max_size(netdev, 32768);
+		else
+			netif_set_gso_max_size(netdev, 65536);
 		ixgbe_configure_dcb(adapter);
 	} else {
 		netif_set_gso_max_size(netdev, 65536);


^ permalink raw reply related

* [net-2.6 PATCH 2/3] ixgbe: Fix checking TFCS register for TXOFF status when DCB is enabled
From: Jeff Kirsher @ 2009-11-06 22:56 UTC (permalink / raw)
  To: davem; +Cc: netdev, gospo, Yi Zou, Peter P Waskiewicz Jr, Jeff Kirsher
In-Reply-To: <20091106225526.28063.83720.stgit@localhost.localdomain>

From: Yi Zou <yi.zou@intel.com>

When DCB is enabled, the ixgbe_check_tx_hang() should check the corresponding
TC's TXOFF in TFCS based on the TC that the tx ring belongs to. Adds a
function to map from the tx_ring hw reg_idx to the correspodning TC and read
TFCS accordingly.

Signed-off-by: Yi Zou <yi.zou@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---

 drivers/net/ixgbe/ixgbe_main.c |   52 +++++++++++++++++++++++++++++++++++++++-
 1 files changed, 51 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 26fc1df..2d0f618 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -226,6 +226,56 @@ static void ixgbe_unmap_and_free_tx_resource(struct ixgbe_adapter *adapter,
 	/* tx_buffer_info must be completely set up in the transmit path */
 }
 
+/**
+ * ixgbe_tx_is_paused - check if the tx ring is paused
+ * @adapter: the ixgbe adapter
+ * @tx_ring: the corresponding tx_ring
+ *
+ * If not in DCB mode, checks TFCS.TXOFF, otherwise, find out the
+ * corresponding TC of this tx_ring when checking TFCS.
+ *
+ * Returns : true if paused
+ */
+static inline bool ixgbe_tx_is_paused(struct ixgbe_adapter *adapter,
+                                      struct ixgbe_ring *tx_ring)
+{
+	int tc;
+	u32 txoff = IXGBE_TFCS_TXOFF;
+
+#ifdef CONFIG_IXGBE_DCB
+	if (adapter->flags & IXGBE_FLAG_DCB_ENABLED) {
+		int reg_idx = tx_ring->reg_idx;
+		int dcb_i = adapter->ring_feature[RING_F_DCB].indices;
+
+		if (adapter->hw.mac.type == ixgbe_mac_82598EB) {
+			tc = reg_idx >> 2;
+			txoff = IXGBE_TFCS_TXOFF0;
+		} else if (adapter->hw.mac.type == ixgbe_mac_82599EB) {
+			tc = 0;
+			txoff = IXGBE_TFCS_TXOFF;
+			if (dcb_i == 8) {
+				/* TC0, TC1 */
+				tc = reg_idx >> 5;
+				if (tc == 2) /* TC2, TC3 */
+					tc += (reg_idx - 64) >> 4;
+				else if (tc == 3) /* TC4, TC5, TC6, TC7 */
+					tc += 1 + ((reg_idx - 96) >> 3);
+			} else if (dcb_i == 4) {
+				/* TC0, TC1 */
+				tc = reg_idx >> 6;
+				if (tc == 1) {
+					tc += (reg_idx - 64) >> 5;
+					if (tc == 2) /* TC2, TC3 */
+						tc += (reg_idx - 96) >> 4;
+				}
+			}
+		}
+		txoff <<= tc;
+	}
+#endif
+	return IXGBE_READ_REG(&adapter->hw, IXGBE_TFCS) & txoff;
+}
+
 static inline bool ixgbe_check_tx_hang(struct ixgbe_adapter *adapter,
                                        struct ixgbe_ring *tx_ring,
                                        unsigned int eop)
@@ -237,7 +287,7 @@ static inline bool ixgbe_check_tx_hang(struct ixgbe_adapter *adapter,
 	adapter->detect_tx_hung = false;
 	if (tx_ring->tx_buffer_info[eop].time_stamp &&
 	    time_after(jiffies, tx_ring->tx_buffer_info[eop].time_stamp + HZ) &&
-	    !(IXGBE_READ_REG(&adapter->hw, IXGBE_TFCS) & IXGBE_TFCS_TXOFF)) {
+	    !ixgbe_tx_is_paused(adapter, tx_ring)) {
 		/* detected Tx unit hang */
 		union ixgbe_adv_tx_desc *tx_desc;
 		tx_desc = IXGBE_TX_DESC_ADV(*tx_ring, eop);


^ permalink raw reply related

* [net-2.6 PATCH 3/3] ixgbe: fix traffic hangs on Tx with ioatdma loaded
From: Jeff Kirsher @ 2009-11-06 22:56 UTC (permalink / raw)
  To: davem; +Cc: netdev, gospo, Don Skidmore, Peter P Waskiewicz Jr, Jeff Kirsher
In-Reply-To: <20091106225526.28063.83720.stgit@localhost.localdomain>

From: Don Skidmore <donald.c.skidmore@intel.com>

When ioatdma was loaded we we were unable to transmit traffic.  We weren't
using the correct registers in ixgbe_update_tx_dca for 82599 systems.
Likewise in ixgbe_configure_tx() we weren't disabling the arbiter before
modifying MTQC.

Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---

 drivers/net/ixgbe/ixgbe_main.c |   27 +++++++++++++++++++++++----
 1 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 2d0f618..5bd9e6b 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -44,6 +44,7 @@
 
 #include "ixgbe.h"
 #include "ixgbe_common.h"
+#include "ixgbe_dcb_82599.h"
 
 char ixgbe_driver_name[] = "ixgbe";
 static const char ixgbe_driver_string[] =
@@ -462,19 +463,23 @@ static void ixgbe_update_tx_dca(struct ixgbe_adapter *adapter,
 	u32 txctrl;
 	int cpu = get_cpu();
 	int q = tx_ring - adapter->tx_ring;
+	struct ixgbe_hw *hw = &adapter->hw;
 
 	if (tx_ring->cpu != cpu) {
-		txctrl = IXGBE_READ_REG(&adapter->hw, IXGBE_DCA_TXCTRL(q));
 		if (adapter->hw.mac.type == ixgbe_mac_82598EB) {
+			txctrl = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL(q));
 			txctrl &= ~IXGBE_DCA_TXCTRL_CPUID_MASK;
 			txctrl |= dca3_get_tag(&adapter->pdev->dev, cpu);
+			txctrl |= IXGBE_DCA_TXCTRL_DESC_DCA_EN;
+			IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL(q), txctrl);
 		} else if (adapter->hw.mac.type == ixgbe_mac_82599EB) {
+			txctrl = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL_82599(q));
 			txctrl &= ~IXGBE_DCA_TXCTRL_CPUID_MASK_82599;
 			txctrl |= (dca3_get_tag(&adapter->pdev->dev, cpu) <<
-			           IXGBE_DCA_TXCTRL_CPUID_SHIFT_82599);
+			          IXGBE_DCA_TXCTRL_CPUID_SHIFT_82599);
+			txctrl |= IXGBE_DCA_TXCTRL_DESC_DCA_EN;
+			IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL_82599(q), txctrl);
 		}
-		txctrl |= IXGBE_DCA_TXCTRL_DESC_DCA_EN;
-		IXGBE_WRITE_REG(&adapter->hw, IXGBE_DCA_TXCTRL(q), txctrl);
 		tx_ring->cpu = cpu;
 	}
 	put_cpu();
@@ -1963,11 +1968,25 @@ static void ixgbe_configure_tx(struct ixgbe_adapter *adapter)
 			break;
 		}
 	}
+
 	if (hw->mac.type == ixgbe_mac_82599EB) {
+		u32 rttdcs;
+
+		/* disable the arbiter while setting MTQC */
+		rttdcs = IXGBE_READ_REG(hw, IXGBE_RTTDCS);
+		rttdcs |= IXGBE_RTTDCS_ARBDIS;
+		IXGBE_WRITE_REG(hw, IXGBE_RTTDCS, rttdcs);
+
 		/* We enable 8 traffic classes, DCB only */
 		if (adapter->flags & IXGBE_FLAG_DCB_ENABLED)
 			IXGBE_WRITE_REG(hw, IXGBE_MTQC, (IXGBE_MTQC_RT_ENA |
 			                IXGBE_MTQC_8TC_8TQ));
+		else
+			IXGBE_WRITE_REG(hw, IXGBE_MTQC, IXGBE_MTQC_64Q_1PB);
+
+		/* re-eable the arbiter */
+		rttdcs &= ~IXGBE_RTTDCS_ARBDIS;
+		IXGBE_WRITE_REG(hw, IXGBE_RTTDCS, rttdcs);
 	}
 }
 


^ permalink raw reply related

* Re: RFC 5482
From: Anirban Sinha @ 2009-11-06 23:08 UTC (permalink / raw)
  To: netdev; +Cc: davem
In-Reply-To: <Pine.LNX.4.64.0911061041540.30985@sleet.zeugmasystems.local>

oops, sorry. Typo.

> Also as a side question, i am wondering if it's possible to change/control the
> TCP three-way handshake timeout (reception of the last SYN_ACK) on a
> per-connection basis.

It will be the timeout on the server side between SYN-ACK and the last ACK
from the peer.

^ permalink raw reply

* Re: PATCH: Network Device Naming mechanism and policy
From: dann frazier @ 2009-11-06 23:17 UTC (permalink / raw)
  To: Matt Domsch, Narendra_K, bryan, bhutchings, netdev, linux-hotplug,
	Jordan_Hargrave
In-Reply-To: <20091106223524.GA27121@bongo.bofh.it>

On Fri, Nov 06, 2009 at 11:35:24PM +0100, Marco d'Itri wrote:
> On Nov 06, Matt Domsch <Matt_Domsch@Dell.com> wrote:
> 
> > > As a distribution developer I highly value solutions like this which do
> > > not require patching every application which deals with interface names
> > > and then teaching users about aliases which only work in some places and
> > > are unknown to the kernel.
> > Fair enough - but would you object if we changed the naming scheme
> > from eth%d to something else?
> I suppose that this would depend on what else. :-)
> Since you want radical changes I recommend that you design the new
> persistent naming infrastructure in a way that will allow root to choose
> to use the classic naming scheme, or many users will scream a lot and at
> least some distributions will do it anyway.
> I also expect that providing choice at the beginning of development may
> lead to more acceptance later if and when the new scheme will have
> proved itself to be superior (at least in some situations).
> You have tought about this for a long time and if so far you have not
> found a solution which is widely considered superior then I doubt that
> one will appear soon. Providing your favourite naming scheme as an
> optional add on will immediately benefit those who like it and greatly
> reduce opposition from those who do not.

This seems to me like a good installer feature - give the user an
option to enter a name for an interface, with the default option
to use the eth* names. To illustrate by example, I imagine an
installer flow that looks like this:

 [Do Hardware Discovery]
 [Automatically reorder kernel names for reasonable defaults;
  eth0-eth{n-1} map to n onboard nics]

  Sample user interface for network configuration:

 ------------Choose an interface to configure --------------
 | Multiple unconfigured interfaces detected.              |
 | Select an interface to configure by:                    |
 |   1. Kernel name (eth0, eth1, etc)                      |
 |   2. Mac Address                                        |
 |   3. Chassis name                                       |
 |   4. PCI Slot                                           |
 -----------------------------------------------------------

 ----Choose an interface to configure (by chassis name)-----
 |   1. LOM0                                               |
 |   2. LOM1                                               |
 |   3. Undefined                                          |
 |   4. Undefined                                          |
 -----------------------------------------------------------

 ----------------Name interface - (chassis name LOM0)-------
 |   Name to use for this interface [eth0]: __mynet0_      |
 -----------------------------------------------------------

 -----------------------------------------------------------
 | Configure interface - mynet0                            |
 |   1. DHCP                                               |
 |   2. Static                                             |
 |   ...                                                   |
 -----------------------------------------------------------
 
[Generate udev rules that bind the user-selected name to
 the user-selected attribute]

^ permalink raw reply

* hisax: remove bad udelay call to fix build error on ARM
From: Martin Michlmayr @ 2009-11-07  0:52 UTC (permalink / raw)
  To: Karsten Keil, Tilman Schmidt, David Miller; +Cc: netdev

The hisax ISDN driver fails to build on ARM with CONFIG_HISAX_ELSA:

| drivers/built-in.o: In function `modem_set_dial':
| drivers/isdn/hisax/elsa_ser.c:535: undefined reference to `__bad_udelay'
| drivers/isdn/hisax/elsa_ser.c:544: undefined reference to `__bad_udelay'
| drivers/built-in.o: In function `modem_set_init':
| drivers/isdn/hisax/elsa_ser.c:486: undefined reference to `__bad_udelay'
| [...]

According to the comment in arch/arm/include/asm/delay.h, __bad_udelay
is specifically designed on ARM to produce a build failure when udelay
is called with a value > 2000.

Signed-off-by: Martin Michlmayr <tbm@cyrius.com>

diff --git a/drivers/isdn/hisax/elsa_ser.c b/drivers/isdn/hisax/elsa_ser.c
index f181db4..1657bba 100644
--- a/drivers/isdn/hisax/elsa_ser.c
+++ b/drivers/isdn/hisax/elsa_ser.c
@@ -477,62 +477,62 @@ static void
 modem_set_init(struct IsdnCardState *cs) {
 	int timeout;
 
-#define RCV_DELAY 20000	
+#define RCV_DELAY 20
 	modem_write_cmd(cs, MInit_1, strlen(MInit_1));
 	timeout = 1000;
 	while(timeout-- && cs->hw.elsa.transcnt)
 		udelay(1000);
 	debugl1(cs, "msi tout=%d", timeout);
-	udelay(RCV_DELAY);
+	mdelay(RCV_DELAY);
 	modem_write_cmd(cs, MInit_2, strlen(MInit_2));
 	timeout = 1000;
 	while(timeout-- && cs->hw.elsa.transcnt)
 		udelay(1000);
 	debugl1(cs, "msi tout=%d", timeout);
-	udelay(RCV_DELAY);
+	mdelay(RCV_DELAY);
 	modem_write_cmd(cs, MInit_3, strlen(MInit_3));
 	timeout = 1000;
 	while(timeout-- && cs->hw.elsa.transcnt)
 		udelay(1000);
 	debugl1(cs, "msi tout=%d", timeout);
-	udelay(RCV_DELAY);
+	mdelay(RCV_DELAY);
 	modem_write_cmd(cs, MInit_4, strlen(MInit_4));
 	timeout = 1000;
 	while(timeout-- && cs->hw.elsa.transcnt)
 		udelay(1000);
 	debugl1(cs, "msi tout=%d", timeout);
-	udelay(RCV_DELAY );
+	mdelay(RCV_DELAY);
 	modem_write_cmd(cs, MInit_5, strlen(MInit_5));
 	timeout = 1000;
 	while(timeout-- && cs->hw.elsa.transcnt)
 		udelay(1000);
 	debugl1(cs, "msi tout=%d", timeout);
-	udelay(RCV_DELAY);
+	mdelay(RCV_DELAY);
 	modem_write_cmd(cs, MInit_6, strlen(MInit_6));
 	timeout = 1000;
 	while(timeout-- && cs->hw.elsa.transcnt)
 		udelay(1000);
 	debugl1(cs, "msi tout=%d", timeout);
-	udelay(RCV_DELAY);
+	mdelay(RCV_DELAY);
 	modem_write_cmd(cs, MInit_7, strlen(MInit_7));
 	timeout = 1000;
 	while(timeout-- && cs->hw.elsa.transcnt)
 		udelay(1000);
 	debugl1(cs, "msi tout=%d", timeout);
-	udelay(RCV_DELAY);
+	mdelay(RCV_DELAY);
 }
 
 static void
 modem_set_dial(struct IsdnCardState *cs, int outgoing) {
 	int timeout;
-#define RCV_DELAY 20000	
+#define RCV_DELAY 20
 
 	modem_write_cmd(cs, MInit_speed28800, strlen(MInit_speed28800));
 	timeout = 1000;
 	while(timeout-- && cs->hw.elsa.transcnt)
 		udelay(1000);
 	debugl1(cs, "msi tout=%d", timeout);
-	udelay(RCV_DELAY);
+	mdelay(RCV_DELAY);
 	if (outgoing)
 		modem_write_cmd(cs, MInit_dialout, strlen(MInit_dialout));
 	else
@@ -541,7 +541,7 @@ modem_set_dial(struct IsdnCardState *cs, int outgoing) {
 	while(timeout-- && cs->hw.elsa.transcnt)
 		udelay(1000);
 	debugl1(cs, "msi tout=%d", timeout);
-	udelay(RCV_DELAY);
+	mdelay(RCV_DELAY);
 }
 
 static void

-- 
Martin Michlmayr
http://www.cyrius.com/

^ permalink raw reply related

* Re: [NEXT PULL 00/17] IEEE 802.15.4 stack updates.
From: David Miller @ 2009-11-07  2:02 UTC (permalink / raw)
  To: dbaryshkov; +Cc: netdev, slapin
In-Reply-To: <1257511181-19403-1-git-send-email-dbaryshkov@gmail.com>

aFrom: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Fri,  6 Nov 2009 15:39:24 +0300

> Please pull into net-next an update for IEEE 802.15.4
> 
> The following changes since commit 6a2a2d6bf8581216e08be15fcb563cfd6c430e1e:
>   Gilad Ben-Yossef (1):
>         tcp: Use defaults when no route options are available
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/lowpan/lowpan.git for-next

Looks good, pulled, thanks a lot!

^ permalink raw reply

* Re: [PATCH net-next] Phonet: use rwlock for sockets list
From: David Miller @ 2009-11-07  2:03 UTC (permalink / raw)
  To: remi.denis-courmont; +Cc: eric.dumazet, netdev
In-Reply-To: <200911061629.42911.remi.denis-courmont@nokia.com>

From: "Rémi Denis-Courmont" <remi.denis-courmont@nokia.com>
Date: Fri, 6 Nov 2009 16:29:42 +0200

> So if you say R/W locks suck, screw this patch.

They do, so I'm tossing it :-)

^ permalink raw reply

* Re: netfilter 02/02: xt_connlimit: fix regression caused by zero family value
From: David Miller @ 2009-11-07  2:08 UTC (permalink / raw)
  To: kaber; +Cc: jengelh, netfilter-devel, netdev
In-Reply-To: <4AF43782.50604@trash.net>

From: Patrick McHardy <kaber@trash.net>
Date: Fri, 06 Nov 2009 15:49:38 +0100

> Jan Engelhardt wrote:
>> On Thursday 2009-11-05 19:23, Patrick McHardy wrote:
>>>    netfilter: xt_connlimit: fix regression caused by zero family value
>>>    
>>>    Commit v2.6.28-rc1~7172~1092~2 was slightly incomplete; not all
>>>    instances of par->match->family were changed to par->family.
>>>    
>>>    Netfilter bugzilla #610.
>> 
>> Hold it.
>> git would never output ~7172~1092~2 because ~8266 would be much simpler.
>> 
>> I originally wrote "Commit v2.6.28-rc1~717^2~109^2~2", but one of your 
>> programs seems to eat commit messages or more.
> 
> Indeed, my email client displays ^2 as ², which cut and paste transforms
> to 2 :)

Ok, so I'll apply Jan's fixed up version, thanks!

^ permalink raw reply

* Re: pull request: wireless-2.6 2009-11-06
From: David Miller @ 2009-11-07  2:22 UTC (permalink / raw)
  To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20091106204034.GI2782@tuxdriver.com>

From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 6 Nov 2009 15:40:34 -0500

> Three more intended for 2.6.32, two oops fixes and a revert of a patch
> that traded one bug for another.  One of the oops fixes reorders some
> cancel_delayed_work_sync calls and the other does some bit testing to
> avoid scheduling work after a device has been removed.
> 
> Please let me know if there are problems!

Pulled, thanks a lot John.

^ permalink raw reply

* TC-HTB issue : low throughput
From: Jean Tourrilhes @ 2009-11-07  2:43 UTC (permalink / raw)
  To: netdev

	Hi,

	I'm playing with a TC-HTB. I'm noticing that the throughput is
low. As the LARTC mailing list seems to be dead, I would welcome
suggestions...
	The example below may seem contrived, but I reduced it to
a simple testcase to make it easier to reproduce.

System :
------
	Debian Lenny with 2.6.30.9
	Quad Core 2.5 GHz Q9300
	Intel 1Gb/s NIC, e1000e driver

Setup :
-----
# brctl addbr br0
# brctl addif br0 eth5.33
# brctl addif br0 eth6.34
# brctl addif br0 eth7.38

#iptables -A FORWARD -t mangle -s 10.10.32.38 -j CLASSIFY --set-class 1:2

#tc qdisc add dev eth6.34 root handle 1: htb default 3
#tc class add dev eth6.34 parent 1: classid 1:1 htb rate 1000mbit ceil 1000mbit
#tc class add dev eth6.34 parent 1:1 classid 1:2 htb rate 3kbit ceil 1000mbit prio 1
#tc class add dev eth6.34 parent 1:1 classid 1:3 htb rate 3kbit ceil 1000mbit prio 2

Topology :
--------
Four PCs with Linux :
10.10.10.32 on br0
10.10.10.33 connected to eth5.33 (sender)
10.10.10.38 connected to eth7.38 (sender)
10.10.10.34 connected to eth6.34 (receiver)

Behaviour :
---------
	If I set only qdisc 1: and class 1:1, but *NOT* 1:2 and 1:3 :
	Each host independantly : ~935 Mb/s
	Both host together, for 10.10.10.38 : ~527 Mb/s ;
	Both host together, for 10.10.10.33 : ~443 Mb/s

	If I add classes 1:2 and 1:3 :
	Each host independantly : ~170 Mb/s.
	Both host together, for 10.10.10.38 : ~106 Mb/s ;
	Both host together, for 10.10.10.33 : ~135 Mb/s

	So, not only performance did drop significantely, but
prioritisation did not happen as expected.

Weird detail :
------------
	I've noticed that /sbin/tc calculates a very low burst
value. This is due to the content of /proc/net/psched. I'm wondering
if the burst calculation is what causes the issue here.
	However, I tried with "burst 50kb" and saw no difference...

Dump of TC
----------
# tc -s class show dev eth6.34
class htb 1:1 root rate 1000Mbit ceil 1000Mbit burst 1375b cburst 1375b 
 Sent 770653596 bytes 509070 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 82776Kbit 6835pps backlog 0b 0p requeues 0 
 lended: 509026 borrowed: 0 giants: 0
 tokens: 11 ctokens: 11

class htb 1:2 parent 1:1 prio 1 rate 3000bit ceil 1000Mbit burst 1599b cburst 13
75b 
 Sent 369190389 bytes 243876 pkt (dropped 3239, overlimits 0 requeues 0) 
 rate 44781Kbit 3698pps backlog 0b 0p requeues 0 
 lended: 20 borrowed: 243856 giants: 0
 tokens: -1384355 ctokens: 11

class htb 1:3 parent 1:1 prio 2 rate 3000bit ceil 1000Mbit burst 1599b cburst 13
75b 
 Sent 401463207 bytes 265194 pkt (dropped 3005, overlimits 0 requeues 0) 
 rate 37996Kbit 3137pps backlog 0b 0p requeues 0 
 lended: 24 borrowed: 265170 giants: 0
 tokens: -3719389 ctokens: 11

# tc -s qdisc show dev eth6.34
qdisc htb 1: root r2q 10 default 3 direct_packets_stat 0
 Sent 770653852 bytes 509071 pkt (dropped 6244, overlimits 25973 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 


	Thanks in advance for any help...

	Jean

^ permalink raw reply

* Re: [PATCH 1/2] be2net: fix to set proper flow control on resume
From: David Miller @ 2009-11-07  4:26 UTC (permalink / raw)
  To: ajitk; +Cc: netdev
In-Reply-To: <20091106120445.GA19181@serverengines.com>

From: Ajit Khaparde <ajitk@serverengines.com>
Date: Fri, 6 Nov 2009 17:36:59 +0530

> If be2 goes into suspend after a user changes the flow control settings,
> we are not programming them back after resume. This patch takes care of it.
> We now get the flow control settings before going to suspend mode and
> then apply them during resume.
> 
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>

Applied to net-2.6

^ permalink raw reply

* Re: [PATCH 2/2] be2net: Bug fix to send config commands to hardware after netdev_register
From: David Miller @ 2009-11-07  4:26 UTC (permalink / raw)
  To: ajitk; +Cc: netdev
In-Reply-To: <20091106120720.GA19198@serverengines.com>

From: Ajit Khaparde <ajitk@serverengines.com>
Date: Fri, 6 Nov 2009 17:37:32 +0530

> Sending config commands to be2 hardware before netdev_register is
> completed, is sometimes causing the async link notification to arrive
> even before the driver is ready to handle it. The commands for vlan
> config and flow control settings can infact wait till be_open.
> This patch takes care of that.
> 
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>

Applied to net-2.6

^ permalink raw reply

* Re: [PATCH] ems_usb: Fix byte order issues on big endian machines
From: David Miller @ 2009-11-07  4:26 UTC (permalink / raw)
  To: haas; +Cc: netdev, socketcan-core
In-Reply-To: <20091104154824.18199.15573.stgit@localhost.localdomain>

From: Sebastian Haas <haas@ems-wuensche.com>
Date: Wed, 04 Nov 2009 16:48:24 +0100

> CPC-USB is using a ARM7 core with little endian byte order. The "id" field
> in can_msg needs byte order conversion from/to CPU byte order.
> 
> Signed-off-by: Sebastian Haas <haas@ems-wuensche.com>

Applied to net-2.6

^ permalink raw reply

* Re: [PATCH 1/1] NET: cassini, fix lock imbalance
From: David Miller @ 2009-11-07  4:26 UTC (permalink / raw)
  To: jirislaby; +Cc: netdev, linux-kernel
In-Reply-To: <1257498869-4374-1-git-send-email-jirislaby@gmail.com>

From: Jiri Slaby <jirislaby@gmail.com>
Date: Fri,  6 Nov 2009 10:14:29 +0100

> Stanse found that one error path in cas_open omits to unlock pm_mutex.
> Fix that.
> 
> Signed-off-by: Jiri Slaby <jirislaby@gmail.com>

Applied to net-2.6

^ permalink raw reply

* Re: [PATCH 7/13] macsonic: fix crash on PowerBook 520
From: David Miller @ 2009-11-07  4:27 UTC (permalink / raw)
  To: fthain; +Cc: geert, tsbogend, netdev, linux-m68k
In-Reply-To: <alpine.OSX.2.00.0911031448060.483@silk.local>

From: Finn Thain <fthain@telegraphics.com.au>
Date: Wed, 4 Nov 2009 00:42:40 +1100 (EST)

> No-one seems to know where the PowerBook 500 series store their ethernet 
> MAC addresses. So, rather than crash, use a MAC address from the SONIC 
> CAM. Failing that, generate a random one.
> 
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>

Applied to net-2.6

^ permalink raw reply

* Re: [net-2.6 PATCH 1/3] ixgbe: Fix gso_max_size for 82599 when DCB is enabled
From: David Miller @ 2009-11-07  4:34 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: netdev, gospo, yi.zou, peter.p.waskiewicz.jr
In-Reply-To: <20091106225526.28063.83720.stgit@localhost.localdomain>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 06 Nov 2009 14:55:38 -0800

> From: Yi Zou <yi.zou@intel.com>
> 
> The 32k gso_max_size when DCB is enabled is for 82598 only, not for 82599.
> 
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

Applied.

^ permalink raw reply

* Re: [net-2.6 PATCH 2/3] ixgbe: Fix checking TFCS register for TXOFF status when DCB is enabled
From: David Miller @ 2009-11-07  4:34 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: netdev, gospo, yi.zou, peter.p.waskiewicz.jr
In-Reply-To: <20091106225559.28063.467.stgit@localhost.localdomain>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 06 Nov 2009 14:56:00 -0800

> From: Yi Zou <yi.zou@intel.com>
> 
> When DCB is enabled, the ixgbe_check_tx_hang() should check the corresponding
> TC's TXOFF in TFCS based on the TC that the tx ring belongs to. Adds a
> function to map from the tx_ring hw reg_idx to the correspodning TC and read
> TFCS accordingly.
> 
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

Applied.

^ permalink raw reply

* Re: [net-2.6 PATCH 3/3] ixgbe: fix traffic hangs on Tx with ioatdma loaded
From: David Miller @ 2009-11-07  4:34 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: netdev, gospo, donald.c.skidmore, peter.p.waskiewicz.jr
In-Reply-To: <20091106225620.28063.96209.stgit@localhost.localdomain>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 06 Nov 2009 14:56:20 -0800

> From: Don Skidmore <donald.c.skidmore@intel.com>
> 
> When ioatdma was loaded we we were unable to transmit traffic.  We weren't
> using the correct registers in ixgbe_update_tx_dca for 82599 systems.
> Likewise in ixgbe_configure_tx() we weren't disabling the arbiter before
> modifying MTQC.
> 
> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

Applied.

^ permalink raw reply

* Re: hisax: remove bad udelay call to fix build error on ARM
From: David Miller @ 2009-11-07  4:34 UTC (permalink / raw)
  To: tbm; +Cc: isdn, tilman, netdev
In-Reply-To: <20091107005234.GA1678@deprecation.cyrius.com>

From: Martin Michlmayr <tbm@cyrius.com>
Date: Sat, 7 Nov 2009 00:52:34 +0000

> The hisax ISDN driver fails to build on ARM with CONFIG_HISAX_ELSA:
> 
> | drivers/built-in.o: In function `modem_set_dial':
> | drivers/isdn/hisax/elsa_ser.c:535: undefined reference to `__bad_udelay'
> | drivers/isdn/hisax/elsa_ser.c:544: undefined reference to `__bad_udelay'
> | drivers/built-in.o: In function `modem_set_init':
> | drivers/isdn/hisax/elsa_ser.c:486: undefined reference to `__bad_udelay'
> | [...]
> 
> According to the comment in arch/arm/include/asm/delay.h, __bad_udelay
> is specifically designed on ARM to produce a build failure when udelay
> is called with a value > 2000.
> 
> Signed-off-by: Martin Michlmayr <tbm@cyrius.com>

Applied to net-2.6

^ permalink raw reply

* Re: [net-2.6 PATCH 1/2] qlge: Fix early exit from mbox cmd complete wait.
From: David Miller @ 2009-11-07  4:35 UTC (permalink / raw)
  To: ron.mercer; +Cc: netdev
In-Reply-To: <1257529498-17459-2-git-send-email-ron.mercer@qlogic.com>

From: Ron Mercer <ron.mercer@qlogic.com>
Date: Fri,  6 Nov 2009 09:44:57 -0800

> This line was accidentally left out of the previous commit #
> da03945140a035a2962f7f93e359085596f20499.
> 
> Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>

Applied, but please provide a text string of the commit's
header line when referencing a commit, don't just provide
the SHA1 ID as that can be not referencable in a -stable
backport.

Here is how I fixed up your commit message so that you can
see how to form it next time, thanks.

qlge: Fix early exit from mbox cmd complete wait.

This line was accidentally left out of the previous commit #
da03945140a035a2962f7f93e359085596f20499 ("qlge: Fix firmware mailbox
command timeout.").

Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

^ permalink raw reply

* Re: [net-2.6 PATCH 2/2] qlge: Set PCIe reset type for EEH to fundamental.
From: David Miller @ 2009-11-07  4:35 UTC (permalink / raw)
  To: ron.mercer; +Cc: netdev
In-Reply-To: <1257529498-17459-3-git-send-email-ron.mercer@qlogic.com>

From: Ron Mercer <ron.mercer@qlogic.com>
Date: Fri,  6 Nov 2009 09:44:58 -0800

> This device requires a fundamental reset when recovering from EEH.
> 
> Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>

Applied.

^ permalink raw reply

* Re: ipip: Fix handling of DF packets when pmtudisc is OFF
From: David Miller @ 2009-11-07  4:36 UTC (permalink / raw)
  To: herbert; +Cc: netdev
In-Reply-To: <20091106203741.GA19736@gondor.apana.org.au>

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 6 Nov 2009 15:37:41 -0500

> ipip: Fix handling of DF packets when pmtudisc is OFF
...
> This patch fixes the problem by performing PMTU discovery for
> all packets with the inner DF bit set, regardless of the PMTU
> discovery setting on the tunnel itself.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

The fun never ends :-)

Applied to net-2.6, thanks Herbert.

^ permalink raw reply

* Re: [RFC, PATCH 0/7] net, compat_ioctl: move handlers to net/socket.c
From: David Miller @ 2009-11-07  4:47 UTC (permalink / raw)
  To: arnd; +Cc: linux-kernel, hch, netdev
In-Reply-To: <1257530949-9695-1-git-send-email-arnd@arndb.de>

From: Arnd Bergmann <arnd@arndb.de>
Date: Fri,  6 Nov 2009 19:09:02 +0100

> This cleans up some of the socket ioctl handling by moving it
> from fs/compat_ioctl.c to net/socket.c. The code is still untested,
> so this is an RFC for now. If you're happy with it, I'll do some
> testing to see if everything still works.
> 
> This series is a prerequisite for cleaning up the rest of
> compat_ioctl.c, saving some 30kb of kernel memory in the end.
> 
> The first four patches are probably worthwhile independently,
> because they fix some bugs in compat_ioctl handling.
> There is some obvious conflict with the ATM patch I sent
> independently today. That one should probably be worked out
> first.

This looks great, all applied.  Please make the fixups recommended
to you in the feedback as followon patches.

Also, I added the following cure after your patch series:

net: compat: No need to define IFHWADDRLEN and IFNAMSIZ twice.

It's defined colloqually in linux/if.h and linux/compat.h
includes that.

Signed-off-by: David S. Miller <davem@davemloft.net>
---
 include/linux/compat.h |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/include/linux/compat.h b/include/linux/compat.h
index 8311d2e..224c7a8 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -166,8 +166,6 @@ struct compat_ifmap {
 };
 
 struct compat_ifreq {
-#define IFHWADDRLEN     6
-#define IFNAMSIZ        16
         union {
                 char    ifrn_name[IFNAMSIZ];            /* if name, e.g. "en0" */
         } ifr_ifrn;
-- 
1.6.5.2


^ 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