Netdev List
 help / color / mirror / Atom feed
* Re: PATCH: Network Device Naming mechanism and policy
From: Marco d'Itri @ 2009-11-06 22:35 UTC (permalink / raw)
  To: Matt Domsch
  Cc: Narendra_K, bryan, dannf, bhutchings, netdev, linux-hotplug,
	Jordan_Hargrave, Charles_Rose, Sandeep_K_Shandilya
In-Reply-To: <20091106220637.GB15533@mock.linuxdev.us.dell.com>

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

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.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* [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


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox