* Re: MSI interrupts and disable_irq
From: Manfred Spraul @ 2007-10-07 16:54 UTC (permalink / raw)
To: Jeff Garzik
Cc: Yinghai Lu, Ayaz Abdulla, nedev, Linux Kernel Mailing List,
David Miller, Andrew Morton
In-Reply-To: <4707CCF1.8080909@pobox.com>
Jeff Garzik wrote:
>
> Interested parties should try the forcedeth patches I just posted :)
>
The patches look good, but I would still prefer to understand why the
current implementation causes crashes before rewriting everything.
I've just noticed that netpoll_send_skb() calls ->hard_start_xmit() and
->poll() within local_irq_save().
Thus it seems that spin_lock_irqsave() must be used in the poll() and
hard_start_xmit() callbacks, at least in nics that support
POLL_CONTROLLER :-(
--
Manfred
^ permalink raw reply
* Re: 2.6.23-rc8-mm2 BUG: register_netdevice() issue as (ab)used by ISDN
From: Andreas Mohr @ 2007-10-07 17:20 UTC (permalink / raw)
To: Andreas Mohr; +Cc: Jeff Garzik, isdn4linux, netdev, akpm
In-Reply-To: <20071007131723.GA22873@rhlx01.hs-esslingen.de>
Hi,
On Sun, Oct 07, 2007 at 03:17:24PM +0200, Andreas Mohr wrote:
> I thus decided to now try plain 2.6.23-rc8 whether it's "corrupted", too.
OK, after 3 hours of compilation the ONLY datapoint I can give right now is:
1 (one) boot on 2.6.23-rc8-mm2 had the BUG in /var/log/messages,
1 (one) boot on 2.6.23-rc8 did NOT have it.
The two .config:s (I did a make oldconfig when going back to
non-mm2) don't seem to have any relevant differences.
I could offer to do more testing on this machine,
but this carries a slight risk for me since I (personally) won't have physical
access to it for a couple days and some people will kill me if the main
internet gateway happened to go down unfixably. ;)
Thanks,
Andreas Mohr
^ permalink raw reply
* [ofa-general] [PATCHES] TX batching
From: jamal @ 2007-10-07 18:34 UTC (permalink / raw)
To: David Miller
Cc: johnpol, peter.p.waskiewicz.jr, kumarkr, herbert, gaagaan,
Robert.Olsson, netdev, rdreier, mcarlson, randy.dunlap, jagana,
general, mchan, tgraf, jeff, sri, shemminger, kaber
In-Reply-To: <1190569987.4256.52.camel@localhost>
Please provide feedback on the code and/or architecture.
Last time i posted them i received little. They are now updated to
work with the latest net-2.6.24 from a few hours ago.
Patch 1: Introduces batching interface
Patch 2: Core uses batching interface
Patch 3: get rid of dev->gso_skb
What has changed since i posted last:
1) Fix a bug eyeballed by Patrick McHardy on requeue reordering.
2) Killed ->hard_batch_xmit()
3) I am going one step back and making this set of patches even simpler
so i can make it easier to review.I am therefore killing dev->hard_prep_xmit()
and focussing just on batching. I plan to re-introduce dev->hard_prep_xmit()
but from now on i will make that a separate effort. (it seems to be creating
confusion in relation to the general work).
Dave please let me know if this meets your desires to allow devices
which are SG and able to compute CSUM benefit just in case i misunderstood.
Herbert, if you can look at at least patch 3 i will appreaciate it
(since it kills dev->gso_skb that you introduced).
UPCOMING PATCHES
---------------
As before:
More patches to follow later if i get some feedback - i didnt want to
overload people by dumping too many patches. Most of these patches
mentioned below are ready to go; some need some re-testing and others
need a little porting from an earlier kernel:
- tg3 driver
- tun driver
- pktgen
- netiron driver
- e1000 driver (LLTX)
- e1000e driver (non-LLTX)
- ethtool interface
- There is at least one other driver promised to me
Theres also a driver-howto i wrote that was posted on netdev last week
as well as one that describes the architectural decisions made.
PERFORMANCE TESTING
--------------------
I started testing since yesterday, but these tests take a long time
so i will post results probably at the end of the day sometime and
may stop running more tests and just comparing batch vs non-batch results.
I have optimized the kernel-config so i expect my overall performance
numbers to look better than the last test results i posted for both
batch and non-batch.
My system under test hardware is still a 2xdual core opteron with a
couple of tg3s.
A test tool generates udp traffic of different sizes for upto 60
seconds per run or a total of 30M packets. I have 4 threads each
running on a specific CPU which keep all the CPUs as busy as they can
sending packets targetted at a directly connected box's udp discard port.
All 4 CPUs target a single tg3 to send. The receiving box has a tc rule
which counts and drops all incoming udp packets to discard port - this
allows me to make sure that the receiver is not the bottleneck in the
testing. Packet sizes sent are {8B, 32B, 64B, 128B, 256B, 512B, 1024B}.
Each packet size run is repeated 10 times to ensure that there are no
transients. The average of all 10 runs is then computed and collected.
I do plan also to run forwarding and TCP tests in the future when the
dust settles.
cheers,
jamal
^ permalink raw reply
* [ofa-general] [PATCH 1/3] [NET_BATCH] Introduce batching interface
From: jamal @ 2007-10-07 18:36 UTC (permalink / raw)
To: David Miller
Cc: johnpol, peter.p.waskiewicz.jr, kumarkr, herbert, gaagaan,
Robert.Olsson, netdev, rdreier, mcarlson, randy.dunlap, jagana,
general, mchan, tgraf, jeff, sri, shemminger, kaber
In-Reply-To: <1190570317.4256.59.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 77 bytes --]
This patch introduces the netdevice interface for batching.
cheers,
jamal
[-- Attachment #2: oct07-p1of3 --]
[-- Type: text/plain, Size: 7403 bytes --]
[NET_BATCH] Introduce batching interface
This patch introduces the netdevice interface for batching.
BACKGROUND
---------
A driver dev->hard_start_xmit() has 4 typical parts:
a) packet formating (example vlan, mss, descriptor counting etc)
b) chip specific formatting
c) enqueueing the packet on a DMA ring
d) IO operations to complete packet transmit, tell DMA engine to chew on,
tx completion interupts, set last tx time, etc
[For code cleanliness/readability sake, regardless of this work,
one should break the dev->hard_start_xmit() into those 4 functions
anyways].
INTRODUCING API
---------------
With the api introduced in this patch, a driver which has all
4 parts and needing to support batching is advised to split its
dev->hard_start_xmit() in the following manner:
1)Remove #d from dev->hard_start_xmit() and put it in
dev->hard_end_xmit() method.
2)#b and #c can stay in ->hard_start_xmit() (or whichever way you want
to do this)
3) #a is deffered to future work to reduce confusion (since it holds
on its own).
Note: There are drivers which may need not support any of the two
approaches (example the tun driver i patched) so the methods are
optional.
xmit_win variable is set by the driver to tell the core how much space
it has to take on new skbs. It is introduced to ensure that when we pass
the driver a list of packets it will swallow all of them - which is
useful because we dont requeue to the qdisc (and avoids burning
unnecessary cpu cycles or introducing any strange re-ordering). The driver
tells us when it invokes netif_wake_queue how much space it has for
descriptors by setting this variable.
Refer to the driver howto for more details.
THEORY OF OPERATION
-------------------
1. Core dequeues from qdiscs upto dev->xmit_win packets. Fragmented
and GSO packets are accounted for as well.
2. Core grabs TX_LOCK
3. Core loop for all skbs:
invokes driver dev->hard_start_xmit()
4. Core invokes driver dev->hard_end_xmit()
ACKNOWLEDGEMENT AND SOME HISTORY
--------------------------------
There's a lot of history and reasoning of "why batching" in a document
i am writting which i may submit as a patch.
Thomas Graf (who doesnt know this probably) gave me the impetus to
start looking at this back in 2004 when he invited me to the linux
conference he was organizing. Parts of what i presented in SUCON in
2004 talk about batching. Herbert Xu forced me to take a second look around
2.6.18 - refer to my netconf 2006 presentation. Krishna Kumar provided
me with more motivation in May 2007 when he posted on netdev and engaged
me.
Sridhar Samudrala, Krishna Kumar, Matt Carlson, Michael Chan,
Jeremy Ethridge, Evgeniy Polyakov, Sivakumar Subramani, David Miller,
and Patrick McHardy, Jeff Garzik and Bill Fink have contributed in one or
more of {bug fixes, enhancements, testing, lively discussion}. The
Broadcom and neterion folks have been outstanding in their help.
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
---
commit 0a0762e2c615a980af284e86d9729d233e1bf7f4
tree c27fec824a9e75ffbb791647bdb595c082a54990
parent 190674ff1fe0b7bddf038c2bfddf45b9c6418e2a
author Jamal Hadi Salim <hadi@cyberus.ca> Sun, 07 Oct 2007 08:51:10 -0400
committer Jamal Hadi Salim <hadi@cyberus.ca> Sun, 07 Oct 2007 08:51:10 -0400
include/linux/netdevice.h | 11 ++++++
net/core/dev.c | 83 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 94 insertions(+), 0 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 91cd3f3..b31df5c 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -467,6 +467,7 @@ struct net_device
#define NETIF_F_NETNS_LOCAL 8192 /* Does not change network namespaces */
#define NETIF_F_MULTI_QUEUE 16384 /* Has multiple TX/RX queues */
#define NETIF_F_LRO 32768 /* large receive offload */
+#define NETIF_F_BTX 65536 /* Capable of batch tx */
/* Segmentation offload features */
#define NETIF_F_GSO_SHIFT 16
@@ -595,6 +596,9 @@ struct net_device
void *priv; /* pointer to private data */
int (*hard_start_xmit) (struct sk_buff *skb,
struct net_device *dev);
+ void (*hard_end_xmit) (struct net_device *dev);
+ int xmit_win;
+
/* These may be needed for future network-power-down code. */
unsigned long trans_start; /* Time (in jiffies) of last Tx */
@@ -609,6 +613,7 @@ struct net_device
/* delayed register/unregister */
struct list_head todo_list;
+ struct sk_buff_head blist;
/* device index hash chain */
struct hlist_node index_hlist;
@@ -1044,6 +1049,12 @@ extern int dev_set_mac_address(struct net_device *,
struct sockaddr *);
extern int dev_hard_start_xmit(struct sk_buff *skb,
struct net_device *dev);
+extern int dev_batch_xmit(struct net_device *dev);
+extern int prepare_gso_skb(struct sk_buff *skb,
+ struct net_device *dev,
+ struct sk_buff_head *skbs);
+extern int xmit_prepare_skb(struct sk_buff *skb,
+ struct net_device *dev);
extern int netdev_budget;
diff --git a/net/core/dev.c b/net/core/dev.c
index d998646..04df3fb 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1517,6 +1517,87 @@ static int dev_gso_segment(struct sk_buff *skb)
return 0;
}
+int prepare_gso_skb(struct sk_buff *skb, struct net_device *dev,
+ struct sk_buff_head *skbs)
+{
+ int tdq = 0;
+ do {
+ struct sk_buff *nskb = skb->next;
+
+ skb->next = nskb->next;
+ nskb->next = NULL;
+
+ /* Driver likes this packet .. */
+ tdq++;
+ __skb_queue_tail(skbs, nskb);
+ } while (skb->next);
+ skb->destructor = DEV_GSO_CB(skb)->destructor;
+ kfree_skb(skb);
+
+ return tdq;
+}
+
+int xmit_prepare_skb(struct sk_buff *skb, struct net_device *dev)
+{
+ struct sk_buff_head *skbs = &dev->blist;
+
+ if (netif_needs_gso(dev, skb)) {
+ if (unlikely(dev_gso_segment(skb))) {
+ kfree_skb(skb);
+ return 0;
+ }
+ if (skb->next)
+ return prepare_gso_skb(skb, dev, skbs);
+ }
+
+ __skb_queue_tail(skbs, skb);
+ return 1;
+}
+
+int dev_batch_xmit(struct net_device *dev)
+{
+ struct sk_buff_head *skbs = &dev->blist;
+ int rc = NETDEV_TX_OK;
+ struct sk_buff *skb;
+ int orig_w = dev->xmit_win;
+ int orig_pkts = skb_queue_len(skbs);
+
+ while ((skb = __skb_dequeue(skbs)) != NULL) {
+ if (!list_empty(&ptype_all))
+ dev_queue_xmit_nit(skb, dev);
+ rc = dev->hard_start_xmit(skb, dev);
+ if (unlikely(rc))
+ break;
+ /* * XXX: multiqueue may need closer srutiny.. */
+ if (unlikely(netif_queue_stopped(dev) ||
+ netif_subqueue_stopped(dev, skb->queue_mapping))) {
+ rc = NETDEV_TX_BUSY;
+ break;
+ }
+ }
+
+ /* driver is likely buggy and lied to us on how much
+ * space it had. Damn you driver ..
+ */
+ if (unlikely(skb_queue_len(skbs))) {
+ printk(KERN_WARNING "Likely bug %s %s (%d) "
+ "left %d/%d window now %d, orig %d\n",
+ dev->name, rc?"busy":"locked",
+ netif_queue_stopped(dev),
+ skb_queue_len(skbs),
+ orig_pkts,
+ dev->xmit_win,
+ orig_w);
+ rc = NETDEV_TX_BUSY;
+ }
+
+ if (orig_pkts > skb_queue_len(skbs))
+ if (dev->hard_end_xmit)
+ dev->hard_end_xmit(dev);
+
+ return rc;
+}
+
int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
if (likely(!skb->next)) {
@@ -3553,6 +3634,8 @@ int register_netdevice(struct net_device *dev)
}
}
+ dev->xmit_win = 1;
+ skb_queue_head_init(&dev->blist);
ret = netdev_register_kobject(dev);
if (ret)
goto err_uninit;
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply related
* [ofa-general] [PATCH 2/3][NET_BATCH] net core use batching
From: jamal @ 2007-10-07 18:38 UTC (permalink / raw)
To: David Miller
Cc: johnpol, peter.p.waskiewicz.jr, kumarkr, herbert, gaagaan,
Robert.Olsson, netdev, rdreier, mcarlson, randy.dunlap, jagana,
general, mchan, tgraf, jeff, sri, shemminger, kaber
In-Reply-To: <1190570409.4256.62.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 73 bytes --]
This patch adds the usage of batching within the core.
cheers,
jamal
[-- Attachment #2: oct07-p2of3 --]
[-- Type: text/plain, Size: 5401 bytes --]
[NET_BATCH] net core use batching
This patch adds the usage of batching within the core.
Performance results demonstrating improvement are provided separately.
I have #if-0ed some of the old functions so the patch is more readable.
A future patch will remove all if-0ed content.
Patrick McHardy eyeballed a bug that will cause re-ordering in case
of a requeue.
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
---
commit cd602aa5f84fcef6359852cd99c95863eeb91015
tree f31d2dde4f138ff6789682163624bc0f8541aa77
parent 0a0762e2c615a980af284e86d9729d233e1bf7f4
author Jamal Hadi Salim <hadi@cyberus.ca> Sun, 07 Oct 2007 09:13:04 -0400
committer Jamal Hadi Salim <hadi@cyberus.ca> Sun, 07 Oct 2007 09:13:04 -0400
net/sched/sch_generic.c | 132 +++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 120 insertions(+), 12 deletions(-)
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 95ae119..80ac56b 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -56,6 +56,7 @@ static inline int qdisc_qlen(struct Qdisc *q)
return q->q.qlen;
}
+#if 0
static inline int dev_requeue_skb(struct sk_buff *skb, struct net_device *dev,
struct Qdisc *q)
{
@@ -110,6 +111,97 @@ static inline int handle_dev_cpu_collision(struct sk_buff *skb,
return ret;
}
+#endif
+
+static inline int handle_dev_cpu_collision(struct net_device *dev)
+{
+ if (unlikely(dev->xmit_lock_owner == smp_processor_id())) {
+ if (net_ratelimit())
+ printk(KERN_WARNING
+ "Dead loop on netdevice %s, fix it urgently!\n",
+ dev->name);
+ return 1;
+ }
+ __get_cpu_var(netdev_rx_stat).cpu_collision++;
+ return 0;
+}
+
+static inline int
+dev_requeue_skbs(struct sk_buff_head *skbs, struct net_device *dev,
+ struct Qdisc *q)
+{
+
+ struct sk_buff *skb;
+
+ while ((skb = __skb_dequeue_tail(skbs)) != NULL)
+ q->ops->requeue(skb, q);
+
+ netif_schedule(dev);
+ return 0;
+}
+
+static inline int
+xmit_islocked(struct sk_buff_head *skbs, struct net_device *dev,
+ struct Qdisc *q)
+{
+ int ret = handle_dev_cpu_collision(dev);
+
+ if (ret) {
+ if (!skb_queue_empty(skbs))
+ skb_queue_purge(skbs);
+ return qdisc_qlen(q);
+ }
+
+ return dev_requeue_skbs(skbs, dev, q);
+}
+
+static int xmit_count_skbs(struct sk_buff *skb)
+{
+ int count = 0;
+ for (; skb; skb = skb->next) {
+ count += skb_shinfo(skb)->nr_frags;
+ count += 1;
+ }
+ return count;
+}
+
+static int xmit_get_pkts(struct net_device *dev,
+ struct Qdisc *q,
+ struct sk_buff_head *pktlist)
+{
+ struct sk_buff *skb;
+ int count = dev->xmit_win;
+
+ if (count && dev->gso_skb) {
+ skb = dev->gso_skb;
+ dev->gso_skb = NULL;
+ count -= xmit_count_skbs(skb);
+ __skb_queue_tail(pktlist, skb);
+ }
+
+ while (count > 0) {
+ skb = q->dequeue(q);
+ if (!skb)
+ break;
+
+ count -= xmit_count_skbs(skb);
+ __skb_queue_tail(pktlist, skb);
+ }
+
+ return skb_queue_len(pktlist);
+}
+
+static int xmit_prepare_pkts(struct net_device *dev,
+ struct sk_buff_head *tlist)
+{
+ struct sk_buff *skb;
+ struct sk_buff_head *flist = &dev->blist;
+
+ while ((skb = __skb_dequeue(tlist)) != NULL)
+ xmit_prepare_skb(skb, dev);
+
+ return skb_queue_len(flist);
+}
/*
* NOTE: Called under dev->queue_lock with locally disabled BH.
@@ -130,22 +222,32 @@ static inline int handle_dev_cpu_collision(struct sk_buff *skb,
* >0 - queue is not empty.
*
*/
-static inline int qdisc_restart(struct net_device *dev)
+
+static inline int qdisc_restart(struct net_device *dev,
+ struct sk_buff_head *tpktlist)
{
struct Qdisc *q = dev->qdisc;
- struct sk_buff *skb;
- int ret;
+ int ret = 0;
- /* Dequeue packet */
- if (unlikely((skb = dev_dequeue_skb(dev, q)) == NULL))
- return 0;
+ /* use of tpktlist reduces the amount of time we sit
+ * holding the queue_lock
+ */
+ ret = xmit_get_pkts(dev, q, tpktlist);
+ if (!ret)
+ return 0;
- /* And release queue */
+ /* We got em packets */
spin_unlock(&dev->queue_lock);
+ /* prepare to embark, no locks held moves packets
+ * to dev->blist
+ * */
+ xmit_prepare_pkts(dev, tpktlist);
+
+ /* bye packets ....*/
HARD_TX_LOCK(dev, smp_processor_id());
- ret = dev_hard_start_xmit(skb, dev);
+ ret = dev_batch_xmit(dev);
HARD_TX_UNLOCK(dev);
spin_lock(&dev->queue_lock);
@@ -158,8 +260,8 @@ static inline int qdisc_restart(struct net_device *dev)
break;
case NETDEV_TX_LOCKED:
- /* Driver try lock failed */
- ret = handle_dev_cpu_collision(skb, dev, q);
+ /* Driver lock failed */
+ ret = xmit_islocked(&dev->blist, dev, q);
break;
default:
@@ -168,7 +270,7 @@ static inline int qdisc_restart(struct net_device *dev)
printk(KERN_WARNING "BUG %s code %d qlen %d\n",
dev->name, ret, q->q.qlen);
- ret = dev_requeue_skb(skb, dev, q);
+ ret = dev_requeue_skbs(&dev->blist, dev, q);
break;
}
@@ -177,8 +279,11 @@ static inline int qdisc_restart(struct net_device *dev)
void __qdisc_run(struct net_device *dev)
{
+ struct sk_buff_head tpktlist;
+ skb_queue_head_init(&tpktlist);
+
do {
- if (!qdisc_restart(dev))
+ if (!qdisc_restart(dev, &tpktlist))
break;
} while (!netif_queue_stopped(dev));
@@ -564,6 +669,9 @@ void dev_deactivate(struct net_device *dev)
skb = dev->gso_skb;
dev->gso_skb = NULL;
+ if (!skb_queue_empty(&dev->blist))
+ skb_queue_purge(&dev->blist);
+ dev->xmit_win = 1;
spin_unlock_bh(&dev->queue_lock);
kfree_skb(skb);
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply related
* [ofa-general] [PATCH 3/3][NET_BATCH] kill dev->gso_skb
From: jamal @ 2007-10-07 18:39 UTC (permalink / raw)
To: David Miller
Cc: johnpol, peter.p.waskiewicz.jr, kumarkr, herbert, gaagaan,
Robert.Olsson, netdev, rdreier, mcarlson, randy.dunlap, jagana,
general, mchan, tgraf, jeff, sri, shemminger, kaber
In-Reply-To: <1190570521.4256.65.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 96 bytes --]
This patch removes dev->gso_skb as it is no longer necessary with
batching code.
cheers,
jamal
[-- Attachment #2: oct07-p3of3 --]
[-- Type: text/plain, Size: 2277 bytes --]
[NET_BATCH] kill dev->gso_skb
The batching code does what gso used to batch at the drivers.
There is no more need for gso_skb. If for whatever reason the
requeueing is a bad idea we are going to leave packets in dev->blist
(and still not need dev->gso_skb)
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
---
commit 7ebf50f0f43edd4897b88601b4133612fc36af61
tree 5d942ecebc14de6254ab3c812d542d524e148e92
parent cd602aa5f84fcef6359852cd99c95863eeb91015
author Jamal Hadi Salim <hadi@cyberus.ca> Sun, 07 Oct 2007 09:30:19 -0400
committer Jamal Hadi Salim <hadi@cyberus.ca> Sun, 07 Oct 2007 09:30:19 -0400
include/linux/netdevice.h | 3 ---
net/sched/sch_generic.c | 12 ------------
2 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index b31df5c..4ddc6eb 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -577,9 +577,6 @@ struct net_device
struct list_head qdisc_list;
unsigned long tx_queue_len; /* Max frames per queue allowed */
- /* Partially transmitted GSO packet. */
- struct sk_buff *gso_skb;
-
/* ingress path synchronizer */
spinlock_t ingress_lock;
struct Qdisc *qdisc_ingress;
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 80ac56b..772e7fe 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -172,13 +172,6 @@ static int xmit_get_pkts(struct net_device *dev,
struct sk_buff *skb;
int count = dev->xmit_win;
- if (count && dev->gso_skb) {
- skb = dev->gso_skb;
- dev->gso_skb = NULL;
- count -= xmit_count_skbs(skb);
- __skb_queue_tail(pktlist, skb);
- }
-
while (count > 0) {
skb = q->dequeue(q);
if (!skb)
@@ -659,7 +652,6 @@ void dev_activate(struct net_device *dev)
void dev_deactivate(struct net_device *dev)
{
struct Qdisc *qdisc;
- struct sk_buff *skb;
spin_lock_bh(&dev->queue_lock);
qdisc = dev->qdisc;
@@ -667,15 +659,11 @@ void dev_deactivate(struct net_device *dev)
qdisc_reset(qdisc);
- skb = dev->gso_skb;
- dev->gso_skb = NULL;
if (!skb_queue_empty(&dev->blist))
skb_queue_purge(&dev->blist);
dev->xmit_win = 1;
spin_unlock_bh(&dev->queue_lock);
- kfree_skb(skb);
-
dev_watchdog_down(dev);
/* Wait for outstanding dev_queue_xmit calls. */
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply related
* Re: [PATCH 2/5] forcedeth: interrupt handling cleanup
From: Yinghai Lu @ 2007-10-07 19:36 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Ayaz Abdulla, LKML, Andrew Morton
In-Reply-To: <4708C5BD.8090402@garzik.org>
On 10/7/07, Jeff Garzik <jeff@garzik.org> wrote:
> Yinghai Lu wrote:
> > On 10/6/07, Jeff Garzik <jeff@garzik.org> wrote:
> >> commit a606d2a111cdf948da5d69eb1de5526c5c2dafef
> >> Author: Jeff Garzik <jeff@garzik.org>
> >> Date: Fri Oct 5 22:56:05 2007 -0400
> >>
> >> [netdrvr] forcedeth: interrupt handling cleanup
> >>
> >> * nv_nic_irq_optimized() and nv_nic_irq_other() were complete duplicates
> >> of nv_nic_irq(), with the exception of one function call. Consolidate
> >> all three into a single interrupt handler, deleting a lot of redundant
> >> code.
> >>
> >> * greatly simplify irq handler locking.
> >>
> >> Prior to this change, the irq handler(s) would acquire and release
> >> np->lock for each action (RX, TX, other events).
> >>
> >> For the common case -- RX or TX work -- the lock is always acquired,
> >> making all successive acquire/release combinations largely redundant.
> >>
> >> Acquire the lock at the beginning of the irq handler, and release it at
> >> the end of the irq handler. This is simple, easy, and obvious.
> >>
> >> * remove irq handler work loop.
> >>
> >> All interesting events emanating from the irq handler either have
> >> their own work loops, or they poke a timer into action.
> >>
> >> Therefore, delete the pointless master interrupt handler work loop.
> >>
> >> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
> >>
> Do you have ideas/suggestions for a different method?
in the e1000 driver, it has seperate handler for msi and ioapic.
but in forcedeth, the nv_nic_irq_optimized keep check msi_flags...,
with num of msi interrupt number, that could cause cpu loading get a
little bit high..., even the network performance is ok.
YH
^ permalink raw reply
* Re: [PATCH 0/5] forcedeth: several proposed updates for testing
From: Yinghai Lu @ 2007-10-07 19:39 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Ayaz Abdulla, LKML, Andrew Morton, Ingo Molnar
In-Reply-To: <4708F194.7080303@garzik.org>
On 10/7/07, Jeff Garzik <jeff@garzik.org> wrote:
> Jeff Garzik wrote:
> > The 'fe-lock' branch of
> > git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git fe-lock
> OK, I've successfully tested patches 1-5 on an AMD64 system with
>
> 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
need to test that with mcp55 based, that will use MSI.
YH
^ permalink raw reply
* Re: [PATCH 0/5] forcedeth: several proposed updates for testing
From: Jeff Garzik @ 2007-10-07 20:05 UTC (permalink / raw)
To: Yinghai Lu; +Cc: netdev, Ayaz Abdulla, LKML, Andrew Morton, Ingo Molnar
In-Reply-To: <86802c440710071239x28c41db2hca6dd7c5bb3c411c@mail.gmail.com>
Yinghai Lu wrote:
> On 10/7/07, Jeff Garzik <jeff@garzik.org> wrote:
>> Jeff Garzik wrote:
>>> The 'fe-lock' branch of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git fe-lock
>> OK, I've successfully tested patches 1-5 on an AMD64 system with
>>
>> 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
>
> need to test that with mcp55 based, that will use MSI.
I would love to see an MSI-X test too (might have to turn on throughput
mode).
Jeff
^ permalink raw reply
* Re: [PATCH 2/5] forcedeth: interrupt handling cleanup
From: Jeff Garzik @ 2007-10-07 20:07 UTC (permalink / raw)
To: Yinghai Lu; +Cc: netdev, Ayaz Abdulla, LKML, Andrew Morton
In-Reply-To: <86802c440710071236h137a5331i78f795d7a04c69e@mail.gmail.com>
Yinghai Lu wrote:
> On 10/7/07, Jeff Garzik <jeff@garzik.org> wrote:
>> Yinghai Lu wrote:
>>> On 10/6/07, Jeff Garzik <jeff@garzik.org> wrote:
>>>> commit a606d2a111cdf948da5d69eb1de5526c5c2dafef
>>>> Author: Jeff Garzik <jeff@garzik.org>
>>>> Date: Fri Oct 5 22:56:05 2007 -0400
>>>>
>>>> [netdrvr] forcedeth: interrupt handling cleanup
>>>>
>>>> * nv_nic_irq_optimized() and nv_nic_irq_other() were complete duplicates
>>>> of nv_nic_irq(), with the exception of one function call. Consolidate
>>>> all three into a single interrupt handler, deleting a lot of redundant
>>>> code.
>>>>
>>>> * greatly simplify irq handler locking.
>>>>
>>>> Prior to this change, the irq handler(s) would acquire and release
>>>> np->lock for each action (RX, TX, other events).
>>>>
>>>> For the common case -- RX or TX work -- the lock is always acquired,
>>>> making all successive acquire/release combinations largely redundant.
>>>>
>>>> Acquire the lock at the beginning of the irq handler, and release it at
>>>> the end of the irq handler. This is simple, easy, and obvious.
>>>>
>>>> * remove irq handler work loop.
>>>>
>>>> All interesting events emanating from the irq handler either have
>>>> their own work loops, or they poke a timer into action.
>>>>
>>>> Therefore, delete the pointless master interrupt handler work loop.
>>>>
>>>> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
>>>>
>> Do you have ideas/suggestions for a different method?
>
> in the e1000 driver, it has seperate handler for msi and ioapic.
>
> but in forcedeth, the nv_nic_irq_optimized keep check msi_flags...,
> with num of msi interrupt number, that could cause cpu loading get a
> little bit high..., even the network performance is ok.
With all the activity in the interrupt handler, a few in-cache branches
are definitely going to be lost in the noise.
Separating the interrupt handlers between MSI and non-MSI tends to be of
more benefit when the separation is accompanied by more efficient
locking in the MSI interrupt handler, or a different mode of interrupt
clear, or some other attribute.
Though CPU usage would be a good thing to measure, with these patches.
Jeff
^ permalink raw reply
* Re: [BNX2X][PATCH 0/8] New driver for Broadcom 10Gb Ethernet, take two.
From: Matti Aarnio @ 2007-10-07 20:50 UTC (permalink / raw)
To: Eliezer Tamir
Cc: davem@davemloft.net, jeff@garzik.org, netdev@vger.kernel.org,
Michael Chan, eilong, vladz, gertner
In-Reply-To: <47090768.4020307@broadcom.com>
On Sun, Oct 07, 2007 at 06:20:56PM +0200, Eliezer Tamir wrote:
> This is an initial version of the BNX2X, the Linux driver for the
> BCM5771X 10Gb Ethernet controller family.
> Although the chip is very different from the 5706-8 family we based the
> driver code on the BNX2 driver.
> Since the hardware is supposed to be generally available soon I have
> posted an initial version and after hearing all the comments I am reposting
> with changes to address them.
> Some planned feature are still under development, but we want to get
> whatever we have out now so people can start using the HW.
Your patch-posting procedure is yet in a bit problem state..
+{
+static const u32 EVST_TSEM_FAST_MEMORY_COMMON_MEMORY_INIT_EMULATION_7[] = {
+0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0,
+0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0,
+0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0,
It does look like your Thunderbird 2.0 did wrap long text lines when you
included the texts into the posts.
The result is that currently your patches are not usable at all.
Your options:
- instead of including the patch in message body, use Attach
- use some other email program that does not scramble your texts
(e.g. mutt + emacs)
- publish the patch file on network somewhere, and just tell URL
to that one in email
> Main changes from first version.
>
> * Fixed most issues raised by Michael Buesch. (Thanks Michael!)
> * Some slow path bug fixes.
> * Yitchak Gertner re-grouped the code in a more logical manner.
> * A lot of work was done to get the generated code to comply with coding
> style requirements.
>
> Known issues/TODO.
> * Move slowpath event handling from tasklet to workqueue context. This will
> allow replacing the busy waits in the link management code with sleeps.
>
> Please consider applying to 2.6.24
>
> Thanks
> Eliezer
/Matti Aarnio -- one of <postmaster@vger.kernel.org>
^ permalink raw reply
* [ofa-general] NET_BATCH: some results
From: jamal @ 2007-10-07 21:49 UTC (permalink / raw)
To: David Miller
Cc: johnpol, peter.p.waskiewicz.jr, kumarkr, herbert, gaagaan,
Robert.Olsson, netdev, rdreier, mcarlson, randy.dunlap, jagana,
general, mchan, tgraf, jeff, sri, shemminger, kaber
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
It seems prettier to just draw graphs and since this one is small file;
here it is attached. The graph demos a patched net-2.6.24 vs a plain
net-2.6.24 kernel with a udp app that sends on 4 CPUs as fast as the the
lower layers would allow it.
Refer to my earlier description of the test setup etc.
As i noted earlier on, for this hardware at about 200B or so, we
approach wire speed, so the app is mostly idle above that as the link
becomes the bottleneck; example it is > 85% idle on 512B and > 90% idle
on 1024B. This is so for either batch or non-batch. So the
differentiation is really in the smaller sized packets.
Enjoy!
cheers,
jamal
[-- Attachment #2: batch-pps.pdf --]
[-- Type: application/pdf, Size: 12238 bytes --]
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH] [343/2many] MAINTAINERS - IPVS
From: Simon Horman @ 2007-10-08 0:43 UTC (permalink / raw)
To: joe; +Cc: wensong, torvalds, netdev, linux-kernel, ja, akpm
In-Reply-To: <46bffb10.JY5EkYQg+QBB0ZZx%joe@perches.com>
On Sun, Aug 12, 2007 at 11:32:48PM -0700, joe@perches.com wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <joe@perches.com>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index dbfdb75..a8fb231 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3300,6 +3300,8 @@ P: Julian Anastasov
> M: ja@ssi.bg
> L: netdev@vger.kernel.org
> S: Maintained
> +F: Documentation/networking/ipvs-sysctl.txt
> +F: net/ipv4/ipvs
Should the following also be added:?
+F: include/net/ip_vs.h
>
> NFS CLIENT
> P: Trond Myklebust
> -
> 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
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
^ permalink raw reply
* Re: [PATCH] rtnl: Simplify ASSERT_RTNL
From: Patrick McHardy @ 2007-10-08 4:40 UTC (permalink / raw)
To: Herbert Xu; +Cc: Eric W. Biederman, davem, netdev, oliver, linux-usb-devel
In-Reply-To: <20071003060603.GA6457@gondor.apana.org.au>
Herbert Xu wrote:
> On Tue, Oct 02, 2007 at 05:29:11PM +0200, Patrick McHardy wrote:
>
>>I think this doesn't completely fix it, when dev_unicast_add is
>>interrupted by dev_mc_add before the unicast changes are performed,
>>they will get committed in the dev_mc_add context, so we might still
>>call change_flags with BH disabled. Taking the TX lock around the
>>dev->uc_count and dev->uc_promisc checks and changes in __dev_set_rx_mode
>>should fix this.
>
>
> Good catch. Digging back in history it seems that you added
> the change_rx_flags function so that the driver didn't have to
> do it under TX lock, right?
Yes, and to make sure the RTNL is held.
> The problem with this is that the stack can now call
> change_rx_flags and set_multicast_list simultaneously
> which presents a potential headache for the driver
> author (if they were to use change_rx_flags).
The change_rx_flags function was intended to be used by software
devices that want to synchronize flags to a different device,
in which case they shouldn't interfere since set_multicast_list
would only be used for the multicast list and not the flags.
> It seems to me what we could do is in fact separate out the
> part that adds the address and the part that syncs it with
> hardware.
That sounds like a really good idea to get rid of all the
confusion.
> That way we can call the hardware from a process context later
> and use the RTNL to guarantee that we only enter the driver
> once.
>
> So dev_mc_add would look like:
>
> 1) Hold some form of lock L.
> 2) Modify mc list A (a copy of the current mc list).
> 3) Drop lock.
> 4) Schedule an update to the hardware.
>
> The update to the hardware would look lie:
>
> 1) Hold RTNL.
> 2) Hold lock L.
> 3) Copy list A to list B (B would be our current list).
> 4) Drop lock L.
> 5) Call the hardware.
> 6) Drop RTNL.
>
> For compatibility, set_multicast_list would still be invoked
> under the TX lock while set_rx_mode would do exactly the same
> thing but would only hold the RTNL.
>
> What do you think about this approach?
Sounds great :)
^ permalink raw reply
* [ofa-general] Re: [PATCH 1/4] [NET_SCHED] explict hold dev tx lock
From: David Miller @ 2007-10-08 4:51 UTC (permalink / raw)
To: hadi
Cc: johnpol, kumarkr, herbert, gaagaan, Robert.Olsson, netdev,
rdreier, peter.p.waskiewicz.jr, mcarlson, randy.dunlap, jagana,
general, mchan, tgraf, jeff, sri, shemminger, kaber
In-Reply-To: <1190677099.4264.37.camel@localhost>
From: jamal <hadi@cyberus.ca>
Date: Mon, 24 Sep 2007 19:38:19 -0400
> How is the policy to define the qdisc queues locked/mapped to tx rings?
For these high performance 10Gbit cards it's a load balancing
function, really, as all of the transmit queues go out to the same
physical port so you could:
1) Load balance on CPU number.
2) Load balance on "flow"
3) Load balance on destination MAC
etc. etc. etc.
It's something that really sits logically between the qdisc and the
card, not something that is a qdisc thing.
In some ways it's similar to bonding, but using anything similar to
bonding's infrastructure (stacking devices) is way overkill for this.
And then we have the virtualization network devices where the queue
selection has to be made precisely, in order for the packet to
reach the proper destination, rather than a performance improvement.
It is also a situation where the TX queue selection is something
to be made between qdisc activity and hitting the device.
I think we will initially have to live with taking the centralized
qdisc lock for the device, get in and out of that as fast as possible,
then only take the TX queue lock of the queue selected.
After we get things that far we can try to find some clever lockless
algorithm for handling the qdisc to get rid of that hot spot.
These queue selection schemes want a common piece of generic code. A
set of load balancing algorithms, a "select TX queue by MAC with a
default fallback on no match" for virtualization, and interfaces for
both drivers and userspace to change the queue selection scheme.
^ permalink raw reply
* [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Krishna Kumar2 @ 2007-10-08 5:03 UTC (permalink / raw)
To: hadi
Cc: jagana, johnpol, gaagaan, jeff, Robert.Olsson, kumarkr, rdreier,
peter.p.waskiewicz.jr, mcarlson, Patrick McHardy, netdev, general,
mchan, tgraf, randy.dunlap, sri, shemminger, David Miller,
herbert
In-Reply-To: <1191244900.4378.3.camel@localhost>
> jamal wrote:
>
> > > + while ((skb = __skb_dequeue(skbs)) != NULL)
> > > + q->ops->requeue(skb, q);
> >
> >
> > ->requeue queues at the head, so this looks like it would reverse
> > the order of the skbs.
>
> Excellent catch! thanks; i will fix.
>
> As a side note: Any batching driver should _never_ have to requeue; if
> it does it is buggy. And the non-batching ones if they ever requeue will
> be a single packet, so not much reordering.
On the contrary, batching LLTX drivers (if that is not ruled out) will very
often requeue resulting in heavy reordering. Fix looks good though.
- KK
^ permalink raw reply
* Re: [git patches] net driver updates
From: David Miller @ 2007-10-08 6:06 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-kernel
In-Reply-To: <20071005182008.GA17519@havoc.gtf.org>
From: Jeff Garzik <jeff@garzik.org>
Date: Fri, 5 Oct 2007 14:20:08 -0400
> Please pull from 'upstream-davem' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-davem
>
Pulled, and pushed back out to net-2.6.24, thanks Jeff.
^ permalink raw reply
* Re: [NET] IPv6 oops bisected
From: David Miller @ 2007-10-08 6:16 UTC (permalink / raw)
To: jeff; +Cc: dlunev, netdev, herbert, linux-kernel, akpm, den
In-Reply-To: <4708F387.1060602@garzik.org>
From: Jeff Garzik <jeff@garzik.org>
Date: Sun, 07 Oct 2007 10:56:07 -0400
> /etc/sysconfig/network-scripts/network-functions-ipv6: line 246: 1760 Killed
> LC_ALL=C /sbin/ip $options
>
>
> NULL pointer dereference at 0x000003f8
>
> backtrace:
> :ipv6:ip6_route_add+0x1b1/0x543
'dev' can be NULL in that code branch of ip6_route_add(),
yet we're deferencing it to get dev->nd_net.
if ((cfg->fc_flags & RTF_REJECT) ||
(dev && (dev->flags&IFF_LOOPBACK) && !(addr_type&IPV6_ADDR_LOOPBACK))) {
/* hold loopback dev/idev if we haven't done so. */
- if (dev != init_net.loopback_dev) {
+ if (dev != dev->nd_net->loopback_dev) {
I'll add the appropriate check for NULL as follows:
commit b3c1427c21f9bac4ceaa02e875f3b2c9a5592132
Author: David S. Miller <davem@sunset.davemloft.net>
Date: Sun Oct 7 23:15:56 2007 -0700
[IPV6]: Fix OOPS introduced by 5f5dace1ce001b24fb8286e09ffd3c4d2b547e09.
In ip6_add_route(), 'dev' can be NULL, so check that before
we try to deref dev->nd_net.
Based upon a crash report by Jeff Garzik.
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index a7db84c..7109ad6 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1188,7 +1188,7 @@ int ip6_route_add(struct fib6_config *cfg)
if ((cfg->fc_flags & RTF_REJECT) ||
(dev && (dev->flags&IFF_LOOPBACK) && !(addr_type&IPV6_ADDR_LOOPBACK))) {
/* hold loopback dev/idev if we haven't done so. */
- if (dev != dev->nd_net->loopback_dev) {
+ if (!dev || (dev != dev->nd_net->loopback_dev)) {
if (dev) {
dev_put(dev);
in6_dev_put(idev);
^ permalink raw reply related
* Re: [NET] IPv6 oops bisected
From: Herbert Xu @ 2007-10-08 6:19 UTC (permalink / raw)
To: David Miller; +Cc: jeff, dlunev, netdev, linux-kernel, akpm, den
In-Reply-To: <20071007.231608.104667710.davem@davemloft.net>
On Sun, Oct 07, 2007 at 11:16:08PM -0700, David Miller wrote:
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index a7db84c..7109ad6 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1188,7 +1188,7 @@ int ip6_route_add(struct fib6_config *cfg)
> if ((cfg->fc_flags & RTF_REJECT) ||
> (dev && (dev->flags&IFF_LOOPBACK) && !(addr_type&IPV6_ADDR_LOOPBACK))) {
> /* hold loopback dev/idev if we haven't done so. */
> - if (dev != dev->nd_net->loopback_dev) {
> + if (!dev || (dev != dev->nd_net->loopback_dev)) {
> if (dev) {
> dev_put(dev);
> in6_dev_put(idev);
Unfortunately this'll still oops a few lines down when it tries
to assign dev->nd_net->loopabck_dev to dev. The issue here is
which namespace are we in if dev is NULL.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [patch 0/2] [AF_IUCV] fixes for net-2.6.24
From: David Miller @ 2007-10-08 6:20 UTC (permalink / raw)
To: braunu; +Cc: netdev, linux-s390, heiko.carstens
In-Reply-To: <20071004144608.880229000@linux.vnet.ibm.com>
From: Ursula Braun <braunu@de.ibm.com>
Date: Thu, 04 Oct 2007 16:46:08 +0200
> the following 2 patches are intended for 2.6.24 and contain:
> - removal of static declarations in af_iucv header file
> - postpone receival of inbound packets in af_iucv
These patches don't apply, for one thing the first patch
rejects because the net-2.6.24 copy of include/net/iucv/af_iucv.h
has this line:
+static int iucv_sock_create(struct socket *sock, int proto);
but the file you are patching against does not.
Please generate new clean patches against net-2.6.24, thank you.
^ permalink raw reply
* Re: [NET] IPv6 oops bisected
From: David Miller @ 2007-10-08 6:23 UTC (permalink / raw)
To: herbert; +Cc: jeff, dlunev, netdev, linux-kernel, akpm, den
In-Reply-To: <20071008061942.GA842@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 8 Oct 2007 14:19:42 +0800
> On Sun, Oct 07, 2007 at 11:16:08PM -0700, David Miller wrote:
> >
> > diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> > index a7db84c..7109ad6 100644
> > --- a/net/ipv6/route.c
> > +++ b/net/ipv6/route.c
> > @@ -1188,7 +1188,7 @@ int ip6_route_add(struct fib6_config *cfg)
> > if ((cfg->fc_flags & RTF_REJECT) ||
> > (dev && (dev->flags&IFF_LOOPBACK) && !(addr_type&IPV6_ADDR_LOOPBACK))) {
> > /* hold loopback dev/idev if we haven't done so. */
> > - if (dev != dev->nd_net->loopback_dev) {
> > + if (!dev || (dev != dev->nd_net->loopback_dev)) {
> > if (dev) {
> > dev_put(dev);
> > in6_dev_put(idev);
>
> Unfortunately this'll still oops a few lines down when it tries
> to assign dev->nd_net->loopabck_dev to dev. The issue here is
> which namespace are we in if dev is NULL.
Good catch.
I'm just going to revert my bogus fix and the original change
for now. Denis can resubmit the original patch once this
is resolved.
^ permalink raw reply
* Re: [PATCH 1/4][TG3]: Walk PCI capability lists.
From: David Miller @ 2007-10-08 6:28 UTC (permalink / raw)
To: mchan; +Cc: netdev, andy, mcarlson
In-Reply-To: <1191641822.17453.6.camel@dell>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 05 Oct 2007 20:37:02 -0700
> [TG3]: Walk PCI capability lists.
>
> Newer tg3 devices shuffle around the registers in PCI configuration
> space. This patch changes the way the driver accesses the PCI
> capabilities registers. Hardcoded register locations are replaced with
> offsets from pci_find_capability() return values.
>
> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
This aspect of the driver always bugged me, but if these
capabilities would never move around in PCI config space
I was going to let sleeping dogs lie :-)
^ permalink raw reply
* Re: [PATCH 2/4][TG3]: ASIC decoding and basic CPMU support.
From: David Miller @ 2007-10-08 6:28 UTC (permalink / raw)
To: mchan; +Cc: netdev, andy, mcarlson
In-Reply-To: <1191641858.17453.7.camel@dell>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 05 Oct 2007 20:37:38 -0700
> [TG3]: ASIC decoding and basic CPMU support.
>
> Newer products change the way the ASIC revision is obtained. This patch
> implements how the driver will extract the revision number.
>
> This patch also adds preliminary CPMU support. CPMU stands for Central
> Power Management Unit. The CPMU's role is to put the chip into lower
> power states when the operating conditions allow it.
>
> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/4][TG3]: Add 5784 and 5764 support.
From: David Miller @ 2007-10-08 6:28 UTC (permalink / raw)
To: mchan; +Cc: netdev, andy, mcarlson
In-Reply-To: <1191641874.17453.8.camel@dell>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 05 Oct 2007 20:37:54 -0700
> [TG3]: Add 5784 and 5764 support.
>
> This patch adds the support for 5784 and 5764 devices.
>
> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH 4/4][TG3]: Update version to 3.82.
From: David Miller @ 2007-10-08 6:29 UTC (permalink / raw)
To: mchan; +Cc: netdev, andy, mcarlson
In-Reply-To: <1191641893.17453.9.camel@dell>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 05 Oct 2007 20:38:13 -0700
> [TG3]: Update version to 3.82.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Also applied, thanks Michael.
^ 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