On Mon, Aug 01, 2005 at 08:33:20AM +, Guillaume Pelat wrote:
>
> I just tried the patch attached. :)
>
> The bug is still here (same symptoms), with a slightly different backtrace :
> [ cut here ]
> kernel BUG at net/ipv4/tcp_output.c:918!
OK, let's try again :)
I be
We went through all 16 Super TSO patches to see which one causes the
performance degradation (relative to the original TSO implementation)
that was observed earlier, and it appears to be the last patch #16;
results below.
We can either provide a remote to the setup, or test incremental patches
if
Convert FIB Trie to use RCU for the normal lookup fast
path. Use simple spin_lock for updates and dump access.
This needs more testing on systems with lareg numbers of routes
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Index: fib-2.6.13-rc5/net/ipv4/fib_trie.c
==
Cleanup of the the fib_trie proc interface:
* cleanup initialization to get rid of ifdef
* new iterator that walks the trie
* cleanup format of /proc/net/fib_trie (no pointers, etc)
* add /proc/net/route for legacy utilities
Signed-off-by: Stephen Hemminger <[EMAIL
Change from using a custom debug hooks, to just using
pr_debug() and BUG_ON() in fib_trie.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Index: tcp/net/ipv4/fib_trie.c
===
--- tcp.orig/net/ipv4/fib_trie.c
+++ tcp/net/ipv4/fib_
Change inflate/halve to use the ERR_PTR return value method to
avoid having to pass error code by reference.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Index: fib/net/ipv4/fib_trie.c
===
--- fib.orig/net/ipv4/fib_trie.c
+++
Use const where possible and get rid of EXTRACT() macro
that was never used.
Signed-off-by: Stephen Hemmigner <[EMAIL PROTECTED]>
Index: fib/net/ipv4/fib_trie.c
===
--- fib.orig/net/ipv4/fib_trie.c
+++ fib/net/ipv4/fib_trie.c
@@ -77,
The attached patch allows a bonding device to inherit the "zero-
copy" features of its slave devices.
It was inspired by a couple of previous postings on this topic:
http://marc.theaimsgroup.com/?l=bonding-devel&m=111924607327794&w=2
http://marc.theaimsgroup.com/?l=bonding-devel&m=11192524270629
> no, it hasn't. I am travelling and don't have the space for a
> debian/i386 installation in addition to the debian/x86_64 on this box,
> sorry :(
That sounds risky. I would ask for this stuff not being merged before
it isn't tested.
> However, all nfnetlink-based protocols are supposed to be b
On Wed, Aug 03, 2005 at 10:02:28PM +0200, Andi Kleen wrote:
> Harald Welte <[EMAIL PROTECTED]> writes:
>
> > Hi Dave!
> >
> > This (long-awaited) patch adds the generic nfnetlink-based userspace
> > logging. nfnetlink_log can be used for any protocol family, and
> > supports upt to 65535 logging
On Wed, Aug 03, 2005 at 06:34:38AM -0700, David S. Miller wrote:
>
> I don't understand.
I think I'm still missing something so I don't understand either :)
> Therefore, when any SA is added, the assosciated policy is the
> one for which we flush all matching DST entries.
How do you find the a
This patch exposes certain features of the gianfar ethernet driver through
sysfs so that they can be configured at runtime.
These include allocating and/or locking buffers and buffer descriptors in
the L2 cache, and modifying the threshold in the FIFO at which the
controller starts transmitting
This patch converts tg3 to use firmware loading, and builds loadable firmware.
Immediate advantages:
* separation of binary firmware and GPL driver into different files makes
Debian happy
* Firmware for irrelevant models never goes into memory
(a significant savings; currently three sets are s
On Thursday 04 August 2005 04:21, Martin Josefsson wrote:
> On Thu, 2005-08-04 at 03:36 +1000, Daniel Phillips wrote:
> > I can think of two ways to deal with this:
> >
> > 1) Mindlessly include the entire maximum memory usage of the rx-ring in
> > the reserve requirement (e.g., (maxskbs * (
Harald Welte <[EMAIL PROTECTED]> writes:
> Hi Dave!
>
> This (long-awaited) patch adds the generic nfnetlink-based userspace
> logging. nfnetlink_log can be used for any protocol family, and
> supports upt to 65535 logging groups (that could go to separate logging
> daemons, e.g.).
Hi - I hope
On Thu, 2005-08-04 at 03:36 +1000, Daniel Phillips wrote:
> I can think of two ways to deal with this:
>
> 1) Mindlessly include the entire maximum memory usage of the rx-ring in
> the reserve requirement (e.g., (maxskbs * (MTU + k)) / PAGE_SIZE).
Would be dependent on the numberof interf
On Wednesday 03 August 2005 16:59, Martin Josefsson wrote:
> On Wed, 3 Aug 2005, Daniel Phillips wrote:
> > Hi,
> >
> > Here is a preliminary patch, not tested at all, just to give everybody a
> > target to aim bricks at.
> >
> > * A new __GFP_MEMALLOC flag gives access to the memalloc reserve.
>
Great to see TOE support getting reviewed.
Some general stuff:
* Use linux indentation style (Documentation/Codingstyle)
"Tabs are 8 characters, and thus indentations are also 8
characters." You are using 4 spaces.
* Don't use // for comments
* All patches must have Signed-off-by:
On Wed, Aug 03, 2005 at 12:19:24PM -0300, Arnaldo Carvalho de Melo wrote:
> On 8/3/05, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > On Wed, Aug 03, 2005 at 06:29:25AM -0700, David S. Miller wrote:
> > > From: Eric Dumazet <[EMAIL PROTECTED]>
> > > Date: Tue, 02 Aug 2005 23:45:27 +0200
> > >
> >
On 8/3/05, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 03, 2005 at 06:29:25AM -0700, David S. Miller wrote:
> > From: Eric Dumazet <[EMAIL PROTECTED]>
> > Date: Tue, 02 Aug 2005 23:45:27 +0200
> >
> > > Please move ; in a better place, not
> > > just after spinlock_t portalloc_lock;
On Wed, Aug 03, 2005 at 06:29:25AM -0700, David S. Miller wrote:
> From: Eric Dumazet <[EMAIL PROTECTED]>
> Date: Tue, 02 Aug 2005 23:45:27 +0200
>
> > Please move kmem_cache_t *bind_bucket_cachep; in a better place, not
> > just after spinlock_t portalloc_lock;
>
> [ Eric, I haven't had time to
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 3 Aug 2005 21:36:59 +1000
> On Sun, Jul 31, 2005 at 10:03:05PM -0700, David S. Miller wrote:
> > When an SA changes, we walk that assosciated policies DST list
> > marking them ->obsolete
>
> Yes this should work but it's missing one important detai
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Tue, 02 Aug 2005 23:45:27 +0200
> Please move kmem_cache_t *bind_bucket_cachep; in a better place, not
> just after spinlock_t portalloc_lock;
[ Eric, I haven't had time to respond to this thread because I'm
in the UK for UKUUG2005 this week, so emai
On Tue, Aug 02, 2005 at 02:04:41PM -0400, jaegert wrote:
> Resend of 20 July patch that repaired the flow_cache_lookup
> authorization (now for 2.6.13-rc4-git4).
Thanks for the resend. I'll try to get back to you soon.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <
Hello!
When trying to upgrade a gateway from old 2.6.10-rc2 to
new 2.6.13-rc5, I noticed a flood of messages like
"172.16.12.1 sent an invalid ICMP type 11, code 0 error to a broadcast:
0.0.0.0"
Source IP is always that of this gateway, destination IP is always 0.0.0.0.
Looks like it tries to se
On Sun, Jul 31, 2005 at 10:03:05PM -0700, David S. Miller wrote:
>
> We can avoid the flushing damage to DSTs of the effected policy.
> At least I think we can do that cleanly. Do you think that is
> a middle ground that might be acceptable to you?
It's acceptable with some blanks filled in :)
On Wed, 3 Aug 2005, Daniel Phillips wrote:
> Hi,
>
> Here is a preliminary patch, not tested at all, just to give everybody a
> target to aim bricks at.
>
> * A new __GFP_MEMALLOC flag gives access to the memalloc reserve.
>
> * In dev_alloc_skb, if GFP_ATOMIC fails then try again with __GFP_M
Hello,
Could someone please help me out on this. I am desperately looking out
for
a solution.
Thanks,
Partha
x3025
-Original Message-
From: Partha Chatterjee
Sent: Tuesday, August 02, 2005 5:50 PM
To: Partha Chatterjee; netdev@vger.kernel.org
Subject: RE: ARP entry ageing time
Hello,
Hi,
Here is a preliminary patch, not tested at all, just to give everybody a
target to aim bricks at.
* A new __GFP_MEMALLOC flag gives access to the memalloc reserve.
* In dev_alloc_skb, if GFP_ATOMIC fails then try again with __GFP_MEMALLOC.
* We know an skb was allocated from reserve
29 matches
Mail list logo
