* Re: [PATCH|[NET]: migrate HARD_TX_LOCK to header file
From: David Miller @ 2007-09-16 19:28 UTC (permalink / raw)
To: hadi; +Cc: netdev
In-Reply-To: <1189957725.4241.4.camel@localhost>
From: jamal <hadi@cyberus.ca>
Date: Sun, 16 Sep 2007 11:48:45 -0400
> I wanted to get rid of the extrenous cpu arguement and ended moving this
> to the header files since it looks common enough an operation that could
> be used elsewhere.
> It is a trivial change - i could resend with leaving it in dev.c and
> just getting rid of the cpu arguement.
The only reason the cpu argument is superfluous is because
we don't provide a way to pass it on down to netif_tx_lock().
So instead netif_tx_lock() recomputes that value in this case which is
extra unnecessary work.
I would instead suggest, in netdevice.h:
static inline void __netif_tx_lock(struct net_device *dev, int cpu)
{
spin_lock(&dev->_xmit_lock);
dev->xmit_lock_owner = cpu;
}
static inline void netif_tx_lock(struct net_device *dev)
{
__netif_tx_lock(dev, smp_processor_id());
}
And make the HARD_TX_LOCK() call __netif_tx_lock() and pass in
the already computed 'cpu' parameter.
Thanks.
^ permalink raw reply
* Re: [RFC][NET_SCHED] explict hold dev tx lock
From: David Miller @ 2007-09-16 19:31 UTC (permalink / raw)
To: hadi; +Cc: herbert, netdev, kaber, dada1, johnpol
In-Reply-To: <1189959274.4241.30.camel@localhost>
From: jamal <hadi@cyberus.ca>
Date: Sun, 16 Sep 2007 12:14:34 -0400
> Changes:
> I made changes to the code path as defined in the patch included to
> and noticed a slight increase (2-3%) in performance with both e1000 and
> tg3; which was a relief because i thought the spinlock_irq (which is
> needed because some drivers grab tx lock in interupts) may have negative
> effects. The fact it didnt reduce performance was a good thing.
> Note: This is the highest end machine ive ever laid hands on, so this
> may be misleading.
>
> So - what side effects do people see in doing this? If none, i will
> clean it up and submit.
I tried this 4 years ago, it doesn't work. :-)
Many drivers, particularly very old ones that PIO packets into
a device which can take a long time, absolutely depend upon
interrupts being enabled fully during ->hard_start_xmit()
so that other high periority devices (such as simpler serial
controllers) can have their interrupts serviced during this
slow operation.
I don't think we want to do it anyways, whatever performance
we gain from it is offset by the badness of disabling interrupts
during this reasonably length stretch of code.
The -rt folks as a result would notice this too and spank us :-)
^ permalink raw reply
* Re: e1000 driver and samba
From: Kok, Auke @ 2007-09-16 20:03 UTC (permalink / raw)
To: James Chapman; +Cc: Kok, Auke, L F, netdev
In-Reply-To: <46ED58AF.1070000@katalix.com>
James Chapman wrote:
> Kok, Auke wrote:
>> James Chapman wrote:
>>> Kok, Auke wrote:
>
>>>>> rx_long_byte_count: 34124849453
>>>
>>> Are these long frames expected in your network? What is the MTU of
>>> the transmitting clients? Perhaps this might explain why reads work
>>> (because data is coming from the Linux box so the packets have
>>> smaller MTU) while writes cause delays or packet loss because the
>>> clients are sending long frames which are getting fragmented?
>>
>> those are not "long frames" but the number of bytes the hardware
>> counted in its "long" data type based byte counter.
>
> Thanks for correcting me, Auke.
>
> Should this counter be renamed to avoid someone else making this mistake
> in the future? Just a thought.
well, that would break tools that read this value. And for all of these stats
we can say that you should read our SDM's to figure out what they really
mean anyway, hence my caution to interpret the other value at first.
Auke
^ permalink raw reply
* Re: [PATCH|[NET]: migrate HARD_TX_LOCK to header file
From: jamal @ 2007-09-16 20:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20070916.122842.59467739.davem@davemloft.net>
On Sun, 2007-16-09 at 12:28 -0700, David Miller wrote:
> The only reason the cpu argument is superfluous is because
> we don't provide a way to pass it on down to netif_tx_lock().
>
> So instead netif_tx_lock() recomputes that value in this case which is
> extra unnecessary work.
>
> I would instead suggest ..
sounds much better - will resend after a simple test.
cheers,
jamal
^ permalink raw reply
* Re: [RFC][NET_SCHED] explict hold dev tx lock
From: jamal @ 2007-09-16 20:41 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev, kaber, dada1, johnpol
In-Reply-To: <20070916.123158.92582301.davem@davemloft.net>
On Sun, 2007-16-09 at 12:31 -0700, David Miller wrote:
> From: jamal <hadi@cyberus.ca>
> Date: Sun, 16 Sep 2007 12:14:34 -0400
> > So - what side effects do people see in doing this? If none, i will
> > clean it up and submit.
>
> I tried this 4 years ago, it doesn't work. :-)
>
;->
[good reasons removed here]
> I don't think we want to do it anyways, whatever performance
> we gain from it is offset by the badness of disabling interrupts
> during this reasonably length stretch of code.
>
> The -rt folks as a result would notice this too and spank us :-)
indeed.
Ok, maybe i am thinking too hard with that patch, so help me out:->
When i looked at that code path as it is today: i felt the softirq could
be interupted on the same CPU it is running on while it already grabbed
that tx lock (if the trylock succeeds) and that the hardirq code when
attempting to grab the lock would result in a deadlock.
Did i misread that?
When i experimented with tg3 and e1000 i did not see any such problems
with the non irq version of the lock.
cheers,
jamal
^ permalink raw reply
* Re: [RFC][NET_SCHED] explict hold dev tx lock
From: jamal @ 2007-09-16 20:52 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev, kaber, dada1, johnpol
In-Reply-To: <1189975284.4230.14.camel@localhost>
On Sun, 2007-16-09 at 16:41 -0400, jamal wrote:
> indeed.
> Ok, maybe i am thinking too hard with that patch, so help me out:->
Ok, that was probably too much of an explanation. What i should say is
if i grabbed the lock explicitly without disabling irqs it wont be much
different than what is done today and should always work.
No?
cheers,
jamal
^ permalink raw reply
* Re: [PATCH|[NET]: migrate HARD_TX_LOCK to header file
From: jamal @ 2007-09-16 20:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1189974522.4230.3.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 155 bytes --]
On Sun, 2007-16-09 at 16:28 -0400, jamal wrote:
>
> sounds much better - will resend after a simple test.
Ok, heres the revised version
cheers,
jamal
[-- Attachment #2: htxp2 --]
[-- Type: text/plain, Size: 2433 bytes --]
[NET]: migrate HARD_TX_LOCK to header file
HARD_TX_LOCK micro is a nice aggregation that could be used
in other spots. move it to netdevice.h
Also makes sure the previously superflous cpu arguement is used.
Thanks to DaveM for the suggestions.
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
---
commit e467e3cb7fca9b533543aa749395547b7ade4980
tree 5e03a405e32968cc8e9e875ecdaeec4e798b6809
parent f55ad5bb4809bdd07720387c62788fad5359d41c
author Jamal Hadi Salim <hadi@cyberus.ca> Sun, 16 Sep 2007 16:54:44 -0400
committer Jamal Hadi Salim <hadi@cyberus.ca> Sun, 16 Sep 2007 16:54:44 -0400
include/linux/netdevice.h | 21 +++++++++++++++++++--
net/core/dev.c | 12 ------------
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index dc5e35f..d529a0c 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1265,10 +1265,15 @@ static inline void netif_rx_complete(struct net_device *dev,
*
* Get network device transmit lock
*/
-static inline void netif_tx_lock(struct net_device *dev)
+static inline void __netif_tx_lock(struct net_device *dev, int cpu)
{
spin_lock(&dev->_xmit_lock);
- dev->xmit_lock_owner = smp_processor_id();
+ dev->xmit_lock_owner = cpu;
+}
+
+static inline void netif_tx_lock(struct net_device *dev)
+{
+ __netif_tx_lock(dev, smp_processor_id());
}
static inline void netif_tx_lock_bh(struct net_device *dev)
@@ -1297,6 +1302,18 @@ static inline void netif_tx_unlock_bh(struct net_device *dev)
spin_unlock_bh(&dev->_xmit_lock);
}
+#define HARD_TX_LOCK(dev, cpu) { \
+ if ((dev->features & NETIF_F_LLTX) == 0) { \
+ __netif_tx_lock(dev, cpu); \
+ } \
+}
+
+#define HARD_TX_UNLOCK(dev) { \
+ if ((dev->features & NETIF_F_LLTX) == 0) { \
+ netif_tx_unlock(dev); \
+ } \
+}
+
static inline void netif_tx_disable(struct net_device *dev)
{
netif_tx_lock_bh(dev);
diff --git a/net/core/dev.c b/net/core/dev.c
index 2897352..a1f6ca6 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1574,18 +1574,6 @@ out_kfree_skb:
return 0;
}
-#define HARD_TX_LOCK(dev, cpu) { \
- if ((dev->features & NETIF_F_LLTX) == 0) { \
- netif_tx_lock(dev); \
- } \
-}
-
-#define HARD_TX_UNLOCK(dev) { \
- if ((dev->features & NETIF_F_LLTX) == 0) { \
- netif_tx_unlock(dev); \
- } \
-}
-
/**
* dev_queue_xmit - transmit a buffer
* @skb: buffer to transmit
^ permalink raw reply related
* Re: [RFC][NET_SCHED] explict hold dev tx lock
From: jamal @ 2007-09-16 21:10 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev, kaber, dada1, johnpol
In-Reply-To: <1189975939.4230.19.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 331 bytes --]
On Sun, 2007-16-09 at 16:52 -0400, jamal wrote:
> What i should say is
> if i grabbed the lock explicitly without disabling irqs it wont be much
> different than what is done today and should always work.
> No?
And to be more explicit, heres a patch using the macros from previous
patch. So far tested on 3 NICs.
cheers,
jamal
[-- Attachment #2: nsqr2 --]
[-- Type: text/x-patch, Size: 1204 bytes --]
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index e970e8e..1ae905e 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -134,34 +134,18 @@ static inline int qdisc_restart(struct net_device *dev)
{
struct Qdisc *q = dev->qdisc;
struct sk_buff *skb;
- unsigned lockless;
int ret;
/* Dequeue packet */
if (unlikely((skb = dev_dequeue_skb(dev, q)) == NULL))
return 0;
- /*
- * When the driver has LLTX set, it does its own locking in
- * start_xmit. These checks are worth it because even uncongested
- * locks can be quite expensive. The driver can do a trylock, as
- * is being done here; in case of lock contention it should return
- * NETDEV_TX_LOCKED and the packet will be requeued.
- */
- lockless = (dev->features & NETIF_F_LLTX);
-
- if (!lockless && !netif_tx_trylock(dev)) {
- /* Another CPU grabbed the driver tx lock */
- return handle_dev_cpu_collision(skb, dev, q);
- }
-
/* And release queue */
spin_unlock(&dev->queue_lock);
+ HARD_TX_LOCK(dev, smp_processor_id());
ret = dev_hard_start_xmit(skb, dev);
-
- if (!lockless)
- netif_tx_unlock(dev);
+ HARD_TX_UNLOCK(dev);
spin_lock(&dev->queue_lock);
q = dev->qdisc;
^ permalink raw reply related
* Re: [PATCH] tehuti: driver for Tehuti 10GbE network adapters
From: Andrew Morton @ 2007-09-16 21:14 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: jeff, davem, netdev, baum
In-Reply-To: <20070911164033.GA3754@gospo.rdu.redhat.com>
erp, changes in the net-2.6.24 tree breaks this.
drivers/net/tehuti.c: In function 'bdx_isr_napi':
drivers/net/tehuti.c:268: error: too few arguments to function 'netif_rx_schedule_prep'
drivers/net/tehuti.c:269: error: too few arguments to function '__netif_rx_schedule'
drivers/net/tehuti.c: In function 'bdx_poll':
drivers/net/tehuti.c:302: error: too few arguments to function 'netif_rx_complete'
drivers/net/tehuti.c: In function 'bdx_hw_start':
drivers/net/tehuti.c:414: error: implicit declaration of function 'netif_poll_enable'
drivers/net/tehuti.c: In function 'bdx_hw_stop':
drivers/net/tehuti.c:428: error: implicit declaration of function 'netif_poll_disable'
drivers/net/tehuti.c: In function 'bdx_rx_receive':
drivers/net/tehuti.c:1219: error: 'struct net_device' has no member named 'quota'
drivers/net/tehuti.c:1219: warning: type defaults to 'int' in declaration of '_y'
drivers/net/tehuti.c:1219: error: 'struct net_device' has no member named 'quota'
drivers/net/tehuti.c:1311: error: 'struct net_device' has no member named 'quota'
drivers/net/tehuti.c: In function 'bdx_probe':
drivers/net/tehuti.c:1994: error: 'struct net_device' has no member named 'poll'
drivers/net/tehuti.c:1995: error: 'struct net_device' has no member named 'weight'
drivers/net/tehuti.c:2058: error: implicit declaration of function 'SET_MODULE_OWNER'
There's a lot of churn in networking at present and I don't have time/inclination
to fix this one up, sorry.
^ permalink raw reply
* Re: ne driver crashes when unloaded in 2.6.22.6
From: Dan Williams @ 2007-09-16 21:14 UTC (permalink / raw)
To: Chris Rankin; +Cc: netdev
In-Reply-To: <343200.37246.qm@web52908.mail.re2.yahoo.com>
On Sat, 2007-09-15 at 21:27 +0100, Chris Rankin wrote:
> --- Dan Williams <dcbw@redhat.com> wrote:
> > On Wed, 2007-09-12 at 19:23 +0100, Chris Rankin wrote:
> > > Hmm, apparently not. The light on the card goes out though, so could this just be a lack of
> > driver
> > > support?
> >
> > Likely, yes.
>
> I've been trawling the Internet for 8390 specifications and have discovered that there is a
> "Carrier Sense Loss" flag on the "Transmit Status Register". However, there doesn't seem to be an
> explicit "media status" test. Would this more likely be part of the NE2000's functionality? I
> can't find any signs of MII support, but then the NE2000 is so heavily cloned that
> "NE2000-compatible" seems to have become more of a generic description these days.
>
> Does anyone have any ideas, please? Does NetworkManager even need full carrier-detection support?
NM needs it if you want the interface to be automatically handled in
0.6.x and earlier. In 0.7.x and later you'll be able to have NM just
set up the interface even if it doesn't have a link (if you set it to
autoconnect), but of course that means that whenever you start NM the
interface will be up with the settings you specify because, of course,
NM can't automatically figure out when the card is up or down and do
something intelligent.
dan
^ permalink raw reply
* Re: [PATCH|[NET]: migrate HARD_TX_LOCK to header file
From: David Miller @ 2007-09-16 21:41 UTC (permalink / raw)
To: hadi; +Cc: netdev
In-Reply-To: <1189976234.4230.22.camel@localhost>
From: jamal <hadi@cyberus.ca>
Date: Sun, 16 Sep 2007 16:57:14 -0400
> On Sun, 2007-16-09 at 16:28 -0400, jamal wrote:
>
> >
> > sounds much better - will resend after a simple test.
>
> Ok, heres the revised version
Applied, thanks Jamal.
^ permalink raw reply
* Re: [PATCH] IPV6: fix source address selection
From: David Miller @ 2007-09-16 21:49 UTC (permalink / raw)
To: jkosina; +Cc: nhorman, netdev, jbohac, pasky
In-Reply-To: <Pine.LNX.4.64.0709130044300.7343@jikos.suse.cz>
From: Jiri Kosina <jkosina@suse.cz>
Date: Thu, 13 Sep 2007 00:56:00 +0200 (CEST)
> From: Jiri Kosina <jkosina@suse.cz>
>
> [PATCH] IPV6: fix source address selection
>
> The commit 95c385 broke proper source address selection for cases in which
> there is a address which is makred 'deprecated'. The commit mistakenly
> changed ifa->flags to ifa_result->flags (probably copy/paste error from a
> few lines above) in the 'Rule 3' address selection code.
>
> The patch below restores the previous RFC-compliant behavior, please
> apply.
>
> Cc: Jiri Bohac <jbohac@suse.cz>
> Cc: Petr Baudis <pasky@suse.cz>
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Excellent catch Jiri.
I'll apply this and push to -stable as well.
Thanks a lot!
^ permalink raw reply
* Re: [PATCH] net: Fix the prototype of call_netdevice_notifiers
From: David Miller @ 2007-09-16 22:33 UTC (permalink / raw)
To: ebiederm; +Cc: netdev, containers
In-Reply-To: <m1y7fa5zg6.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 13 Sep 2007 09:59:05 -0600
>
> This replaces the void * parameter with a struct net_device * which
> is what is actually required.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Applied to net-2.6.24, thanks Eric.
^ permalink raw reply
* Re: Network Namespace status
From: David Miller @ 2007-09-16 22:36 UTC (permalink / raw)
To: ebiederm; +Cc: containers, netdev, htejun, gregkh, akpm
In-Reply-To: <m18x7a5qif.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 13 Sep 2007 13:12:08 -0600
> The final blocker to having multiple useful instances of network
> namespaces is the loopback device. We recognize the network namespace
> of incoming packets by looking at dev->nd_net. Which means for
> packets to properly loopback within a network namespace we need a
> loopback device per network namespace. There were some concerns
> expressed when we posted the cleanup part of the patches that allowed
> for multiple loopback devices a few weeks ago so resolving this one
> may be tricky.
There was a change posted recently to dynamically allocate the
loopback device. I like that (sorry I don't have a reference
to the patch handy), and you can build on top of that to get
the namespace local loopback objects you want.
static struct net_device *loopback_dev(struct net_namespace *net)
{
...
}
You get the idea.
^ permalink raw reply
* Re: [PATCH][NETNS] Consolidate hashes creation in netdev_init()
From: David Miller @ 2007-09-16 22:40 UTC (permalink / raw)
To: xemul; +Cc: ebiederm, netdev, containers, devel, dlezcano
In-Reply-To: <46EA4911.9070401@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Fri, 14 Sep 2007 12:40:49 +0400
> The dev_name_hash and the dev_index_hash are now booth kmalloc-ed
> (and each element is properly initialized as usually) so I think
> it's worth consolidating this code making it look nicer (and
> saving 28 bytes of .text section ;) )
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied to net-2.6.24, thanks Pavel.
^ permalink raw reply
* Re: [PATCH] Cleanup calling netdev notifiers
From: David Miller @ 2007-09-16 22:43 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <46EA63AE.3070100@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Fri, 14 Sep 2007 14:34:22 +0400
> The call_netdev_notifiers routine can successfully be used in
> the net/core_dev.c itself.
>
> This will save 6 lines of code and 62 ;) bytes of .text section.
>
> 62 is rather small, but I have one more patch saving ~30 bytes
> from netns code (sent to Eric), so altogether they can save
> some more noticeable amount.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied to net-2.6.24, thanks Pavel.
^ permalink raw reply
* Re: [PATCH] small cleanup for fib rules
From: David Miller @ 2007-09-16 22:46 UTC (permalink / raw)
To: den; +Cc: kuznet, netdev, devel, dev
In-Reply-To: <20070914110647.GA7369@iris.sw.ru>
From: "Denis V. Lunev" <den@openvz.org>
Date: Fri, 14 Sep 2007 15:06:47 +0400
> From: Denis V. Lunev <den@openvz.org>
>
> This patch slightly cleanups FIB rules framework. rules_list as a pointer
> on struct fib_rules_ops is useless. It is always assigned with a static
> per/subsystem list in IPv4, IPv6 and DecNet.
>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> Acked-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
I am convinced you namespace guys will eventually eliminate
every single global variable in the kernel :-)
Patch applied to net-2.6.24, thanks!
^ permalink raw reply
* Re: [v2 PATCH for 2.6.24] SCTP: Implement the Supported Extensions Parameter
From: David Miller @ 2007-09-16 22:55 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: netdev, lksctp-developers
In-Reply-To: <11897091493925-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Thu, 13 Sep 2007 14:45:49 -0400
> [... i can't seem to spell to save my life lately...]
>
> SCTP Supported Extenions parameter is specified in Section 4.2.7
> of the ADD-IP draft (soon to be RFC). The parameter is
> encoded as:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Parameter Type = 0x8008 | Parameter Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | CHUNK TYPE 1 | CHUNK TYPE 2 | CHUNK TYPE 3 | CHUNK TYPE 4 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | .... |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | CHUNK TYPE N | PAD | PAD | PAD |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> It contains a list of chunks that a particular SCTP extension
> uses. Current extensions supported are Partial Reliability
> (FWD-TSN) and ADD-IP (ASCONF and ASCONF-ACK).
>
> When implementing new extensions (AUTH, PKT-DROP, etc..), new
> chunks need to be added to this parameter. Parameter processing
> would be modified to negotiate support for these new features.
>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied to net-2.6.24, thanks Vlad.
^ permalink raw reply
* Re: [v3 PATCH 0/2] Add RCU locking to SCTPaddress management
From: David Miller @ 2007-09-16 23:01 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: netdev, lksctp
In-Reply-To: <11897120771278-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Thu, 13 Sep 2007 15:34:35 -0400
> Thanks to Sridhar Samudral and Paul McKenney for all the help and comments.
> I think this is a final version, unless someone else can spot more problems.
> I've ran this under heavy load and it the patches behaves well.
>
> I think patch 1 is a candidate for 2.6.23 since it fixes a bug, but splitting
> these seems a bit odd to me. I'll leave it to DaveM to decide where to
> put them.
Since you tested this well, I've decided to put both of these
patches into net-2.6
I agree it's stupid to split them up.
There'll be some merge hassles when I rebase net-2.6.24, but
that tree is such a monster that this is inevitable for every
bug fix I queue up for 2.6.23 :-)
^ permalink raw reply
* Re: [PATCH for 2.6.24] SCTP: Move sysctl_sctp_[rw]mem definitions to protocol.c
From: David Miller @ 2007-09-16 23:05 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: netdev, lksctp-developers
In-Reply-To: <46E9A5B1.5070202@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Thu, 13 Sep 2007 17:03:45 -0400
> The sctp_[rw]mem definitions should really be in protocol.c
> since that is where they are initialized. This also allows
> one to build a kernel without sysctl support.
>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied to net-2.6.24, thanks Vlad.
^ permalink raw reply
* [ofa-general] Re: [PATCH 0/10 REV5] Implement skb batching and support in IPoIB/E1000
From: David Miller @ 2007-09-16 23:17 UTC (permalink / raw)
To: krkumar2
Cc: johnpol, jagana, peter.p.waskiewicz.jr, kumarkr, herbert, gaagaan,
Robert.Olsson, netdev, rdreier, hadi, mcarlson, jeff, general,
mchan, tgraf, randy.dunlap, sri, shemminger, kaber
In-Reply-To: <20070914090058.17589.80352.sendpatchset@K50wks273871wss.in.ibm.com>
From: Krishna Kumar <krkumar2@in.ibm.com>
Date: Fri, 14 Sep 2007 14:30:58 +0530
> This set of patches implements the batching xmit capability, and
> adds support for batching in IPoIB and E1000 (E1000 driver changes
> is ported, thanks to changes taken from Jamal's code from an old
> kernel).
The only major complaint I have about this patch series is that
the IPoIB part should just be one big changeset. Otherwise the
tree is not bisectable, for example the initial ipoib header file
change breaks the build.
The tree must compile and work properly after every single patch.
On a lower priority, I question the indirection of skb_blist by making
it a pointer. For what? Saving 12 bytes on 64-bit? That kmalloc()'d
thing is a nearly guarenteed cache and/or TLB miss. Just inline the
thing, we generally don't do crap like this anywhere else.
^ permalink raw reply
* Re: [PATCH 1/7] [PPP] pppoe: Fix skb_unshare_check call position
From: David Miller @ 2007-09-16 23:19 UTC (permalink / raw)
To: herbert; +Cc: jchapman, mostrows, paulus, toralf.foerster, netdev
In-Reply-To: <E1IR2Uj-0007MU-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 31 Aug 2007 17:08:49 +0800
> [PPP] pppoe: Fix skb_unshare_check call position
>
> The skb_unshare_check call needs to be made before pskb_may_pull,
> not after.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Patch applied, thanks Herbert.
^ permalink raw reply
* Re: [PATCH 2/7] [PPP] pppoe: Fix data clobbering in __pppoe_xmit and return value
From: David Miller @ 2007-09-16 23:20 UTC (permalink / raw)
To: herbert; +Cc: jchapman, mostrows, paulus, toralf.foerster, netdev
In-Reply-To: <E1IR2Uy-0007Ms-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 31 Aug 2007 17:09:04 +0800
> [PPP] pppoe: Fix data clobbering in __pppoe_xmit and return value
>
> The function __pppoe_xmit modifies the skb data and therefore it needs
> to copy and skb data if it's cloned.
>
> In fact, it currently allocates a new skb so that it can return 0 in
> case of error without freeing the original skb. This is totally wrong
> because returning zero is meant to indicate congestion whereupon pppoe
> is supposed to wake up the upper layer once the congestion subsides.
>
> This makes sense for ppp_async and ppp_sync but is out-of-place for
> pppoe. This patch makes it always return 1 and free the skb.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks Herbert.
^ permalink raw reply
* Re: [PATCH 3/7] [PPP] pppoe: Fill in header directly in __pppoe_xmit
From: David Miller @ 2007-09-16 23:20 UTC (permalink / raw)
To: herbert; +Cc: jchapman, mostrows, paulus, toralf.foerster, netdev
In-Reply-To: <E1IR2V6-0007N6-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 31 Aug 2007 17:09:12 +0800
> [PPP] pppoe: Fill in header directly in __pppoe_xmit
>
> This patch removes the hdr variable (which is copied into the skb)
> and instead sets the header directly in the skb.
>
> It also uses __skb_push instead of skb_push since we've just checked
> using skb_cow for enough head room.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks Herbert.
^ permalink raw reply
* Re: [PATCH 4/7] [BRIDGE]: Kill clone argument to br_flood_*
From: David Miller @ 2007-09-16 23:21 UTC (permalink / raw)
To: herbert; +Cc: jchapman, mostrows, paulus, toralf.foerster, netdev
In-Reply-To: <E1IR2V8-0007NE-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 31 Aug 2007 17:09:14 +0800
> [BRIDGE]: Kill clone argument to br_flood_*
>
> The clone argument is only used by one caller and that caller can clone
> the packet itself. This patch moves the clone call into the caller and
> kills the clone argument.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks Herbert.
^ 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