* [PATCHv2 7/7] X25: Update X25 interface documentation
From: Andrew Hendry @ 2010-04-19 23:30 UTC (permalink / raw)
To: netdev
Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com>
---
Documentation/networking/x25-iface.txt | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/networking/x25-iface.txt b/Documentation/networking/x25-iface.txt
index 975cc87..78f662e 100644
--- a/Documentation/networking/x25-iface.txt
+++ b/Documentation/networking/x25-iface.txt
@@ -20,23 +20,23 @@ the rest of the skbuff, if any more information does exist.
Packet Layer to Device Driver
-----------------------------
-First Byte = 0x00
+First Byte = 0x00 (X25_IFACE_DATA)
This indicates that the rest of the skbuff contains data to be transmitted
over the LAPB link. The LAPB link should already exist before any data is
passed down.
-First Byte = 0x01
+First Byte = 0x01 (X25_IFACE_CONNECT)
Establish the LAPB link. If the link is already established then the connect
confirmation message should be returned as soon as possible.
-First Byte = 0x02
+First Byte = 0x02 (X25_IFACE_DISCONNECT)
Terminate the LAPB link. If it is already disconnected then the disconnect
confirmation message should be returned as soon as possible.
-First Byte = 0x03
+First Byte = 0x03 (X25_IFACE_PARAMS)
LAPB parameters. To be defined.
@@ -44,22 +44,22 @@ LAPB parameters. To be defined.
Device Driver to Packet Layer
-----------------------------
-First Byte = 0x00
+First Byte = 0x00 (X25_IFACE_DATA)
This indicates that the rest of the skbuff contains data that has been
received over the LAPB link.
-First Byte = 0x01
+First Byte = 0x01 (X25_IFACE_CONNECT)
LAPB link has been established. The same message is used for both a LAPB
link connect_confirmation and a connect_indication.
-First Byte = 0x02
+First Byte = 0x02 (X25_IFACE_DISCONNECT)
LAPB link has been terminated. This same message is used for both a LAPB
link disconnect_confirmation and a disconnect_indication.
-First Byte = 0x03
+First Byte = 0x03 (X25_IFACE_PARAMS)
LAPB parameters. To be defined.
--
1.5.6.5
^ permalink raw reply related
* [PATCHv2 5/7] X25: Use identifiers for cyclades device to x25 interface
From: Andrew Hendry @ 2010-04-19 23:30 UTC (permalink / raw)
To: netdev, acme
Change magic numbers to identifiers for X25 interface.
Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com>
---
drivers/net/wan/cycx_x25.c | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wan/cycx_x25.c b/drivers/net/wan/cycx_x25.c
index cd8cb95..cf9e15f 100644
--- a/drivers/net/wan/cycx_x25.c
+++ b/drivers/net/wan/cycx_x25.c
@@ -634,11 +634,12 @@ static netdev_tx_t cycx_netdevice_hard_start_xmit(struct sk_buff *skb,
}
} else { /* chan->protocol == ETH_P_X25 */
switch (skb->data[0]) {
- case 0: break;
- case 1: /* Connect request */
+ case X25_IFACE_DATA:
+ break;
+ case X25_IFACE_CONNECT:
cycx_x25_chan_connect(dev);
goto free_packet;
- case 2: /* Disconnect request */
+ case X25_IFACE_DISCONNECT:
cycx_x25_chan_disconnect(dev);
goto free_packet;
default:
@@ -1406,7 +1407,8 @@ static void cycx_x25_set_chan_state(struct net_device *dev, u8 state)
reset_timer(dev);
if (chan->protocol == ETH_P_X25)
- cycx_x25_chan_send_event(dev, 1);
+ cycx_x25_chan_send_event(dev,
+ X25_IFACE_CONNECT);
break;
case WAN_CONNECTING:
@@ -1424,7 +1426,8 @@ static void cycx_x25_set_chan_state(struct net_device *dev, u8 state)
}
if (chan->protocol == ETH_P_X25)
- cycx_x25_chan_send_event(dev, 2);
+ cycx_x25_chan_send_event(dev,
+ X25_IFACE_DISCONNECT);
netif_wake_queue(dev);
break;
--
1.5.6.5
^ permalink raw reply related
* [PATCHv2 4/7] X25: Use identifiers for lapbether device to x25 interface
From: Andrew Hendry @ 2010-04-19 23:30 UTC (permalink / raw)
To: netdev
Change magic numbers to identifiers for X25 interface.
Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com>
---
drivers/net/wan/lapbether.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wan/lapbether.c b/drivers/net/wan/lapbether.c
index 98e2f99..4d4dc38 100644
--- a/drivers/net/wan/lapbether.c
+++ b/drivers/net/wan/lapbether.c
@@ -139,7 +139,7 @@ static int lapbeth_data_indication(struct net_device *dev, struct sk_buff *skb)
return NET_RX_DROP;
ptr = skb->data;
- *ptr = 0x00;
+ *ptr = X25_IFACE_DATA;
skb->protocol = x25_type_trans(skb, dev);
return netif_rx(skb);
@@ -161,14 +161,14 @@ static netdev_tx_t lapbeth_xmit(struct sk_buff *skb,
goto drop;
switch (skb->data[0]) {
- case 0x00:
+ case X25_IFACE_DATA:
break;
- case 0x01:
+ case X25_IFACE_CONNECT:
if ((err = lapb_connect_request(dev)) != LAPB_OK)
printk(KERN_ERR "lapbeth: lapb_connect_request "
"error: %d\n", err);
goto drop;
- case 0x02:
+ case X25_IFACE_DISCONNECT:
if ((err = lapb_disconnect_request(dev)) != LAPB_OK)
printk(KERN_ERR "lapbeth: lapb_disconnect_request "
"err: %d\n", err);
@@ -225,7 +225,7 @@ static void lapbeth_connected(struct net_device *dev, int reason)
}
ptr = skb_put(skb, 1);
- *ptr = 0x01;
+ *ptr = X25_IFACE_CONNECT;
skb->protocol = x25_type_trans(skb, dev);
netif_rx(skb);
@@ -242,7 +242,7 @@ static void lapbeth_disconnected(struct net_device *dev, int reason)
}
ptr = skb_put(skb, 1);
- *ptr = 0x02;
+ *ptr = X25_IFACE_DISCONNECT;
skb->protocol = x25_type_trans(skb, dev);
netif_rx(skb);
--
1.5.6.5
^ permalink raw reply related
* [PATCHv2 6/7] X25: Use identifiers for hdlc x25 device to x25 interface
From: Andrew Hendry @ 2010-04-19 23:30 UTC (permalink / raw)
To: netdev, khc
Change magic numbers to identifiers for X25 interface.
Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com>
Acked-by: Krzysztof Halasa <khc@pm.waw.pl>
---
drivers/net/wan/hdlc_x25.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wan/hdlc_x25.c b/drivers/net/wan/hdlc_x25.c
index c7adbb7..70527e5 100644
--- a/drivers/net/wan/hdlc_x25.c
+++ b/drivers/net/wan/hdlc_x25.c
@@ -49,14 +49,14 @@ static void x25_connect_disconnect(struct net_device *dev, int reason, int code)
static void x25_connected(struct net_device *dev, int reason)
{
- x25_connect_disconnect(dev, reason, 1);
+ x25_connect_disconnect(dev, reason, X25_IFACE_CONNECT);
}
static void x25_disconnected(struct net_device *dev, int reason)
{
- x25_connect_disconnect(dev, reason, 2);
+ x25_connect_disconnect(dev, reason, X25_IFACE_DISCONNECT);
}
@@ -71,7 +71,7 @@ static int x25_data_indication(struct net_device *dev, struct sk_buff *skb)
return NET_RX_DROP;
ptr = skb->data;
- *ptr = 0;
+ *ptr = X25_IFACE_DATA;
skb->protocol = x25_type_trans(skb, dev);
return netif_rx(skb);
@@ -94,13 +94,13 @@ static netdev_tx_t x25_xmit(struct sk_buff *skb, struct net_device *dev)
/* X.25 to LAPB */
switch (skb->data[0]) {
- case 0: /* Data to be transmitted */
+ case X25_IFACE_DATA: /* Data to be transmitted */
skb_pull(skb, 1);
if ((result = lapb_data_request(dev, skb)) != LAPB_OK)
dev_kfree_skb(skb);
return NETDEV_TX_OK;
- case 1:
+ case X25_IFACE_CONNECT:
if ((result = lapb_connect_request(dev))!= LAPB_OK) {
if (result == LAPB_CONNECTED)
/* Send connect confirm. msg to level 3 */
@@ -112,7 +112,7 @@ static netdev_tx_t x25_xmit(struct sk_buff *skb, struct net_device *dev)
}
break;
- case 2:
+ case X25_IFACE_DISCONNECT:
if ((result = lapb_disconnect_request(dev)) != LAPB_OK) {
if (result == LAPB_NOTCONNECTED)
/* Send disconnect confirm. msg to level 3 */
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH v5] rfs: Receive Flow Steering
From: Changli Gao @ 2010-04-19 23:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, therbert, netdev
In-Reply-To: <1271709121.3845.94.camel@edumazet-laptop>
On Tue, Apr 20, 2010 at 4:32 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> Hmm, this was not a formal patch, just an information.
>
> Problem is if hardware provides rxhash, will it be "consistent" too ?
>
>
Does this problem has relationship with your patch? No. If the rxhash
isn't provided by hardware, we can get more throughput from you patch,
and on the other side, we don't lose anything but potential more hash
collision.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH net-next-2.6] rps: shortcut net_rps_action()
From: Changli Gao @ 2010-04-19 23:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Tom Herbert, netdev
In-Reply-To: <1271689653.3845.73.camel@edumazet-laptop>
On Mon, Apr 19, 2010 at 11:07 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> +
> + /* Send pending IPI's to kick RPS processing on remote cpus. */
> + while (remqueue) {
> + struct softnet_data *next = remqueue->rps_ipi_next;
> + if (cpu_online(remqueue->cpu))
> + __smp_call_function_single(remqueue->cpu,
> + &remqueue->csd, 0);
> + remqueue = next;
> + }
It seems you prefetch rps_ipi_next. I think it isn't necessary, as the
list should be short. If you insist on this, is the macro prefetch()
better?
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH net-next-2.6] rps: shortcut net_rps_action()
From: Changli Gao @ 2010-04-20 0:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Tom Herbert, netdev
In-Reply-To: <n2y412e6f7f1004191656qd53a8d77occ407ac288c53bbc@mail.gmail.com>
On Tue, Apr 20, 2010 at 7:56 AM, Changli Gao <xiaosuo@gmail.com> wrote:
>
> It seems you prefetch rps_ipi_next. I think it isn't necessary, as the
> list should be short. If you insist on this, is the macro prefetch()
> better?
Oh, I read the code again and got the answer. After the IPI is sent,
this softnet will be queued by the other CPUs. We prefetch the pointer
rps_ipi_next to avoid this race condition.
Sorry for noise :)
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: 2.6.34-rc5: Reported regressions from 2.6.33
From: Andrew Morton @ 2010-04-20 0:57 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Maciej Rutecki, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <deuQKFRcc0B.A.3EG.BRSzLB@tosh>
On Tue, 20 Apr 2010 05:15:57 +0200 (CEST) "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15812
> Subject : utsname.domainname not set in x86_32 processes (causing "YPBINDPROC_DOMAIN: domain not bound" errors)
> Submitter : <adi@hexapodia.org>
> Date : 2010-04-19 21:28 (1 days old)
I merged hch's fix for this twelve seconds ago.
^ permalink raw reply
* [PATCH] cxgb3: fix linkup issue
From: Hiroshi Shimamoto @ 2010-04-20 1:32 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel@vger.kernel.org
From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
I encountered an issue that not to link up on cxgb3 fabric.
I bisected and found that this regression was introduced by
0f07c4ee8c800923ae7918c231532a9256233eed.
Correct to pass phy_addr to cphy_init() at t3_xaui_direct_phy_prep().
Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
---
drivers/net/cxgb3/ael1002.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb3/ael1002.c b/drivers/net/cxgb3/ael1002.c
index 5248f9e..35cd367 100644
--- a/drivers/net/cxgb3/ael1002.c
+++ b/drivers/net/cxgb3/ael1002.c
@@ -934,7 +934,7 @@ static struct cphy_ops xaui_direct_ops = {
int t3_xaui_direct_phy_prep(struct cphy *phy, struct adapter *adapter,
int phy_addr, const struct mdio_ops *mdio_ops)
{
- cphy_init(phy, adapter, MDIO_PRTAD_NONE, &xaui_direct_ops, mdio_ops,
+ cphy_init(phy, adapter, phy_addr, &xaui_direct_ops, mdio_ops,
SUPPORTED_10000baseT_Full | SUPPORTED_AUI | SUPPORTED_TP,
"10GBASE-CX4");
return 0;
--
1.6.3.3
^ permalink raw reply related
* RE: [RFC][PATCH v2 0/3] Provide a zero-copy method on KVM virtio-net.
From: Xin, Xiaohui @ 2010-04-20 2:21 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mingo@elte.hu,
jdike@linux.intel.com, davem@davemloft.net
In-Reply-To: <20100419102118.GA16198@redhat.com>
Michael,
>>>>>> What we have not done yet:
>>>>>> packet split support
>>>>>>
>>>>>What does this mean, exactly?
>>>> We can support 1500MTU, but for jumbo frame, since vhost driver before don't
>>>>support mergeable buffer, we cannot try it for multiple sg.
>>>>
>>>I do not see why, vhost currently supports 64K buffers with indirect
>>>descriptors.
>>>
>> The receive_skb() in guest virtio-net driver will merge the multiple sg to skb frags, how >>can indirect descriptors to that?
>See add_recvbuf_big.
I don't mean this, it's for buffer submission. I mean when packet is received, in receive_buf(), mergeable buffer knows which pages received can be hooked in skb frags, it's receive_mergeable() which do this.
When a NIC driver supports packet split mode, then each ring descriptor contains a skb and a page. When packet is received, if the status is not EOP, then hook the page of the next descriptor to the prev skb. We don't how many frags belongs to one skb. So when guest submit buffers, it should submit multiple pages, and when receive, the guest should know which pages are belongs to one skb and hook them together. I think receive_mergeable() can do this, but I don't see how big->packets handle this. May I miss something here?
Thanks
Xiaohui
^ permalink raw reply
* 2.6.34-rc5: Reported regressions from 2.6.33
From: Rafael J. Wysocki @ 2010-04-20 3:15 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions from 2.6.33,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved regressions from 2.6.33, please let us
know either and we'll add them to the list. Also, please let us know
if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-04-20 64 35 34
2010-04-07 48 35 33
2010-03-21 15 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15812
Subject : utsname.domainname not set in x86_32 processes (causing "YPBINDPROC_DOMAIN: domain not bound" errors)
Submitter : <adi-3HqRAUrWAWyGglJvpFV4uA@public.gmane.org>
Date : 2010-04-19 21:28 (1 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15805
Subject : reiserfs locking
Submitter : Alexander Beregalov <a.beregalov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-04-15 21:02 (5 days old)
Message-ID : <t2ka4423d671004151402n7b2dc425mdc9c6bb9640d63fb-JsoAwUIsXov1KXRcyAk9cg@public.gmane.orgl.com>
References : http://marc.info/?l=linux-kernel&m=127136535323933&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15796
Subject : [REGRESSION bisected] Sound goes too fast due to commit 7b3a177b0
Submitter : Éric Piel <Eric.Piel-VkQ1JFuSMpfAbQlEx87xDw@public.gmane.org>
Date : 2010-04-13 21:54 (7 days old)
First-Bad-Commit: http://kernel.org/git/linus/7b3a177b0d4f92b3431b8dca777313a07533a710
Message-ID : <4BC4E812.6050602-VkQ1JFuSMpfAbQlEx87xDw@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127119569009790&w=2
Handled-By : Takashi Iwai <tiwai-l3A5Bk7waGM@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15795
Subject : 2.6.34-rc4 : OOPS in unmap_vma
Submitter : Parag Warudkar <parag.lkml-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-04-14 (6 days old)
Message-ID : <alpine.DEB.2.00.1004132147260.1881@parag-laptop>
References : http://marc.info/?l=linux-kernel&m=127121006625429&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15790
Subject : Meta-Bug: Regressions
Submitter : Florian Mickler <fmickler-Mmb7MZpHnFY@public.gmane.org>
Date : 2010-04-15 18:21 (5 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15788
Subject : external usb sound card doesn't work after resume
Submitter : François Valenduc <francois.valenduc-bmtTS95sd5BUM80lpFwj4w@public.gmane.org>
Date : 2010-04-15 10:16 (5 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15774
Subject : 2.6.34-rc3: eth0 (8139too): transmit queue 0 timed out
Submitter : Németh Márton <nm127-Y8qEzhMunLyT9ig0jae3mg@public.gmane.org>
Date : 2010-04-10 12:33 (10 days old)
Message-ID : <4BC07022.6000708-Y8qEzhMunLyT9ig0jae3mg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127090287021976&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15768
Subject : Incorrectly calculated free blocks result in ENOSPC from writepage
Submitter : Dmitry Monakhov <dmonakhov-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Date : 2010-04-12 11:24 (8 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15744
Subject : [2.6.34-rc1 REGRESSION] ahci 0000:00:1f.2: controller reset failed (0xffffffff)
Submitter : Andy Isaacson <adi-3HqRAUrWAWyGglJvpFV4uA@public.gmane.org>
Date : 2010-04-06 22:54 (14 days old)
Message-ID : <<4BC51312.6080302-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org></desc>>
References : http://marc.info/?l=linux-kernel&m=127059449031511&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15730
Subject : Ugly rmap NULL ptr deref oopsie on hibernate (was Linux 2.6.34-rc3)
Submitter : Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>
Date : 2010-04-02 17:59 (18 days old)
Message-ID : <20100402175937.GA19690-f9CnO7I+Q6zU6FkGJEIX5A@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127023173329741&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15729
Subject : BUG: physmap modprobe & rmmod
Submitter : Randy Dunlap <randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date : 2010-04-02 20:40 (18 days old)
Message-ID : <20100402134058.c4682716.randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127024096210230&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15719
Subject : virtio_net causing kernel BUG when running under VirtualBox
Submitter : Thomas Müller <thomas-5bHTHlrcoh6zQB+pC5nmwQ@public.gmane.org>
Date : 2010-03-27 14:32 (24 days old)
First-Bad-Commit: http://kernel.org/git/linus/9ab86bbcf8be755256f0a5e994e0b38af6b4d399
Message-ID : <4BAE1707.2050803-5bHTHlrcoh6zQB+pC5nmwQ@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=126970039227740&w=4
Handled-By : Shirley Ma <mashirle-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15717
Subject : bluetooth oops
Submitter : Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
Date : 2010-03-14 20:14 (37 days old)
Message-ID : <20100314201434.GE22059-I/5MKhXcvmPrBKCeMvbIDA@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=126859771528426&w=4
Handled-By : Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15713
Subject : hackbench regression due to commit 9dfc6e68bfe6e
Submitter : Alex Shi <alex.shi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date : 2010-03-25 8:40 (26 days old)
First-Bad-Commit: http://kernel.org/git/linus/9dfc6e68bfe6ee452efb1a4e9ca26a9007f2b864
Message-ID : <1269506457.4513.141.camel-c8rhgrCDLIED0+JXs3kMbRL4W9x8LtSr@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=126950632920682&w=4
Handled-By : Christoph Lameter <cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Pekka Enberg <penberg-bbCR+/B0CizivPeTLB3BmA@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15712
Subject : [regression] 2.6.34-rc1 to -rc3 on zaurus: no longer boots
Submitter : Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
Date : 2010-04-01 6:06 (19 days old)
Message-ID : <20100401060624.GA1329-+ZI9xUNit7I@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127010200817402&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15711
Subject : 2.6.34-rc3, BUG at mm/slab.c:2989
Submitter : Heinz Diehl <htd-HjJ2MNWy62to6+H+lsi3Gti2O/JbrIOy@public.gmane.org>
Date : 2010-04-01 17:52 (19 days old)
Message-ID : <20100401175225.GA6581-HjJ2MNWy62to6+H+lsi3Gti2O/JbrIOy@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127014437406250&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15704
Subject : [r8169] WARNING: at net/sched/sch_generic.c
Submitter : Sergey Senozhatsky <sergey.senozhatsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-03-31 10:21 (20 days old)
Message-ID : <<20100331102142.GA3294-dY8u8AhHFaWtd10JCjopabkcH5ONE+aC@public.gmane.org>>
References : http://marc.info/?l=linux-kernel&m=127003090406108&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15698
Subject : Freeze on power-off / suspend to ram
Submitter : arond <hector1987-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-04-05 13:53 (15 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15673
Subject : 2.6.34-rc2: "ima_dec_counts: open/free imbalance"?
Submitter : Thomas Meyer <thomas-VsYtu1Qij5c@public.gmane.org>
Date : 2010-03-28 11:31 (23 days old)
Message-ID : <1269775909.5301.4.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=126977593326800&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15672
Subject : KVM bug, git bisected
Submitter : Kent Overstreet <kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-03-27 12:43 (24 days old)
First-Bad-Commit: http://kernel.org/git/linus/5beb49305251e5669852ed541e8e2f2f7696c53e
Message-ID : <4BADFD74.8060904-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=126969385121711&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15671
Subject : intel graphic card hanging (Hangcheck timer elapsed... GPU hung)
Submitter : Norbert Preining <preining-DX+603jRYB8@public.gmane.org>
Date : 2010-03-27 16:11 (24 days old)
Message-ID : <20100327161104.GA12043-DqSSrKF0TaySnEC3TeqHn5dqbFPxfnh/@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=126970883105262&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15669
Subject : INFO: suspicious rcu_dereference_check()
Submitter : Zdenek Kabelac <zdenek.kabelac-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-03-08 1:26 (43 days old)
Message-ID : <c4e36d111003250348q678eb2e6w4f3e8133e7fd6e58-JsoAwUIsXounXO2b/Sh1tA@public.gmane.orgom>
References : http://marc.info/?l=linux-kernel&m=126801163107713&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15668
Subject : start_kernel(): bug: interrupts were enabled early
Submitter : Rabin Vincent <rabin-66gdRtMMWGc@public.gmane.org>
Date : 2010-03-25 19:53 (26 days old)
First-Bad-Commit: http://kernel.org/git/linus/773e3eb7b81e5ba13b5155dfb3bb75b8ce37f8f9
Message-ID : <20100325194100.GA2364@debian>
References : http://marc.info/?l=linux-kernel&m=126954607216519&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15664
Subject : Graphics hang and kernel backtrace when starting Azureus with Compiz enabled
Submitter : Alex Villacis Lasso <avillaci-x0m+Mc+nT7uljOmnV8AmnkElSqmLX1BE@public.gmane.org>
Date : 2010-04-01 01:09 (19 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15661
Subject : PROBLEM: crash on halt with 2.6.34-0.16.rc2.git0.fc14.x86_64
Submitter : Jon Masters <jonathan-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org>
Date : 2010-03-26 15:29 (25 days old)
Message-ID : <<1269617372.3779.234.camel@localhost>>
References : http://marc.info/?l=linux-kernel&m=126961739803949&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15659
Subject : [Regresion] [2.6.34-rc1] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
Submitter : Maciej Rutecki <maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-03-25 20:04 (26 days old)
Message-ID : <201003252104.24965.maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=126954749618319&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15625
Subject : BUG: 2.6.34-rc1, RIP is (null)
Submitter : Randy Dunlap <randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date : 2010-03-18 22:22 (33 days old)
Message-ID : <4BA2A7A9.4080503-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=126895098217351&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15611
Subject : Failure with the 2.6.34-rc1 kernel
Submitter : Rupjyoti Sarmah <rsarmah-6mNVq6Owofk@public.gmane.org>
Date : 2010-03-16 15:45 (35 days old)
Message-ID : <AC311A8E81420D4EBC1F26E6479848FE065B7D3D-oUPhqDSr77q+n3Z1v9ZxkQ@public.gmane.org.amcc.com>
References : http://marc.info/?l=linux-kernel&m=126875435718396&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15610
Subject : fsck leads to swapper - BUG: unable to handle kernel NULL pointer dereference & panic
Submitter : Ozgur Yuksel <ozgur.yuksel-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date : 2010-03-22 15:59 (29 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15601
Subject : [BUG] SLOB breaks Crypto
Submitter : michael-dev-1SGGS//iJ+Y38rf8aCqVIw@public.gmane.org
Date : 2010-03-15 13:39 (36 days old)
Message-ID : <4B9E38AF.70309-1SGGS//iJ+Y38rf8aCqVIw@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=126866044724539&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15590
Subject : 2.6.34-rc1: regression: ^Z no longer stops sound
Submitter : Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
Date : 2010-03-14 7:58 (37 days old)
Message-ID : <20100314075831.GA13457-I/5MKhXcvmPrBKCeMvbIDA@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=126855353122623&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15589
Subject : 2.6.34-rc1: Badness at fs/proc/generic.c:316
Submitter : Christian Kujau <lists-AanptEQQ3TL9uQeqpI+JUg@public.gmane.org>
Date : 2010-03-13 23:53 (38 days old)
Message-ID : <alpine.DEB.2.01.1003131544340.5493-uKsf7x9sgtqQ/Pez2Lbyp4QuADTiUCJX@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=126852442903680&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15553
Subject : Screen backlight doesn't come back on after lid was closed (GM45)
Submitter : <bugs-fbdoOxCsnNob1SvskN2V4Q@public.gmane.org>
Date : 2010-03-17 14:35 (34 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15551
Subject : WARNING: at net/mac80211/work.c:811 ieee80211_work_work+0x7f/0xde8 [mac80211]()
Submitter : Alex Zhavnerchik <alex.vizor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-03-16 22:03 (35 days old)
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15505
Subject : No more b43 wireless interface since 2.6.34-rc1
Submitter : Christian Casteyde <casteyde.christian-GANU6spQydw@public.gmane.org>
Date : 2010-03-10 06:59 (41 days old)
Handled-By : Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Patch : https://bugzilla.kernel.org/show_bug.cgi?id=15505#c11
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.33,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=15310
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* [PATCH] rps: send IPIs ASAP
From: Changli Gao @ 2010-04-20 4:08 UTC (permalink / raw)
To: David S. Miller; +Cc: Tom Herbert, Eric Dumazet, netdev, Changli Gao
rps: send IPIs ASAP
In order to reduce latency, we'd better send IPIs ASAP to schedule the
corresponding NAPIs.
For NAPI drivers, we send IPIs immediately, and for the others, we defer them
to NET_RX_SOFTIRQ. In this patch, we move net_rps_action() to the beginning of
net_rx_action() to emulate a softirq with the higher priority than
NET_RX_SOFTIRQ.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
net/core/dev.c | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 05a2b29..d8fca21 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2363,6 +2363,10 @@ static int enqueue_to_backlog(struct sk_buff *skb, int cpu,
{
struct softnet_data *queue;
unsigned long flags;
+#ifdef CONFIG_RPS
+ bool ni = !in_irq();
+ bool ipi = false;
+#endif
queue = &per_cpu(softnet_data, cpu);
@@ -2380,6 +2384,10 @@ enqueue:
#endif
rps_unlock(queue);
local_irq_restore(flags);
+#ifdef CONFIG_RPS
+ if (ipi)
+ __smp_call_function_single(cpu, &queue->csd, 0);
+#endif
return NET_RX_SUCCESS;
}
@@ -2389,6 +2397,11 @@ enqueue:
if (cpu != smp_processor_id()) {
struct softnet_data *myqueue;
+ if (ni) {
+ ipi = true;
+ goto enqueue;
+ }
+
myqueue = &__get_cpu_var(softnet_data);
queue->rps_ipi_next = myqueue->rps_ipi_list;
myqueue->rps_ipi_list = queue;
@@ -3337,6 +3350,7 @@ static void net_rps_action(void)
struct softnet_data *locqueue = &__get_cpu_var(softnet_data);
struct softnet_data *remqueue = locqueue->rps_ipi_list;
+ local_irq_disable();
if (remqueue) {
locqueue->rps_ipi_list = NULL;
@@ -3350,9 +3364,10 @@ static void net_rps_action(void)
&remqueue->csd, 0);
remqueue = next;
}
- } else
-#endif
+ } else {
local_irq_enable();
+ }
+#endif
}
static void net_rx_action(struct softirq_action *h)
@@ -3362,6 +3377,8 @@ static void net_rx_action(struct softirq_action *h)
int budget = netdev_budget;
void *have;
+ net_rps_action();
+
local_irq_disable();
while (!list_empty(list)) {
@@ -3423,7 +3440,7 @@ static void net_rx_action(struct softirq_action *h)
netpoll_poll_unlock(have);
}
out:
- net_rps_action();
+ local_irq_enable();
#ifdef CONFIG_NET_DMA
/*
^ permalink raw reply related
* Re: 2.6.34-rc5: Reported regressions from 2.6.33
From: Rafael J. Wysocki @ 2010-04-20 4:13 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux Kernel Mailing List, Maciej Rutecki, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <20100419205723.8724338c.akpm@linux-foundation.org>
On Tuesday 20 April 2010, Andrew Morton wrote:
> On Tue, 20 Apr 2010 05:15:57 +0200 (CEST) "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15812
> > Subject : utsname.domainname not set in x86_32 processes (causing "YPBINDPROC_DOMAIN: domain not bound" errors)
> > Submitter : <adi@hexapodia.org>
> > Date : 2010-04-19 21:28 (1 days old)
>
> I merged hch's fix for this twelve seconds ago.
I updated the entry.
^ permalink raw reply
* Re: [PATCH] rdma/cm: Randomize local port allocation.
From: Cong Wang @ 2010-04-20 4:34 UTC (permalink / raw)
To: David Miller
Cc: penguin-kernel, sean.hefty, opurdila, eric.dumazet, netdev,
nhorman, ebiederm, linux-kernel, rolandd, linux-rdma
In-Reply-To: <20100416.133001.262206466.davem@davemloft.net>
David Miller wrote:
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Fri, 16 Apr 2010 22:54:22 +0900
>
>> Cong Wang wrote:
>>> Sean Hefty wrote:
>>>> I like this version, thanks! I'm not sure which tree to merge it through.
>>>> Are you needing this for 2.6.34, or is 2.6.35 okay?
>>>>
>>> As soon as possible, so 2.6.34. :)
>>>
>> Cong, merge window for 2.6.34 was already closed.
>> You need to make your patchset towards 2.6.35 (using net-next-2.6 tree)
>> rather than 2.6.34 (using linux-2.6 tree). Therefore, this patch being
>> queued for 2.6.35 (through net-next-2.6 tree) should be okay for you.
>
> I don't take RDMA patches into net-next-2.6, the less I touch this
> stack avoiding stuff the better and Roland has been taking this stuff
> into his own tree for some time now.
I left for a few days.
Ok, so I will wait for this to be merged.
Thanks, David and Tetsuo!
^ permalink raw reply
* Re: [PATCH] gianfar: Wait for both RX and TX to stop
From: Kumar Gala @ 2010-04-20 4:43 UTC (permalink / raw)
To: Timur Tabi; +Cc: Andy Fleming, davem, netdev
In-Reply-To: <m2ged82fe3e1004191408p53f19073x106ef56677c8a5df@mail.gmail.com>
On Apr 19, 2010, at 4:08 PM, Timur Tabi wrote:
> On Sun, Apr 18, 2010 at 6:13 PM, Andy Fleming <afleming@freescale.com> wrote:
>
>> - while (!(gfar_read(®s->ievent) &
>> - (IEVENT_GRSC | IEVENT_GTSC)))
>> + while ((gfar_read(®s->ievent) &
>> + (IEVENT_GRSC | IEVENT_GTSC)) !=
>> + (IEVENT_GRSC | IEVENT_GTSC))
>> cpu_relax();
>
> How about using spin_event_timeout()? It streamlines this process and
> includes a timeout.
>
> The U-Boot version of this code doesn't have a timeout either, but
> spin_event_timeout() is not available in U-Boot.
spin_event_timeout doesn't make sense for this. The patch is fine.
- k
^ permalink raw reply
* Re: [PATCH] gianfar: Wait for both RX and TX to stop
From: Kumar Gala @ 2010-04-20 4:44 UTC (permalink / raw)
To: David Miller; +Cc: Netdev, Andy Fleming
In-Reply-To: <1271632401-2472-1-git-send-email-afleming@freescale.com>
On Apr 18, 2010, at 6:13 PM, Andy Fleming wrote:
> When gracefully stopping the controller, the driver was continuing if
> *either* RX or TX had stopped. We need to wait for both, or the
> controller could get into an invalid state.
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> ---
> drivers/net/gianfar.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
Acked-by: Kumar Gala <galak@kernel.crashing.org>
(please pick this up for 2.6.34, fixes an annoying bug).
- k
>
> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
> index 032073d..6038397 100644
> --- a/drivers/net/gianfar.c
> +++ b/drivers/net/gianfar.c
> @@ -1571,8 +1571,9 @@ static void gfar_halt_nodisable(struct net_device *dev)
> tempval |= (DMACTRL_GRS | DMACTRL_GTS);
> gfar_write(®s->dmactrl, tempval);
>
> - while (!(gfar_read(®s->ievent) &
> - (IEVENT_GRSC | IEVENT_GTSC)))
> + while ((gfar_read(®s->ievent) &
> + (IEVENT_GRSC | IEVENT_GTSC)) !=
> + (IEVENT_GRSC | IEVENT_GTSC))
> cpu_relax();
> }
> }
> --
> 1.6.5.2.g6ff9a
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] rps: send IPIs ASAP
From: Tom Herbert @ 2010-04-20 5:15 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, Eric Dumazet, netdev
In-Reply-To: <1271736519-2991-1-git-send-email-xiaosuo@gmail.com>
On Mon, Apr 19, 2010 at 9:08 PM, Changli Gao <xiaosuo@gmail.com> wrote:
> rps: send IPIs ASAP
>
> In order to reduce latency, we'd better send IPIs ASAP to schedule the
> corresponding NAPIs.
>
A design point of RPS is that we generate at most one IPI per CPU per
device interrupt, which at least offers some predictable coalescing.
With your changes, we would get at most one IPI per packet-- that
could represent a lot more of them. Did you test this to see what the
impact is in this regard?
> For NAPI drivers, we send IPIs immediately, and for the others, we defer them
> to NET_RX_SOFTIRQ. In this patch, we move net_rps_action() to the beginning of
> net_rx_action() to emulate a softirq with the higher priority than
> NET_RX_SOFTIRQ.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> ----
> net/core/dev.c | 23 ++++++++++++++++++++---
> 1 file changed, 20 insertions(+), 3 deletions(-)
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 05a2b29..d8fca21 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2363,6 +2363,10 @@ static int enqueue_to_backlog(struct sk_buff *skb, int cpu,
> {
> struct softnet_data *queue;
> unsigned long flags;
> +#ifdef CONFIG_RPS
> + bool ni = !in_irq();
> + bool ipi = false;
> +#endif
>
> queue = &per_cpu(softnet_data, cpu);
>
> @@ -2380,6 +2384,10 @@ enqueue:
> #endif
> rps_unlock(queue);
> local_irq_restore(flags);
> +#ifdef CONFIG_RPS
> + if (ipi)
> + __smp_call_function_single(cpu, &queue->csd, 0);
> +#endif
> return NET_RX_SUCCESS;
> }
>
> @@ -2389,6 +2397,11 @@ enqueue:
> if (cpu != smp_processor_id()) {
> struct softnet_data *myqueue;
>
> + if (ni) {
> + ipi = true;
> + goto enqueue;
> + }
> +
> myqueue = &__get_cpu_var(softnet_data);
> queue->rps_ipi_next = myqueue->rps_ipi_list;
> myqueue->rps_ipi_list = queue;
> @@ -3337,6 +3350,7 @@ static void net_rps_action(void)
> struct softnet_data *locqueue = &__get_cpu_var(softnet_data);
> struct softnet_data *remqueue = locqueue->rps_ipi_list;
>
> + local_irq_disable();
> if (remqueue) {
> locqueue->rps_ipi_list = NULL;
>
> @@ -3350,9 +3364,10 @@ static void net_rps_action(void)
> &remqueue->csd, 0);
> remqueue = next;
> }
> - } else
> -#endif
> + } else {
> local_irq_enable();
> + }
> +#endif
> }
>
> static void net_rx_action(struct softirq_action *h)
> @@ -3362,6 +3377,8 @@ static void net_rx_action(struct softirq_action *h)
> int budget = netdev_budget;
> void *have;
>
> + net_rps_action();
> +
> local_irq_disable();
>
> while (!list_empty(list)) {
> @@ -3423,7 +3440,7 @@ static void net_rx_action(struct softirq_action *h)
> netpoll_poll_unlock(have);
> }
> out:
> - net_rps_action();
> + local_irq_enable();
>
> #ifdef CONFIG_NET_DMA
> /*
>
^ permalink raw reply
* Re: [PATCH] rps: send IPIs ASAP
From: David Miller @ 2010-04-20 5:39 UTC (permalink / raw)
To: therbert; +Cc: xiaosuo, eric.dumazet, netdev
In-Reply-To: <g2y65634d661004192215oc06d9c43xb2a7c7d946149cf5@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Mon, 19 Apr 2010 22:15:58 -0700
> Did you test this to see what the impact is in this regard?
Changli it would help immensely if you posted performance
test results along with your changes.
I can see quite obviously that this change will completely undo the
intentional batching of IPIs done by RPS. IPIs are expensive and we
should batch things as much as possible here.
^ permalink raw reply
* Re: [PATCH] rps: send IPIs ASAP
From: Eric Dumazet @ 2010-04-20 5:45 UTC (permalink / raw)
To: Tom Herbert; +Cc: Changli Gao, David S. Miller, netdev
In-Reply-To: <g2y65634d661004192215oc06d9c43xb2a7c7d946149cf5@mail.gmail.com>
Le lundi 19 avril 2010 à 22:15 -0700, Tom Herbert a écrit :
> On Mon, Apr 19, 2010 at 9:08 PM, Changli Gao <xiaosuo@gmail.com> wrote:
> > rps: send IPIs ASAP
> >
> > In order to reduce latency, we'd better send IPIs ASAP to schedule the
> > corresponding NAPIs.
> >
> A design point of RPS is that we generate at most one IPI per CPU per
> device interrupt, which at least offers some predictable coalescing.
> With your changes, we would get at most one IPI per packet-- that
> could represent a lot more of them. Did you test this to see what the
> impact is in this regard?
>
I agree with you Tom. Coalescing IPI is probably better.
If the receiver CPU got a single packet in its RX handling, latency will
be the same anyway.
If the receiver CPU got many packets, chance is high we are in a stress
situation, and coalescing is a win in this case.
I am currently testing a patch to call net_rps_action() at the beginning
of process_backlog() (if we have a non null ipi_rps_list pointer)
Will post a patch with bench results
^ permalink raw reply
* Re: [PATCH net-next-2.6] rps: shortcut net_rps_action()
From: Eric Dumazet @ 2010-04-20 5:55 UTC (permalink / raw)
To: Changli Gao; +Cc: David Miller, Tom Herbert, netdev
In-Reply-To: <p2j412e6f7f1004191732p41094214yf82d2755f9081d1d@mail.gmail.com>
Le mardi 20 avril 2010 à 08:32 +0800, Changli Gao a écrit :
> Oh, I read the code again and got the answer. After the IPI is sent,
> this softnet will be queued by the other CPUs. We prefetch the pointer
> rps_ipi_next to avoid this race condition.
>
Speaking of prefetch business,
I partly tested following patch, I will submit it if it happens to be a
clear win.
diff --git a/net/core/dev.c b/net/core/dev.c
index 05a2b29..fe6fc9f 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2349,7 +2349,9 @@ done:
static void trigger_softirq(void *data)
{
struct softnet_data *queue = data;
+
__napi_schedule(&queue->backlog);
+ prefetch(queue->input_pkt_queue.next);
__get_cpu_var(netdev_rx_stat).received_rps++;
}
#endif /* CONFIG_RPS */
^ permalink raw reply related
* Re: [PATCH v5] rfs: Receive Flow Steering
From: Eric Dumazet @ 2010-04-20 5:59 UTC (permalink / raw)
To: Changli Gao; +Cc: David Miller, therbert, netdev
In-Reply-To: <y2u412e6f7f1004191638mee9206dfoab7482bbff83e38d@mail.gmail.com>
Le mardi 20 avril 2010 à 07:38 +0800, Changli Gao a écrit :
> Does this problem has relationship with your patch? No. If the rxhash
> isn't provided by hardware, we can get more throughput from you patch,
> and on the other side, we don't lose anything but potential more hash
> collision.
>
I am not sure what you call hash collision. There is no hash chain here.
This 32bit hash is a jhash one, and we only need 1 to 12 bits in it, I
am pretty sure its OK.
^ permalink raw reply
* [PATCH net-next-2.6] rps: cleanups
From: Eric Dumazet @ 2010-04-20 7:17 UTC (permalink / raw)
To: David Miller; +Cc: xiaosuo, therbert, netdev
In-Reply-To: <20100419.132158.143863746.davem@davemloft.net>
Le lundi 19 avril 2010 à 13:21 -0700, David Miller a écrit :
>
> It is getting increasingly complicated to follow who enables and
> disabled local cpu irqs in these code paths. We could combat
> this by adding something like "_irq_enable()" to the function
> names.
Yes I agree, we need a general cleanup in this file
Thanks David !
[PATCH net-next-2.6] rps: cleanups
struct softnet_data holds many queues, so consistent use "sd" name
instead of "queue" is better.
Adds a rps_ipi_queued() helper to cleanup enqueue_to_backlog()
Adds a _and_irq_disable suffix to net_rps_action() name, as David
suggested.
incr_input_queue_head() becomes input_queue_head_incr()
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/linux/netdevice.h | 4
net/core/dev.c | 149 +++++++++++++++++++-----------------
2 files changed, 82 insertions(+), 71 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 83ab3da..3c5ed5f 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1401,10 +1401,10 @@ struct softnet_data {
struct napi_struct backlog;
};
-static inline void incr_input_queue_head(struct softnet_data *queue)
+static inline void input_queue_head_incr(struct softnet_data *sd)
{
#ifdef CONFIG_RPS
- queue->input_queue_head++;
+ sd->input_queue_head++;
#endif
}
diff --git a/net/core/dev.c b/net/core/dev.c
index 05a2b29..70df048 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -208,17 +208,17 @@ static inline struct hlist_head *dev_index_hash(struct net *net, int ifindex)
return &net->dev_index_head[ifindex & (NETDEV_HASHENTRIES - 1)];
}
-static inline void rps_lock(struct softnet_data *queue)
+static inline void rps_lock(struct softnet_data *sd)
{
#ifdef CONFIG_RPS
- spin_lock(&queue->input_pkt_queue.lock);
+ spin_lock(&sd->input_pkt_queue.lock);
#endif
}
-static inline void rps_unlock(struct softnet_data *queue)
+static inline void rps_unlock(struct softnet_data *sd)
{
#ifdef CONFIG_RPS
- spin_unlock(&queue->input_pkt_queue.lock);
+ spin_unlock(&sd->input_pkt_queue.lock);
#endif
}
@@ -2346,63 +2346,74 @@ done:
}
/* Called from hardirq (IPI) context */
-static void trigger_softirq(void *data)
+static void rps_trigger_softirq(void *data)
{
- struct softnet_data *queue = data;
- __napi_schedule(&queue->backlog);
+ struct softnet_data *sd = data;
+
+ __napi_schedule(&sd->backlog);
__get_cpu_var(netdev_rx_stat).received_rps++;
}
+
#endif /* CONFIG_RPS */
/*
+ * Check if this softnet_data structure is another cpu one
+ * If yes, queue it to our IPI list and return 1
+ * If no, return 0
+ */
+static int rps_ipi_queued(struct softnet_data *sd)
+{
+#ifdef CONFIG_RPS
+ struct softnet_data *mysd = &__get_cpu_var(softnet_data);
+
+ if (sd != mysd) {
+ sd->rps_ipi_next = mysd->rps_ipi_list;
+ mysd->rps_ipi_list = sd;
+
+ __raise_softirq_irqoff(NET_RX_SOFTIRQ);
+ return 1;
+ }
+#endif /* CONFIG_RPS */
+ return 0;
+}
+
+/*
* enqueue_to_backlog is called to queue an skb to a per CPU backlog
* queue (may be a remote CPU queue).
*/
static int enqueue_to_backlog(struct sk_buff *skb, int cpu,
unsigned int *qtail)
{
- struct softnet_data *queue;
+ struct softnet_data *sd;
unsigned long flags;
- queue = &per_cpu(softnet_data, cpu);
+ sd = &per_cpu(softnet_data, cpu);
local_irq_save(flags);
__get_cpu_var(netdev_rx_stat).total++;
- rps_lock(queue);
- if (queue->input_pkt_queue.qlen <= netdev_max_backlog) {
- if (queue->input_pkt_queue.qlen) {
+ rps_lock(sd);
+ if (sd->input_pkt_queue.qlen <= netdev_max_backlog) {
+ if (sd->input_pkt_queue.qlen) {
enqueue:
- __skb_queue_tail(&queue->input_pkt_queue, skb);
+ __skb_queue_tail(&sd->input_pkt_queue, skb);
#ifdef CONFIG_RPS
- *qtail = queue->input_queue_head +
- queue->input_pkt_queue.qlen;
+ *qtail = sd->input_queue_head + sd->input_pkt_queue.qlen;
#endif
- rps_unlock(queue);
+ rps_unlock(sd);
local_irq_restore(flags);
return NET_RX_SUCCESS;
}
/* Schedule NAPI for backlog device */
- if (napi_schedule_prep(&queue->backlog)) {
-#ifdef CONFIG_RPS
- if (cpu != smp_processor_id()) {
- struct softnet_data *myqueue;
-
- myqueue = &__get_cpu_var(softnet_data);
- queue->rps_ipi_next = myqueue->rps_ipi_list;
- myqueue->rps_ipi_list = queue;
-
- __raise_softirq_irqoff(NET_RX_SOFTIRQ);
- goto enqueue;
- }
-#endif
- __napi_schedule(&queue->backlog);
+ if (napi_schedule_prep(&sd->backlog)) {
+ if (!rps_ipi_queued(sd))
+ __napi_schedule(&sd->backlog);
}
goto enqueue;
}
- rps_unlock(queue);
+ rps_unlock(sd);
__get_cpu_var(netdev_rx_stat).dropped++;
local_irq_restore(flags);
@@ -2903,17 +2914,17 @@ EXPORT_SYMBOL(netif_receive_skb);
static void flush_backlog(void *arg)
{
struct net_device *dev = arg;
- struct softnet_data *queue = &__get_cpu_var(softnet_data);
+ struct softnet_data *sd = &__get_cpu_var(softnet_data);
struct sk_buff *skb, *tmp;
- rps_lock(queue);
- skb_queue_walk_safe(&queue->input_pkt_queue, skb, tmp)
+ rps_lock(sd);
+ skb_queue_walk_safe(&sd->input_pkt_queue, skb, tmp)
if (skb->dev == dev) {
- __skb_unlink(skb, &queue->input_pkt_queue);
+ __skb_unlink(skb, &sd->input_pkt_queue);
kfree_skb(skb);
- incr_input_queue_head(queue);
+ input_queue_head_incr(sd);
}
- rps_unlock(queue);
+ rps_unlock(sd);
}
static int napi_gro_complete(struct sk_buff *skb)
@@ -3219,23 +3230,23 @@ EXPORT_SYMBOL(napi_gro_frags);
static int process_backlog(struct napi_struct *napi, int quota)
{
int work = 0;
- struct softnet_data *queue = &__get_cpu_var(softnet_data);
+ struct softnet_data *sd = &__get_cpu_var(softnet_data);
napi->weight = weight_p;
do {
struct sk_buff *skb;
local_irq_disable();
- rps_lock(queue);
- skb = __skb_dequeue(&queue->input_pkt_queue);
+ rps_lock(sd);
+ skb = __skb_dequeue(&sd->input_pkt_queue);
if (!skb) {
__napi_complete(napi);
- rps_unlock(queue);
+ rps_unlock(sd);
local_irq_enable();
break;
}
- incr_input_queue_head(queue);
- rps_unlock(queue);
+ input_queue_head_incr(sd);
+ rps_unlock(sd);
local_irq_enable();
__netif_receive_skb(skb);
@@ -3331,24 +3342,25 @@ EXPORT_SYMBOL(netif_napi_del);
* net_rps_action sends any pending IPI's for rps.
* Note: called with local irq disabled, but exits with local irq enabled.
*/
-static void net_rps_action(void)
+static void net_rps_action_and_irq_disable(void)
{
#ifdef CONFIG_RPS
- struct softnet_data *locqueue = &__get_cpu_var(softnet_data);
- struct softnet_data *remqueue = locqueue->rps_ipi_list;
+ struct softnet_data *sd = &__get_cpu_var(softnet_data);
+ struct softnet_data *remsd = sd->rps_ipi_list;
- if (remqueue) {
- locqueue->rps_ipi_list = NULL;
+ if (remsd) {
+ sd->rps_ipi_list = NULL;
local_irq_enable();
/* Send pending IPI's to kick RPS processing on remote cpus. */
- while (remqueue) {
- struct softnet_data *next = remqueue->rps_ipi_next;
- if (cpu_online(remqueue->cpu))
- __smp_call_function_single(remqueue->cpu,
- &remqueue->csd, 0);
- remqueue = next;
+ while (remsd) {
+ struct softnet_data *next = remsd->rps_ipi_next;
+
+ if (cpu_online(remsd->cpu))
+ __smp_call_function_single(remsd->cpu,
+ &remsd->csd, 0);
+ remsd = next;
}
} else
#endif
@@ -3423,7 +3435,7 @@ static void net_rx_action(struct softirq_action *h)
netpoll_poll_unlock(have);
}
out:
- net_rps_action();
+ net_rps_action_and_irq_disable();
#ifdef CONFIG_NET_DMA
/*
@@ -5595,7 +5607,7 @@ static int dev_cpu_callback(struct notifier_block *nfb,
/* Process offline CPU's input_pkt_queue */
while ((skb = __skb_dequeue(&oldsd->input_pkt_queue))) {
netif_rx(skb);
- incr_input_queue_head(oldsd);
+ input_queue_head_incr(oldsd);
}
return NOTIFY_OK;
@@ -5812,24 +5824,23 @@ static int __init net_dev_init(void)
*/
for_each_possible_cpu(i) {
- struct softnet_data *queue;
+ struct softnet_data *sd = &per_cpu(softnet_data, i);
- queue = &per_cpu(softnet_data, i);
- skb_queue_head_init(&queue->input_pkt_queue);
- queue->completion_queue = NULL;
- INIT_LIST_HEAD(&queue->poll_list);
+ skb_queue_head_init(&sd->input_pkt_queue);
+ sd->completion_queue = NULL;
+ INIT_LIST_HEAD(&sd->poll_list);
#ifdef CONFIG_RPS
- queue->csd.func = trigger_softirq;
- queue->csd.info = queue;
- queue->csd.flags = 0;
- queue->cpu = i;
+ sd->csd.func = rps_trigger_softirq;
+ sd->csd.info = sd;
+ sd->csd.flags = 0;
+ sd->cpu = i;
#endif
- queue->backlog.poll = process_backlog;
- queue->backlog.weight = weight_p;
- queue->backlog.gro_list = NULL;
- queue->backlog.gro_count = 0;
+ sd->backlog.poll = process_backlog;
+ sd->backlog.weight = weight_p;
+ sd->backlog.gro_list = NULL;
+ sd->backlog.gro_count = 0;
}
dev_boot_phase = 0;
^ permalink raw reply related
* [PATCH net-next-2.6] rps: consistent rxhash
From: Eric Dumazet @ 2010-04-20 7:56 UTC (permalink / raw)
To: Changli Gao, David Miller; +Cc: therbert, netdev
In-Reply-To: <1271743164.3845.128.camel@edumazet-laptop>
In case we compute a software skb->rxhash, we can generate a consistent
hash : Its value will be the same in both flow directions.
This helps some workloads, like conntracking, since the same state needs
to be accessed in both directions.
tbench + RFS + this patch gives better results than tbench with default
kernel configuration (no RPS, no RFS)
Also fixed some sparse warnings.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/dev.c | 25 ++++++++++++++++++-------
1 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 05a2b29..cb150ec 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1974,7 +1974,7 @@ u16 skb_tx_hash(const struct net_device *dev, const struct sk_buff *skb)
if (skb->sk && skb->sk->sk_hash)
hash = skb->sk->sk_hash;
else
- hash = skb->protocol;
+ hash = (__force u16) skb->protocol;
hash = jhash_1word(hash, hashrnd);
@@ -2253,8 +2253,8 @@ static int get_rps_cpu(struct net_device *dev, struct sk_buff *skb,
ip = (struct iphdr *) skb->data;
ip_proto = ip->protocol;
- addr1 = ip->saddr;
- addr2 = ip->daddr;
+ addr1 = (__force u32) ip->saddr;
+ addr2 = (__force u32) ip->daddr;
ihl = ip->ihl;
break;
case __constant_htons(ETH_P_IPV6):
@@ -2263,8 +2263,8 @@ static int get_rps_cpu(struct net_device *dev, struct sk_buff *skb,
ip6 = (struct ipv6hdr *) skb->data;
ip_proto = ip6->nexthdr;
- addr1 = ip6->saddr.s6_addr32[3];
- addr2 = ip6->daddr.s6_addr32[3];
+ addr1 = (__force u32) ip6->saddr.s6_addr32[3];
+ addr2 = (__force u32) ip6->daddr.s6_addr32[3];
ihl = (40 >> 2);
break;
default:
@@ -2279,14 +2279,25 @@ static int get_rps_cpu(struct net_device *dev, struct sk_buff *skb,
case IPPROTO_AH:
case IPPROTO_SCTP:
case IPPROTO_UDPLITE:
- if (pskb_may_pull(skb, (ihl * 4) + 4))
- ports = *((u32 *) (skb->data + (ihl * 4)));
+ if (pskb_may_pull(skb, (ihl * 4) + 4)) {
+ __be16 *hports = (__be16 *) (skb->data + (ihl * 4));
+ u32 sport, dport;
+
+ sport = (__force u16) hports[0];
+ dport = (__force u16) hports[1];
+ if (dport < sport)
+ swap(sport, dport);
+ ports = (sport << 16) + dport;
+ }
break;
default:
break;
}
+ /* get a consistent hash (same value on both flow directions) */
+ if (addr2 < addr1)
+ swap(addr1, addr2);
skb->rxhash = jhash_3words(addr1, addr2, ports, hashrnd);
if (!skb->rxhash)
skb->rxhash = 1;
^ permalink raw reply related
* Re: [PATCH net-next-2.6] rps: cleanups
From: David Miller @ 2010-04-20 8:18 UTC (permalink / raw)
To: eric.dumazet; +Cc: xiaosuo, therbert, netdev
In-Reply-To: <1271747834.3845.206.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 20 Apr 2010 09:17:14 +0200
> Le lundi 19 avril 2010 à 13:21 -0700, David Miller a écrit :
>
>>
>> It is getting increasingly complicated to follow who enables and
>> disabled local cpu irqs in these code paths. We could combat
>> this by adding something like "_irq_enable()" to the function
>> names.
>
> Yes I agree, we need a general cleanup in this file
>
> Thanks David !
>
> [PATCH net-next-2.6] rps: cleanups
>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] rps: consistent rxhash
From: David Miller @ 2010-04-20 8:18 UTC (permalink / raw)
To: eric.dumazet; +Cc: xiaosuo, therbert, netdev
In-Reply-To: <1271750198.3845.216.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 20 Apr 2010 09:56:38 +0200
> In case we compute a software skb->rxhash, we can generate a consistent
> hash : Its value will be the same in both flow directions.
>
> This helps some workloads, like conntracking, since the same state needs
> to be accessed in both directions.
>
> tbench + RFS + this patch gives better results than tbench with default
> kernel configuration (no RPS, no RFS)
>
> Also fixed some sparse warnings.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ 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