Kris Katterjohn wrote:
Whoops! Here you go:
Whoops again. Screwed that last patch up. I gotta stop doing this stuff when I'm
tired and I need to check myself :)
Sorry. Again.
--- x/net/core/filter.c 2006-01-05 12:27:17.0 -0600
+++ y/net/core/filter.c 2006-01-05 17:02:32.0
In order to avoid some OOM triggered by a flood of call_rcu() calls, we
increased in linux 2.6.14 maxbatch from 10 to 1, and conditionally call
set_need_resched() in call_rcu().
This solution doesnt solve all the problems and has drawbacks.
1) Using a big maxbatch has a bad impact on
* We really have no wireless maintainer. I'm just the defacto guy,
with no interest in the job. The ideal maintainer knows 802.11 well,
uses git, and isn't an asshole with no taste. I'm just the guy who
wants to make sure the net driver portion doesn't turn out to be a
stinker
On Fri, 2006-01-06 at 12:00 +0100, Michael Buesch wrote:
* master interface as real device node
* Virtual interfaces (net_devices)
I didn't want to spam the netdev wiki with this (yet) so I collected
some more structured things outside. Anyone feel free to edit:
Hi Michael,
How would the virtual interfaces look like? That is quite easy to answer.
They are net_devices, as they transfer data.
They should probaly _not_ be on top of the ethernet, as 80211 does not
have very much in common with ethernet. Basically they share the same
MAC address format.
On Friday 06 January 2006 12:38, you wrote:
Hi Michael,
How would the virtual interfaces look like? That is quite easy to answer.
They are net_devices, as they transfer data.
They should probaly _not_ be on top of the ethernet, as 80211 does not
have very much in common with ethernet.
On Fri, Jan 06, 2006 at 12:31:24PM +0100, Johannes Berg wrote:
On Fri, 2006-01-06 at 12:00 +0100, Michael Buesch wrote:
* master interface as real device node
* Virtual interfaces (net_devices)
I didn't want to spam the netdev wiki with this (yet) so I collected
some more structured
From someone who has no idea at all (yet) about 802.11: why character
device, and not sysfs or configfs files? Like
As Michael already said -- there's no real reason for that. We were just
brainstorming. The /dev idea seemed like a good plan at first, but then
it isn't fixed. What you
First patch was buggy, sorry :(
This 2nd version makes no more RCU assumptions, because only the 'donelist'
queue is fetched for an item to be deleted. Items from the donelist are ready
to be freed.
This V2 also corrects a problem in case of a CPU hotplug, we forgot to update
the -count
On Friday 06 January 2006 11:17, Eric Dumazet wrote:
I assume that if a CPU queued 10.000 items in its RCU queue, then the
oldest entry cannot still be in use by another CPU. This might sounds as a
violation of RCU rules, (I'm not an RCU expert) but seems quite reasonable.
I don't think it's
Andi Kleen a écrit :
On Friday 06 January 2006 11:17, Eric Dumazet wrote:
I assume that if a CPU queued 10.000 items in its RCU queue, then the
oldest entry cannot still be in use by another CPU. This might sounds as a
violation of RCU rules, (I'm not an RCU expert) but seems quite reasonable.
From: Patrick McHardy
Sent: 1/6/2006 1:36:24 AM
Please use unsigned int not just unsigned.
Ta-da!
--- x/net/core/filter.c 2006-01-05 12:27:17.0 -0600
+++ y/net/core/filter.c 2006-01-05 17:02:32.0 -0600
@@ -75,7 +75,7 @@ static inline void *load_pointer(struct
* len is the
Alan Cox a écrit :
On Gwe, 2006-01-06 at 11:17 +0100, Eric Dumazet wrote:
I assume that if a CPU queued 10.000 items in its RCU queue, then the oldest
entry cannot still be in use by another CPU. This might sounds as a violation
of RCU rules, (I'm not an RCU expert) but seems quite reasonable.
On Fri, 2006-01-06 at 12:38 -0200, Alan Menegotto wrote:
Look at the code:
static int __init ipv4_proc_init(void)
{
int rc = 0;
if (raw_proc_init())
goto out_raw;
if (tcp4_proc_init())
goto out_tcp;
if
On Gwe, 2006-01-06 at 15:00 +0100, Eric Dumazet wrote:
In the case of call_rcu_bh(), you can be sure that the caller cannot afford
'sleeping memory allocations'. Better drop a frame than block the stack, no ?
atomic allocations can't sleep and will fail which is fine. If memory
allocation
Hi,
This patch contains two corrections to the LSM-IPsec Nethooks patches
previously applied.
(1) free a security context on a failed insert via xfrm_user
interface in xfrm_add_policy. Memory leak.
(2) change the authorization of the allocation of a security context
in a xfrm_policy or
Forgot signoff -- see below.
On Jan 6, 2006, at 10:48 AM, Trent Jaeger wrote:
Hi,
This patch contains two corrections to the LSM-IPsec Nethooks patches
previously applied.
(1) free a security context on a failed insert via xfrm_user
interface in xfrm_add_policy. Memory leak.
(2) change the
Michael Buesch wrote:
The _real_ main point I wanted to make was to _not_ use a net_device for
the master device. What else should be used for master device, let it
be a device node or a netlink socket, is rather unimportant at
this stage.
If the only purpose of the master device was
On Fri, 2006-01-06 at 11:09 -0500, Trent Jaeger wrote:
Forgot signoff -- see below.
On Jan 6, 2006, at 10:48 AM, Trent Jaeger wrote:
Hi,
This patch contains two corrections to the LSM-IPsec Nethooks patches
previously applied.
(1) free a security context on a failed insert via
On 1/6/06, Alan Menegotto [EMAIL PROTECTED] wrote:
Hi.
I couldn't understand the logic in the function 'static int __init
ipv4_proc_init(void)' located at net/ipv4/af_inet.c. Look at the code:
static int __init ipv4_proc_init(void)
{
int rc = 0;
if (raw_proc_init())
On Fri, Jan 06, 2006 at 01:37:12PM +, Alan Cox wrote:
On Gwe, 2006-01-06 at 11:17 +0100, Eric Dumazet wrote:
I assume that if a CPU queued 10.000 items in its RCU queue, then the
oldest
entry cannot still be in use by another CPU. This might sounds as a
violation
of RCU rules,
On Fri, 2006-01-06 at 17:12 +0100, Feyd wrote:
Michael Buesch wrote:
The _real_ main point I wanted to make was to _not_ use a net_device for
the master device. What else should be used for master device, let it
be a device node or a netlink socket, is rather unimportant at
this stage.
ifenslave, as of abi version 2, does not set the ip address on the slave
interfaces. The documentation example however still shows that the
ensalved interfaces should have the same IP as the master. The patch
simply removes the lines from the example which should no longer appear.
Michael Buesch wrote:
How would the virtual interfaces look like? That is quite easy to answer.
They are net_devices, as they transfer data.
They should probaly _not_ be on top of the ethernet, as 80211 does not
have very much in common with ethernet. Basically they share the same
MAC address
Paul E. McKenney a écrit :
On Fri, Jan 06, 2006 at 01:37:12PM +, Alan Cox wrote:
On Gwe, 2006-01-06 at 11:17 +0100, Eric Dumazet wrote:
I assume that if a CPU queued 10.000 items in its RCU queue, then the oldest
entry cannot still be in use by another CPU. This might sounds as a violation
On Fri, 06 Jan 2006 13:46:15 +0100
Patrick McHardy [EMAIL PROTECTED] wrote:
Marcel Holtmann wrote:
I just personally liked the idea of having a device node in /dev for
every existing hardware wlan card. Like we have device nodes for
other real hardware, too. It felt like a bit of a unix way
This uses is_multicast_ether_addr() because it has recently been changed to do
the same thing these seperate tests are doing.
Signed-off-by: Kris Katterjohn [EMAIL PROTECTED]
Thanks!
--- x/net/atm/br2684.c 2006-01-02 21:21:10.0 -0600
+++ y/net/atm/br2684.c 2006-01-06
This patch removes the obsolete drivers/net/tulip/xircom_tulip_cb.c
driver.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch was already sent on:
- 12 Dec 2005
- 18 Nov 2005
drivers/net/tulip/Kconfig | 16
drivers/net/tulip/Makefile |1
On Fri, 2006-01-06 at 13:58 +0100, Andi Kleen wrote:
Another CPU might be stuck in a long
running interrupt
Shouldn't a long running interrupt be considered a bug?
Lee
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
On Fri, 2006-01-06 at 11:17 +0100, Eric Dumazet wrote:
I have some servers that once in a while crashes when the ip route
cache is flushed. After
raising /proc/sys/net/ipv4/route/secret_interval (so that *no*
flush is done), I got better uptime for these servers.
Argh, where is that
From: Christoph Dworzak [EMAIL PROTECTED]
A BIOS bug affecting some multiport tulip NICs requires an irq fixup
in tulip_core.c. This has only been enabled for i686, but it is
needed for x86_64 as well.
Signed-off-by: John W. Linville [EMAIL PROTECTED]
---
drivers/net/tulip/tulip_core.c |2
And fix trivial warnings that emerged.
Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]
---
include/linux/ip.h | 10 +-
net/ipv4/ip_fragment.c |2 +-
net/ipv4/ip_output.c |4 ++--
net/ipv4/ipvs/ip_vs_xmit.c |2 +-
4 files changed, 9 insertions(+), 9
Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]
---
include/linux/inet.h |2 +-
net/core/utils.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/include/linux/inet.h
+++ b/include/linux/inet.h
@@ -45,6 +45,6 @@
#ifdef __KERNEL__
#include linux/types.h
-extern
http://bugzilla.ubuntu.com/show_bug.cgi?id=16435
The above is a bug report for a user that is getting a firmware restart
timeout (waiting for mbox1 magic to invert).
Any ideas on if this is a software or hardware issue? Anything I can ask
the user to do to help debug it?
This is 2.6.15, btw.
On Fri, Jan 06, 2006 at 06:19:15PM +0100, Eric Dumazet wrote:
Paul E. McKenney a écrit :
On Fri, Jan 06, 2006 at 01:37:12PM +, Alan Cox wrote:
On Gwe, 2006-01-06 at 11:17 +0100, Eric Dumazet wrote:
I assume that if a CPU queued 10.000 items in its RCU queue, then the
oldest entry cannot
Randy.Dunlap wrote:
On Fri, 6 Jan 2006, Patrick McHardy wrote:
--- x/net/atm/br2684.c 2006-01-02 21:21:10.0 -0600
+++ y/net/atm/br2684.c 2006-01-06 12:34:47.0 -0600
@@ -295,7 +295,7 @@ static inline __be16 br_type_trans(struc
unsigned char *rawp;
eth =
From: Patrick McHardy
Sent: 1/6/2006 12:52:34 PM
Randy.Dunlap wrote:
On Fri, 6 Jan 2006, Patrick McHardy wrote:
--- x/net/atm/br2684.c 2006-01-02 21:21:10.0 -0600
+++ y/net/atm/br2684.c 2006-01-06 12:34:47.0 -0600
@@ -295,7 +295,7 @@ static inline __be16
On Fri, 2006-01-06 at 15:13 -0500, Ben Collins wrote:
http://bugzilla.ubuntu.com/show_bug.cgi?id=16435
The above is a bug report for a user that is getting a firmware restart
timeout (waiting for mbox1 magic to invert).
Any ideas on if this is a software or hardware issue? Anything I can
From: Kris Katterjohn [EMAIL PROTECTED]
Date: Fri, 6 Jan 2006 05:53:32 -0800
From: Patrick McHardy
Sent: 1/6/2006 1:36:24 AM
Please use unsigned int not just unsigned.
Ta-da!
Applied, thanks Kris.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message
From: Kris Katterjohn [EMAIL PROTECTED]
Date: Fri, 6 Jan 2006 13:01:54 -0800
From: Patrick McHardy
Sent: 1/6/2006 12:52:34 PM
Randy.Dunlap wrote:
On Fri, 6 Jan 2006, Patrick McHardy wrote:
--- x/net/atm/br2684.c 2006-01-02 21:21:10.0 -0600
+++ y/net/atm/br2684.c
From: Joe [EMAIL PROTECTED]
Date: Thu, 5 Jan 2006 23:43:52 -0500
Thats not all either, ./net/ipv4/netfilter/ipt_helper.c has the same
error and the same fix.
Here's the patch for this one. Sorry for the dupe.. i sent the last
as html by accident.
Applied, please provide a Signed-off-by:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 4 Jan 2006 16:00:41 -0800
It looks like the bridge netfilter code does not correctly update
the hardware checksum after popping off the VLAN header.
This is by inspection, I have *not* tested this.
To test you would need to set up a
From: Trent Jaeger [EMAIL PROTECTED]
Date: Fri, 6 Jan 2006 11:09:43 -0500
Signed-off-by: Trent Jaeger [EMAIL PROTECTED]
Applied, thanks Trent.
I think it's a small bit of lesser known trivia that I spent one
semester at Penn State, on the Erie campus :-)
-
To unsubscribe from this list: send
From: Alexey Dobriyan [EMAIL PROTECTED]
Date: Fri, 6 Jan 2006 23:18:37 +0300
And fix trivial warnings that emerged.
Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]
Applied.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
From: Alexey Dobriyan [EMAIL PROTECTED]
Date: Fri, 6 Jan 2006 23:19:25 +0300
Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]
Also applied.
Thanks.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, 6 Jan 2006, Patrick McHardy wrote:
Marcel Holtmann wrote:
I just personally liked the idea of having a device node in /dev for
every existing hardware wlan card. Like we have device nodes for
other real hardware, too. It felt like a bit of a unix way to do
this to me. I don't say this
Our daily build-system spat this out about 2.6.15-git2
WARNING:
/usr/src/build/676459-ia64/install/lib/modules/2.6.15-1.1830_FC5/kernel/net/dccp/dccp_ipv6.ko
needs unknown symbol csum_ipv6_magic
WARNING:
David Lang wrote:
On Fri, 6 Jan 2006, Patrick McHardy wrote:
I think the main advantages of netlink over a character device is its
flexible format, which is easily extendable, and multicast capability,
which can be used to broadcast events and configuration changes. Its
also good to have all
Michael Buesch [EMAIL PROTECTED] wrote:
How would the virtual interfaces look like? That is quite easy to answer.
They are net_devices, as they transfer data.
They should probaly _not_ be on top of the ethernet, as 80211 does not
have very much in common with ethernet. Basically they share
Begin forwarded message:
Date: Fri, 6 Jan 2006 03:12:39 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 5843] New: kissattach locks up system
http://bugzilla.kernel.org/show_bug.cgi?id=5843
Summary: kissattach locks up system
Kernel Version:
It can be in promiscious mode (wardriving).
Just to nitpick:
Promisc implies delivering all data frames from the medium. rfmon is
actually a different link type and delivers management frames (for which
there isn't a clear equivalent in 802.3).
Promisc does not imply disabling normal
[ Sorry, this went to linux-kernel, meant to send it to netdev.
Apologies to those who see it twice. ]
So, now we asked: How would a sane UI look like. We had a few points:
* The interface needs to support some kind of master interface to
configure the hardware, 80211 parameters and
to
Hi,
The following patch to the e100 device driver is in the current
2.6.15-mm1 tree, and is being pushed to the mainline 2.6.15 tree.
I wrote this patch, and I believe I've cc'ed you on previous
versions, but certainly not recently. Please review, comment,
ACK or NAK as appropriate.
From: Dave Jones [EMAIL PROTECTED]
Date: Fri, 6 Jan 2006 17:23:07 -0500
Missing exports/inlines ?
Missing include, I'll fix it up.
Thanks for the report.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Here's the correspondig patch fo the e1000
--linas
Hi,
The following patch to the e100 device driver is in the current
2.6.15-mm1 tree, and is being pushed to the mainline 2.6.15 tree.
I wrote this patch, and I believe I've cc'ed you on previous
versions, but certainly not recently.
Here's the corresponding patch for the ixgb.
--linas
Hi,
The following patch to the e100 device driver is in the current
2.6.15-mm1 tree, and is being pushed to the mainline 2.6.15 tree.
I wrote this patch, and I believe I've cc'ed you on previous
versions, but certainly not recently.
This removes an old comment and old commented-out code that's been there since
at least as far back as 2.4.0.
Signed-off-by: Kris Katterjohn [EMAIL PROTECTED]
Thanks!
--- x/net/ethernet/eth.c2006-01-06 12:49:27.0 -0600
+++ y/net/ethernet/eth.c2006-01-06
From: Kris Katterjohn [EMAIL PROTECTED]
Date: Fri, 6 Jan 2006 16:05:36 -0800
This removes an old comment and old commented-out code that's been there since
at least as far back as 2.4.0.
Signed-off-by: Kris Katterjohn [EMAIL PROTECTED]
It's instructive to keep it there so that nobody in the
From: David S. Miller
Sent: 1/6/2006 4:08:33 PM
From: Kris Katterjohn [EMAIL PROTECTED]
Date: Fri, 6 Jan 2006 16:05:36 -0800
This removes an old comment and old commented-out code that's been there
since
at least as far back as 2.4.0.
Signed-off-by: Kris Katterjohn [EMAIL
This localizes a variable to the function it's used in.
Signed-off-by: Kris Katterjohn [EMAIL PROTECTED]
I assume tmp was used for a reason instead of using a variable local to the if()
in load_pointer(), but I can't figure out why. So I wrote this patch changing it
in case it was just a mistake
After fixing skge/sky2 for 64 bit DMA, examination of sk98lin
showed similar bugs. Once again, I don't want to get into a massive
cleanup fest of the sk98lin driver, but there are some real issues
here that users might see.
--
Stephen Hemminger [EMAIL PROTECTED]
OSDL
The sk98lin driver doesn't do proper error number handling
during initialization. Note: -EAGAIN is a bogus return value for
hardware errors.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sk98lin.orig/drivers/net/sk98lin/skge.c
+++ sk98lin/drivers/net/sk98lin/skge.c
@@ -530,7 +530,7 @@
Sk98lin driver error recovery on two port boards is bad.
If it fails the second allocation, it will not release resources
properly. Also it registers the second port in the pci driver data
If second port fails, might as well go with one port.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
Trivial use of kzalloc.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sk98lin.orig/drivers/net/sk98lin/skge.c
+++ sk98lin/drivers/net/sk98lin/skge.c
@@ -4807,14 +4807,13 @@ static int __devinit skge_probe_one(stru
}
pNet = netdev_priv(dev);
- pNet-pAC =
Don't enable the pci device twice (already done in the probe
routine). Propogate the error codes from pci_request_region
back to initial probing.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sk98lin.orig/drivers/net/sk98lin/skge.c
+++ sk98lin/drivers/net/sk98lin/skge.c
@@ -292,17
Sk98lin driver has a routine marked __init that is called from
the probe code. If using pci hotplug, this could be called after
the initialization so it needs to be marked __devinit.
So if you hot added a sk98lin board, the kernel would crash.
I don't have hot plug hardware to actually try this
Sk98lin 64bit memory handling is wrong. It doesn't set the
highdma flag; i.e. the kernel always does bounce buffers.
It doesn't fallback to 32 bit mask if it can't get 64 bit mask.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sk98lin.orig/drivers/net/sk98lin/skge.c
+++
Kris Katterjohn wrote:
This localizes a variable to the function it's used in.
Signed-off-by: Kris Katterjohn [EMAIL PROTECTED]
I assume tmp was used for a reason instead of using a variable local to the if()
in load_pointer(), but I can't figure out why. So I wrote this patch changing it
in
From: Patrick McHardy
Sent: 1/6/2006 5:12:33 PM
-static inline void *load_pointer(struct sk_buff *skb, int k,
- unsigned int size, void *buffer)
+static inline void *load_pointer(struct sk_buff *skb, int k, unsigned int
size)
{
- if (k = 0)
+ if
Kris Katterjohn wrote:
From: Patrick McHardy
Sent: 1/6/2006 5:12:33 PM
-static inline void *load_pointer(struct sk_buff *skb, int k,
- unsigned int size, void *buffer)
+static inline void *load_pointer(struct sk_buff *skb, int k, unsigned int size)
{
- if
From: Patrick McHardy
Sent: 1/6/2006 5:20:44 PM
-static inline void *load_pointer(struct sk_buff *skb, int k,
- unsigned int size, void *buffer)
+static inline void *load_pointer(struct sk_buff *skb, int k, unsigned int
size)
{
- if (k = 0)
-
From: Kris Katterjohn [EMAIL PROTECTED]
Date: Fri, 6 Jan 2006 17:25:32 -0800
So the whole thing is wrong? If so, I guess I understand why it was
done the way it was before.
It's using the local variable in the parent function as a temporary
scratch area if the SKB isn't linear and we need to
From: David S. Miller
Sent: 1/6/2006 5:29:20 PM
From: Kris Katterjohn [EMAIL PROTECTED]
Date: Fri, 6 Jan 2006 17:25:32 -0800
So the whole thing is wrong? If so, I guess I understand why it was
done the way it was before.
It's using the local variable in the parent function as a
On Fri, Jan 06, 2006 at 01:25:03PM -0800, David S. Miller wrote:
From: Alexey Dobriyan [EMAIL PROTECTED]
Date: Fri, 6 Jan 2006 23:18:37 +0300
And fix trivial warnings that emerged.
Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]
Applied.
OK, will merge... I've actually got way
On Saturday 07 January 2006 01:17, David S. Miller wrote:
I mean something like this patch:
Looks like a good idea to me.
I always disliked the per chain spinlocks even for other hash tables like
TCP/UDP multiplex - it would be much nicer to use a much smaller separately
hashed lock table
In article [EMAIL PROTECTED] (at Sat, 7 Jan 2006 02:09:30 +0100 (MET)),
Patrick McHardy [EMAIL PROTECTED] says:
following are the remaining patches for netfilter IPsec support.
They are missing the common-case optimization for inner transport mode
SAs on the input path, but since its just an
The unlocking disappeared during commit
5793f4be23f0171b4999ca68a39a9157b44139f3.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
diff --git a/drivers/net/hamradio/mkiss.c b/drivers/net/hamradio/mkiss.c
index 3e9accf..41b3d83 100644
--- a/drivers/net/hamradio/mkiss.c
+++
On 1/6/06, David S. Miller [EMAIL PROTECTED] wrote:
From: Joe [EMAIL PROTECTED]
Date: Thu, 5 Jan 2006 23:43:52 -0500
Thats not all either, ./net/ipv4/netfilter/ipt_helper.c has the same
error and the same fix.
Here's the patch for this one. Sorry for the dupe.. i sent the last
as
From: Francois Romieu [EMAIL PROTECTED]
Date: Sat, 7 Jan 2006 03:22:43 +0100
The unlocking disappeared during commit
5793f4be23f0171b4999ca68a39a9157b44139f3.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Applied, thanks a lot.
-
To unsubscribe from this list: send the line unsubscribe
From: Andi Kleen [EMAIL PROTECTED]
Date: Sat, 7 Jan 2006 02:09:01 +0100
I always disliked the per chain spinlocks even for other hash tables like
TCP/UDP multiplex - it would be much nicer to use a much smaller separately
hashed lock table and save cache. In this case the special case of
Andi Kleen a écrit :
I always disliked the per chain spinlocks even for other hash tables like
TCP/UDP multiplex - it would be much nicer to use a much smaller separately
hashed lock table and save cache. In this case the special case of using
a one entry only lock hash table makes sense.
From: Eric Dumazet [EMAIL PROTECTED]
Date: Sat, 07 Jan 2006 08:34:35 +0100
I agree, I do use a hashed spinlock array on my local tree for TCP,
mainly to reduce the hash table size by a 2 factor.
So what do you think about going to a single spinlock for the
routing cache?
-
To unsubscribe from
David S. Miller a écrit :
From: Eric Dumazet [EMAIL PROTECTED]
Date: Sat, 07 Jan 2006 08:34:35 +0100
I agree, I do use a hashed spinlock array on my local tree for TCP,
mainly to reduce the hash table size by a 2 factor.
So what do you think about going to a single spinlock for the
routing
83 matches
Mail list logo
