* [ofa-general] Re: [PATCH 1/4] [NET_SCHED] explict hold dev tx lock
From: jamal @ 2007-09-25 22:14 UTC (permalink / raw)
To: Stephen Hemminger
Cc: johnpol, kumarkr, herbert, gaagaan, Robert.Olsson, netdev,
rdreier, Waskiewicz Jr, Peter P, mcarlson, kaber, randy.dunlap,
jagana, general, mchan, tgraf, jeff, sri, David Miller
In-Reply-To: <20070925082457.6fec30d6@freepuppy.rosehill>
On Tue, 2007-25-09 at 08:24 -0700, Stephen Hemminger wrote:
> The transmit code path is locked as a code region, rather than just object locking
> on the transmit queue or other fine grained object. This leads to moderately long
> lock hold times when multiple qdisc's and classification is being done.
It will be pretty tricky to optimize that path given the dependencies
between the queues, classifiers, and actions in enqueues; schedulers in
dequeues as well as their config/queries from user space which could
happen concurently on all "N" CPUs.
The txlock optimization i added in patch1 intends to let go of the queue
lock when we enter the dequeue region sooner to reduce the contention.
A further optimization i made was to reduce the time it takes to hold
the tx lock at the driver by moving gunk that doesnt need lock-holding
into the new method dev->hard_end_xmit() (refer to patch #2)
> If we went to finer grain locking it would also mean changes to all network
> devices using the new locking model. My assumption is that we would use
> something like the features flag to do the transition for backward compatibility.
> Take this as a purely "what if" or "it would be nice if" kind of suggestion
> not a requirement or some grand plan.
Ok, hopefully someone would demonstrate how to achieve it; seems a hard
thing to achieve.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH: 2.6.13-15-SMP 3/3] network: concurrently runsoftirqnetwork code on SMP
From: jamal @ 2007-09-25 22:22 UTC (permalink / raw)
To: Stephen Hemminger
Cc: john ye, David Miller, netdev, kuznet, pekkas, jmorris, kaber,
iceburgue
In-Reply-To: <20070925090333.11beebb2@freepuppy.rosehill>
On Tue, 2007-25-09 at 09:03 -0700, Stephen Hemminger wrote:
> There is a standard hash called RSS, that many drivers support because it is
> used by other operating systems.
I think any stateless/simple thing will do (something along the lines
what 802.1ad does for trunk, a 5 classical five tuple etc).
Having solved the reordering problem in such a stateless way introduces
a loadbalancing setback; you may end sending all your packets to one cpu
(a problem Mr Ye didnt have when he was re-orderding ;->).
cheers,
jamal
^ permalink raw reply
* [ofa-general] Re: [DOC] Net batching driver howto
From: jamal @ 2007-09-25 22:28 UTC (permalink / raw)
To: Randy Dunlap
Cc: johnpol, peter.p.waskiewicz.jr, kumarkr, herbert, Jeff Garzik,
Robert.Olsson, netdev, rdreier, mcarlson, David Miller, gaagaan,
jagana, general, mchan, tgraf, sri, shemminger, kaber
In-Reply-To: <20070925131620.617794ae.randy.dunlap@oracle.com>
On Tue, 2007-25-09 at 13:16 -0700, Randy Dunlap wrote:
> On Mon, 24 Sep 2007 18:54:19 -0400 jamal wrote:
>
> > I have updated the driver howto to match the patches i posted yesterday.
> > attached.
>
> Thanks for sending this.
Thank you for reading it Randy.
> This is an early draft, right?
Its a third revision - but you could call it early. When it is done, i
will probably put a pointer to it in some patch.
> I'll fix some typos etc. in it (patch attached) and add some whitespace.
> Please see RD: in the patch for more questions/comments.
Thanks, will do and changes will show up in the next update.
> IMO it needs some changes to eliminate words like "we", "you",
> and "your" (words that personify code). Those words are OK
> when talking about yourself.
The narrative intent is supposed to be i (or someone doing the
description) sitting there with a pen and paper and maybe a laptop and
walking through the details with someone who needs to understand those
details. If you think it is important to make it formal, then by all
means be my guest.
Again, thanks for taking the time.
cheers,
jamal
^ permalink raw reply
* [ofa-general] Re: [PATCH 1/4] [NET_SCHED] explict hold dev tx lock
From: jamal @ 2007-09-25 22:43 UTC (permalink / raw)
To: Stephen Hemminger
Cc: johnpol, kumarkr, herbert, gaagaan, Robert.Olsson, netdev,
rdreier, Waskiewicz Jr, Peter P, mcarlson, kaber, randy.dunlap,
jagana, general, mchan, tgraf, jeff, sri, David Miller
In-Reply-To: <1190758491.4244.15.camel@localhost>
On Tue, 2007-25-09 at 18:15 -0400, jamal wrote:
> A further optimization i made was to reduce the time it takes to hold
> the tx lock at the driver by moving gunk that doesnt need lock-holding
> into the new method dev->hard_end_xmit() (refer to patch #2)
Sorry, that should have read dev->hard_prep_xmit()
cheers,
jamal
^ permalink raw reply
* [PATCH] mv643xx_eth: duplicate methods in initializer
From: Al Viro @ 2007-09-26 0:53 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, netdev
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
drivers/net/mv643xx_eth.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index 6a117e9..456d1e1 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -2768,8 +2768,6 @@ static const struct ethtool_ops mv643xx_ethtool_ops = {
.get_stats_count = mv643xx_get_stats_count,
.get_ethtool_stats = mv643xx_get_ethtool_stats,
.get_strings = mv643xx_get_strings,
- .get_stats_count = mv643xx_get_stats_count,
- .get_ethtool_stats = mv643xx_get_ethtool_stats,
.nway_reset = mv643xx_eth_nway_restart,
};
--
1.5.3.GIT
^ permalink raw reply related
* Re: [PATCH: 2.6.13-15-SMP 3/3] network: concurrentlyrunsoftirqnetwork code on SMP
From: John Ye @ 2007-09-26 2:12 UTC (permalink / raw)
To: hadi, Stephen Hemminger
Cc: David Miller, netdev, kuznet, pekkas, jmorris, kaber, iceburgue
In-Reply-To: <1190758944.4244.23.camel@localhost>
Jamal & Stephen,
I found BSS-hash paper you mentioned and have browsed it briefly.
The issue "may end sending all your packets to one cpu" might be dealt with
by
cpu hash (srcip + dstip) % nr_cpus, plus checking cpu balance periodically,
shift cpu by an extra seed value?
Any way, the cpu hash code must not be too expensive because every incoming
packet hits the path.
We are going to do further study on this BSS thing.
__do_IRQ has a tendency to collect same IRQ on different CPUs into one CPU
when NIC is busy(by IRQ_PENDING & IRQ_INPROGRESS control skill). so,
dispatch the load to SMP here may be good thing(?).
Thanks.
John Ye
----- Original Message -----
From: "jamal" <hadi@cyberus.ca>
To: "Stephen Hemminger" <shemminger@linux-foundation.org>
Cc: "john ye" <johny@asimco.com.cn>; "David Miller" <davem@davemloft.net>;
<netdev@vger.kernel.org>; <kuznet@ms2.inr.ac.ru>; <pekkas@netcore.fi>;
<jmorris@namei.org>; <kaber@coreworks.de>; <iceburgue@gmail.com>
Sent: Wednesday, September 26, 2007 6:22 AM
Subject: Re: [PATCH: 2.6.13-15-SMP 3/3] network:
concurrentlyrunsoftirqnetwork code on SMP
> On Tue, 2007-25-09 at 09:03 -0700, Stephen Hemminger wrote:
>
> > There is a standard hash called RSS, that many drivers support because
it is
> > used by other operating systems.
>
> I think any stateless/simple thing will do (something along the lines
> what 802.1ad does for trunk, a 5 classical five tuple etc).
>
> Having solved the reordering problem in such a stateless way introduces
> a loadbalancing setback; you may end sending all your packets to one cpu
> (a problem Mr Ye didnt have when he was re-orderding ;->).
>
> cheers,
> jamal
>
>
^ permalink raw reply
* Re: [net-2.6.24][patch 2/2] Dynamically allocate the loopback device
From: David Miller @ 2007-09-26 2:24 UTC (permalink / raw)
To: ebiederm
Cc: pjwaskiewicz, dlezcano, shemminger, netdev, containers,
benjamin.thery
In-Reply-To: <m1r6kwpu9t.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Mon, 17 Sep 2007 20:44:14 -0600
> David Miller <davem@davemloft.net> writes:
>
> > From: "Peter Waskiewicz" <pjwaskiewicz@gmail.com>
> > Date: Mon, 17 Sep 2007 12:12:24 -0700
> >
> >> This would be a good opportunity to remove the single-allocated queue struct
> >> in netdevice (at the bottom) that we had to put in to accomodate the static
> >> loopback. Now we can set it back to a zero element list, and have
> >> alloc_netdev_mq() just allocate the number of queues requested, not
> >> num_queues - 1.
> >>
> >> I'll put a patch together based on this patchset.
> >
> > Thanks Peter.
> >
> > I'll also let this sit so that Eric can provide any feedback
> > he wants and also figure out how he will use this for the
> > namespace stuff.
>
> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
> Not that it doesn't already have my signed off by.
I've put these patches into the just-rebased net-2.6.24 tree.
I made a minor modification to the second patch, the
out_free_netdev: code in loopback_init() ended like this:
out_free_netdev:
free_netdev(dev);
goto out;
return err;
};
I got rid of the spurious return statement and the trailing
semi-colon after the function closing brace.
Thanks.
^ permalink raw reply
* Re: [PATCH 0/3] move hardware header functions out of netdevice
From: David Miller @ 2007-09-26 2:24 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20070824204310.388073598@linux-foundation.org>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Fri, 24 Aug 2007 13:43:10 -0700
> The follow patches series starts the process of moving function
> pointers out of network device structure. This saves space and
> separates code from data.
>
> The first step is moving the functions dealing with hardware
> headers.
>
> Patches are against current net-2.6.24 tree. Basic functional
> testing on ethernet part, not on all the other protocols affected.
Stephen, can you respin these against net-2.6.24 and resubmit?
Thanks!
^ permalink raw reply
* Re: [RFC][NET_SCHED] explict hold dev tx lock
From: David Miller @ 2007-09-26 2:28 UTC (permalink / raw)
To: hadi; +Cc: herbert, netdev, kaber, dada1, johnpol
In-Reply-To: <1190256183.4818.28.camel@localhost>
From: jamal <hadi@cyberus.ca>
Date: Wed, 19 Sep 2007 22:43:03 -0400
> [NET_SCHED] explict hold dev tx lock
>
> For N cpus, with full throttle traffic on all N CPUs, funneling traffic
> to the same ethernet device, the devices queue lock is contended by all
> N CPUs constantly. The TX lock is only contended by a max of 2 CPUS.
> In the current mode of operation, after all the work of entering the
> dequeue region, we may endup aborting the path if we are unable to get
> the tx lock and go back to contend for the queue lock. As N goes up,
> this gets worse.
>
> The changes in this patch result in a small increase in performance
> with a 4CPU (2xdual-core) with no irq binding. Both e1000 and tg3
> showed similar behavior;
>
> Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
I've applied this to net-2.6.24, although I want to study more deeply
the implications of this change myself at some point :)
^ permalink raw reply
* Re: [PATCH - net-2.6.24 0/2] Introduce and use print_ip and print_ipv6
From: David Miller @ 2007-09-26 2:29 UTC (permalink / raw)
To: joe; +Cc: netdev, jgarzik, akpm
In-Reply-To: <1190271211.26101.91.camel@localhost>
From: Joe Perches <joe@perches.com>
Date: Wed, 19 Sep 2007 23:53:31 -0700
> In the same vein as print_mac, the implementations
> introduce declaration macros:
I'm going to hold on this for now, there is no universal
agreement that this is something we want to do and I'd
like to take care of getting the more certain stuff into
net-2.6.24 before "iffy" bits like this one.
Thanks.
^ permalink raw reply
* Re: [patch 1/1] revert "8139too: clean up I/O remapping"
From: David Miller @ 2007-09-26 2:30 UTC (permalink / raw)
To: jeff; +Cc: akpm, michal.k.k.piotrowski, netdev
In-Reply-To: <46F2DF03.1060501@garzik.org>
From: Jeff Garzik <jeff@garzik.org>
Date: Thu, 20 Sep 2007 16:58:43 -0400
> akpm@linux-foundation.org wrote:
> > From: Andrew Morton <akpm@linux-foundation.org>
> >
> > Revert git-netdev-all's 9ee6b32a47b9abc565466a9c3b127a5246b452e5. Michal was
> > getting oopses.
> >
> > Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> > Cc: Jeff Garzik <jeff@garzik.org>
> > Cc: David S. Miller" <davem@davemloft.net>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > ---
> >
> > drivers/net/8139too.c | 50 +++++++++++++++++++++++-----------------
> > 1 file changed, 29 insertions(+), 21 deletions(-)
>
> ACK -- DaveM, please remove or revert this patch.
>
I've reverted this patch during the net-2.6.24 rebase I'm
working on today.
^ permalink raw reply
* Re: Please pull 'iwlwifi' branch of wireless-2.6
From: David Miller @ 2007-09-26 2:31 UTC (permalink / raw)
To: linville; +Cc: yi.zhu, hch, jeff, netdev, linux-wireless
In-Reply-To: <20070921013403.GA3170@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 20 Sep 2007 21:34:03 -0400
> On Fri, Sep 21, 2007 at 09:20:30AM +0800, Zhu Yi wrote:
> > On Wed, 2007-09-19 at 11:13 +0100, Christoph Hellwig wrote:
> > > it really needs to be moved into a directory of it's own.
> >
> > It used to be... John?
>
> Fine by me -- I guess I misinterpreted the some other statements to
> make me think we wanted as flat a directory structure as possible.
I've taken care of this during the net-2.6.24 rebase I'm working
on today.
^ permalink raw reply
* Re: [PATCH] note that NETIF_F_LLTX is deprecated
From: David Miller @ 2007-09-26 2:42 UTC (permalink / raw)
To: herbert; +Cc: borntraeger, jeff, netdev
In-Reply-To: <20070922005709.GA17022@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 22 Sep 2007 08:57:10 +0800
> On Fri, Sep 21, 2007 at 04:59:54PM +0200, Christian Borntraeger wrote:
> >
> > I suggest to document that LLTX is deprecated.
> >
> > Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>
> This looks good to me.
To me too, applied to net-2.6.24, thanks.
^ permalink raw reply
* Re: Please pull 'fixes-davem' branch of wireless-2.6 (for 2.6.23)
From: David Miller @ 2007-09-26 2:44 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20070922154142.GA4738-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Sat, 22 Sep 2007 11:41:42 -0400
> These are a few more minor fixes that I would like to have in 2.6.23 if
> at all possible.
I've pulled these into my net-2.6 tree and will push to
Linus, thanks!
^ permalink raw reply
* Re: [RFC] Zero-length write() does not generate a datagram on connected socket
From: Herbert Xu @ 2007-09-26 3:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20070924153435.14249225@freepuppy.rosehill>
Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> The bug http://bugzilla.kernel.org/show_bug.cgi?id=5731
> describes an issue where write() can't be used to generate a zero-length
> datagram (but send, and sendto do work).
>
> I think the following is needed:
>
> --- a/net/socket.c 2007-08-20 09:54:28.000000000 -0700
> +++ b/net/socket.c 2007-09-24 15:31:25.000000000 -0700
> @@ -777,8 +777,11 @@ static ssize_t sock_aio_write(struct kio
> if (pos != 0)
> return -ESPIPE;
>
> - if (iocb->ki_left == 0) /* Match SYS5 behaviour */
> - return 0;
> + if (unlikely(iocb->ki_left == 0)) {
> + struct socket *sock = iocb->ki_filp->private_data;
> + if (sock->type == SOCK_STREAM)
> + return 0;
> + }
I'm not sure whether all STREAM protocols treat zero-length
sends as no-ops. What about SCTP?
Put it another way, do we really need to keep the short-circuit
for SOCK_STREAM?
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 - net-2.6.24 0/2] Introduce and use print_ip and print_ipv6
From: Joe Perches @ 2007-09-26 4:36 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jgarzik, akpm
In-Reply-To: <20070925.192917.21908774.davem@davemloft.net>
On Tue, 2007-09-25 at 19:29 -0700, David Miller wrote:
> I'm going to hold on this for now, there is no universal
> agreement that this is something we want to do and I'd
> like to take care of getting the more certain stuff into
> net-2.6.24 before "iffy" bits like this one.
Here's an argument for inclusion:
defconfig without patches:
$ size vmlinux
text data bss dec hex filename
4738370 518986 622592 5879948 59b88c vmlinux
defconfig with patches:
$ size vmlinux
text data bss dec hex filename
4735238 518986 622592 5876816 59ac50 vmlinux
cheers, Joe
^ permalink raw reply
* Re: [PATCH - net-2.6.24 0/2] Introduce and use print_ip and print_ipv6
From: David Miller @ 2007-09-26 5:11 UTC (permalink / raw)
To: joe; +Cc: netdev, jgarzik, akpm
In-Reply-To: <1190781398.17052.18.camel@localhost>
From: Joe Perches <joe@perches.com>
Date: Tue, 25 Sep 2007 21:36:38 -0700
> On Tue, 2007-09-25 at 19:29 -0700, David Miller wrote:
> > I'm going to hold on this for now, there is no universal
> > agreement that this is something we want to do and I'd
> > like to take care of getting the more certain stuff into
> > net-2.6.24 before "iffy" bits like this one.
>
> Here's an argument for inclusion:
>
> defconfig without patches:
Sure, but this ignores certain things that text/data/bss
size don't show you.
For one thing, stack frames might now be larger in the
functions where the new variables get added, even if they
aren't used to print out the debugging message. And that
could have negative performance implications.
Nothing is every black and white, everything is gray :-)
^ permalink raw reply
* Re: [PATCH - net-2.6.24 0/2] Introduce and use print_ip and print_ipv6
From: Jeff Garzik @ 2007-09-26 5:18 UTC (permalink / raw)
To: David Miller; +Cc: joe, netdev, akpm
In-Reply-To: <20070925.221115.26296263.davem@davemloft.net>
David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Tue, 25 Sep 2007 21:36:38 -0700
>
>> On Tue, 2007-09-25 at 19:29 -0700, David Miller wrote:
>>> I'm going to hold on this for now, there is no universal
>>> agreement that this is something we want to do and I'd
>>> like to take care of getting the more certain stuff into
>>> net-2.6.24 before "iffy" bits like this one.
>> Here's an argument for inclusion:
>>
>> defconfig without patches:
>
> Sure, but this ignores certain things that text/data/bss
> size don't show you.
size(1) output also ignores the merge noise this creates, and IMO we've
got a lot of that already...
Jeff
^ permalink raw reply
* Re: [RFC] Zero-length write() does not generate a datagram on connected socket
From: Stephen Hemminger @ 2007-09-26 5:36 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <E1IaNQ7-0004DX-00@gondolin.me.apana.org.au>
On Wed, 26 Sep 2007 11:18:39 +0800
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> > The bug http://bugzilla.kernel.org/show_bug.cgi?id=5731
> > describes an issue where write() can't be used to generate a zero-length
> > datagram (but send, and sendto do work).
> >
> > I think the following is needed:
> >
> > --- a/net/socket.c 2007-08-20 09:54:28.000000000 -0700
> > +++ b/net/socket.c 2007-09-24 15:31:25.000000000 -0700
> > @@ -777,8 +777,11 @@ static ssize_t sock_aio_write(struct kio
> > if (pos != 0)
> > return -ESPIPE;
> >
> > - if (iocb->ki_left == 0) /* Match SYS5 behaviour */
> > - return 0;
> > + if (unlikely(iocb->ki_left == 0)) {
> > + struct socket *sock = iocb->ki_filp->private_data;
> > + if (sock->type == SOCK_STREAM)
> > + return 0;
> > + }
>
> I'm not sure whether all STREAM protocols treat zero-length
> sends as no-ops. What about SCTP?
>
> Put it another way, do we really need to keep the short-circuit
> for SOCK_STREAM?
>
> Cheers,
Stream is defined as sequence of bytes. So short circuit makes sense
If the application wants message boundaries it needs to use SOCK_SEQPACKET.
I was paranoid about possible breakage in TCP or SCTP. But since
send(s, buf, 0, 0) already filters through, I guess it doesn't matter.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: Please pull 'upstream-davem' branch of wireless-2.6 (for 2.6.24)
From: David Miller @ 2007-09-26 5:38 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: jeff-o2qLIJkoznsdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20070922195457.GA22629-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Sat, 22 Sep 2007 15:54:57 -0400
> The individual patches are available here:
>
> http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-davem/
I sucked these into my net-2.6.24 tree, thanks John.
It may look slightly different because I applied the iwlwifi
CFLAGS Makefile patch directly from Intel and I did the
iwlwifi directory source move on my own.
Thanks!
^ permalink raw reply
* Re: [PATCH 1/3] [TCP]: Re-place highest_sack check to a more robust position
From: David Miller @ 2007-09-26 5:44 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev
In-Reply-To: <11906246483657-git-send-email-ilpo.jarvinen@helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Mon, 24 Sep 2007 12:04:06 +0300
> I previously added checking to position that is rather poor as
> state has already been adjusted quite a bit. Re-placing it above
> all state changes should be more robust though the return should
> never ever get executed regardless of its place :-).
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Applied to net-2.6.24, thanks Ilpo.
^ permalink raw reply
* Re: [RFC PATCH 2/3] [TCP]: Reordered ACK's (old) SACKs not included to discarded MIB
From: David Miller @ 2007-09-26 5:47 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev
In-Reply-To: <11906246484144-git-send-email-ilpo.jarvinen@helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Mon, 24 Sep 2007 12:04:07 +0300
> In case of ACK reordering, the SACK block might be valid in it's
> time but is already obsoleted since we've received another kind
> of confirmation about arrival of the segments through snd_una
> advancement of an earlier packet.
>
> I didn't bother to build distinguishing of valid and invalid
> SACK blocks but simply made reordered SACK blocks that are too
> old always not counted regardless of their "real" validity which
> could be determined by using the ack field of the reordered
> packet (won't be significant IMHO).
>
> DSACKs can very well be considered useful even in this situation,
> so won't do any of this for them.
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
This looks fine to me, applied.
If the skipped case is interesting we can add another MIB
stat for it :-)
^ permalink raw reply
* Re: [RFC PATCH 3/3] [TCP] MIB: Count FRTO's successfully detected spurious RTOs
From: David Miller @ 2007-09-26 5:47 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev
In-Reply-To: <11906246481619-git-send-email-ilpo.jarvinen@helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Mon, 24 Sep 2007 12:04:08 +0300
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
This also looks fine, applied, thanks!
^ permalink raw reply
* Re: [SCTP PULL Request]: Bug fixes for 2.6.23
From: David Miller @ 2007-09-26 5:53 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: netdev, lksctp-developers
In-Reply-To: <46F8252D.3090803@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Mon, 24 Sep 2007 16:59:25 -0400
> Can you please pull the following changes since commit a41d3015c11a4e864b95cb57f579f2d8f40cd41b:
I had to apply this by hand because:
> David S. Miller (1):
> Revert "PCI: disable MSI by default on systems with Serverworks HT1000 chips"
You did this work on a very old tree of mine that I redid
at one point. This MSI changeset I yanked out of my net-2.6
tree during a rebase, so if I pull I get the thing back
which I definitely don't want :-)
Just to let you know what's happening and why I couldn't
pull directly from your tree into mine.
^ permalink raw reply
* net-2.6.24 rebased...
From: David Miller @ 2007-09-26 6:33 UTC (permalink / raw)
To: netdev; +Cc: linville, jeff, akpm
Ok the rebase is complete and I integrated all of the
"easy" stuff in my backlog. In the usual spot:
kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git
John, one patch didn't go in cleanly after I removed the
Z1211 driver. I put it here for your consideration so it
doesn't get lost:
http://vger.kernel.org/~davem/0433-Z1211-Fix-TX-status-reports.patch
What probably needs to happen is some other changes that
were in z1211 need to go into the non-mac80211 driver and
then this patch applies correctly.
I tried the simple thing to rename the directory in the patch
and that didn't work, obviously :-)
Jeff, if you have any pending driver bits please toss them my
way as most of my backlog is clear now.
Andrew, I applied a good chunk of the driver build fixes you had
accumulated. I think I missed one or two, so please check that out
and send my way the ones that I missed.
Thanks!
^ 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