From: Andi Kleen <[EMAIL PROTECTED]>
Date: Sat, 17 Dec 2005 08:10:29 +0100
> sock_init can be done as a core_initcall instead of calling
> it directly in init/main.c
>
> Also I removed an out of date #ifdef.
>
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Might as well kill of SLAB_SKB's defi
subscribe netdev
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 16 Dec 2005, I wrote:
> Is it expected behavior that ARP replies would be generated for interfaces
> on a different network than the IP address in the ARP request (note I
> don't have Proxy ARP enabled), or is this a bug? To me it would seem
> to be a bug.
Answering my own question for t
Add ID for Symbol LA-4123. Reported by Tomas Novak <[EMAIL PROTECTED]>
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
I mentioned LA-4113 so that potential users can find this driver and
tell me the ID. This patch has a great user_impact/code_impact ratio,
should be OK for 2.6.15 or 2.6.15
orinoco_nortel was broken during conversion to iomem API. Wrong PCI BAR
is used for chipset registers. Reported by Tomas Novak <[EMAIL PROTECTED]>
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
Please push to 2.6.15 or 2.6.15.x. We don't want broken drivers in the
kernel.
diff --git a/dr
On Fri, Dec 16, 2005 at 03:05:13PM -0800, David S. Miller ([EMAIL PROTECTED])
wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Sat, 17 Dec 2005 02:00:34 +0300
>
> > The most expensive is ioread according to oprofile, which can not be
> > changed.
>
> Sometimes clever device driver pro
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Sat, 17 Dec 2005 02:00:34 +0300
> The most expensive is ioread according to oprofile, which can not be
> changed.
Sometimes clever device driver programmers can eliminate some
ioread operations :-)
> The second one is memory allocation and then co
On Fri, Dec 16, 2005 at 09:40:48AM -0800, Stephen Hemminger ([EMAIL PROTECTED])
wrote:
> On Fri, 16 Dec 2005 11:39:52 +0300
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Dec 15, 2005 at 12:55:48PM -0800, Stephen Hemminger ([EMAIL
> > PROTECTED]) wrote:
> > > Given the pretty extens
From: Benjamin LaHaise <[EMAIL PROTECTED]>
Date: Fri, 16 Dec 2005 15:58:57 -0500
> On Fri, Dec 16, 2005 at 12:59:57PM -0800, Joe Perches wrote:
> > How about moving this into a helper function
> > and calling it from alloc_skb_from_cache too?
>
> The previous patch deleted alloc_skb_from_cache(),
From: Benjamin LaHaise <[EMAIL PROTECTED]>
Date: Fri, 16 Dec 2005 14:13:33 -0500
> The function alloc_skb_from_cache() doesn't appear to be referenced
> from anywhere in the kernel source, so let's remove it.
Xen makes use of it... that's why it was added.
-
To unsubscribe from this list: send t
> On Fri, 2005-12-16 at 15:58 -0500, Benjamin LaHaise wrote:
> > On Fri, Dec 16, 2005 at 12:59:57PM -0800, Joe Perches wrote:
> > > How about moving this into a helper function and calling it from
> > > alloc_skb_from_cache too?
> >
> > The previous patch deleted alloc_skb_from_cache(), which wa
On Fri, 2005-12-16 at 15:58 -0500, Benjamin LaHaise wrote:
> On Fri, Dec 16, 2005 at 12:59:57PM -0800, Joe Perches wrote:
> > How about moving this into a helper function
> > and calling it from alloc_skb_from_cache too?
>
> The previous patch deleted alloc_skb_from_cache(), which wasn't reference
On Fri, Dec 16, 2005 at 12:59:57PM -0800, Joe Perches wrote:
> How about moving this into a helper function
> and calling it from alloc_skb_from_cache too?
The previous patch deleted alloc_skb_from_cache(), which wasn't referenced
from anywhere in the tree.
-ben
-
To unsubscribe
On Fri, 2005-12-16 at 14:52 -0500, Benjamin LaHaise wrote:
> In __alloc_skb(), the use of skb_shinfo() which casts a u8 * to the
> shared info structure results in gcc being forced to do a reload of the
> pointer since it has no information on possible aliasing. Fix this by
> using a pointer to
In af_unix, a rwlock is used to protect internal state. At least on my
P4 with HT it is faster to use a spinlock due to the simpler memory
barrier used to unlock. This patch raises bw_unix to ~690K/s.
-ben
diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index 3f302a
In __alloc_skb(), the use of skb_shinfo() which casts a u8 * to the
shared info structure results in gcc being forced to do a reload of the
pointer since it has no information on possible aliasing. Fix this by
using a pointer to refer to skb_shared_info.
By initializing skb_shared_info sequent
The function alloc_skb_from_cache() doesn't appear to be referenced
from anywhere in the kernel source, so let's remove it.
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 97f6580..7e65f7a 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -320,9 +320,6 @@ stat
On Fri, 2005-12-16 at 09:48 -0800, Stephen Hemminger wrote:
> On Thu, 15 Dec 2005 18:09:22 -0800
> Sridhar Samudrala <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2005-12-15 at 00:21 -0800, David S. Miller wrote:
> > > From: Sridhar Samudrala <[EMAIL PROTECTED]>
> > > Date: Wed, 14 Dec 2005 23:37:37 -0
On Thu, 15 Dec 2005 18:09:22 -0800
Sridhar Samudrala <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-12-15 at 00:21 -0800, David S. Miller wrote:
> > From: Sridhar Samudrala <[EMAIL PROTECTED]>
> > Date: Wed, 14 Dec 2005 23:37:37 -0800 (PST)
> >
> > > Instead, you seem to be suggesting in_emergency to
On Fri, 16 Dec 2005 11:39:52 +0300
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 15, 2005 at 12:55:48PM -0800, Stephen Hemminger ([EMAIL
> PROTECTED]) wrote:
> > Given the pretty extensive modifications necessary, do you have any
> > useful benchmark data to show that this is a win. P
On Thu, Dec 15, 2005 at 02:55:13PM -0800, David S. Miller wrote:
[]
> I think the kernel is definitely within it's rights to interpret
> section 4.3 of RFC2408 the way that it does.
We can say that, but then, we have to accept that this interpretation
can lead to interoperability problems !
Sometimes when doing my 10-GigE testing, I would get results like
the following:
chance% nuttcp -w2m 192.168.88.8
1184.3614 MB / 10.04 sec = 989.8235 Mbps 12 %TX 9 %RX
This seemed to indicate it was using one of the GigE interfaces
rather than the 10-GigE interface. Both chance and chance4 ha
On Fri, Dec 16, 2005 at 04:47:54AM +0100, Andi Kleen wrote:
>
> Some more testing shows that even the 2.6.14 driver eventually
> causes slab debugging BUGs() like
>
> --- [cut here ] - [please bite here ] -
> Kernel BUG at /home/andi/lsrc/linux-2.6.15rc5-git4/mm/slab.c:23
Here is initial support for size truncation.
It has some problems with unconnected socket closing.
diff --git a/include/net/zerocopy.h b/include/net/zerocopy.h
--- a/include/net/zerocopy.h
+++ b/include/net/zerocopy.h
@@ -152,6 +152,7 @@ struct zsock
u32 zc_seq_first;
On Thu, Dec 15, 2005 at 01:58:41PM -0800, David S. Miller wrote:
> From: "John W. Linville" <[EMAIL PROTECTED]>
> Date: Thu, 15 Dec 2005 15:21:37 -0500
>
> > Interesting... FWIW the FC4.netdev.6 kernel seems to be working fine
> > on (a yet-to-be-released box), which is an x86_64 (AMD) box w/
> >
On Fri, Dec 16, 2005 at 12:47:47AM -0800, Nivedita Singhvi wrote:
> Stephen Hemminger wrote:
>
> >On Thu, 15 Dec 2005 21:10:03 -0500
> >"John W. Linville" <[EMAIL PROTECTED]> wrote:
> >>That is a good question...what does a MAC address like
> >>FF:xx:xx:xx:xx:xx signify? Anyone know?
> >
> >
> >
On Thu, 15 Dec 2005, David S. Miller wrote:
From: "David S. Miller" <[EMAIL PROTECTED]>
Date: Thu, 15 Dec 2005 17:52:54 -0800 (PST)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 7cf48aa..25dd8f4 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
Sorry, that p
From: Robert Olsson <[EMAIL PROTECTED]>
Date: Wed, 14 Dec 2005 17:54:13 +0100
> An new driver entry point? And can we increase skb->users to delay
> skb destruction until the driver got the indication back?
> So the driver will do the final kfree and not in the protocol layers
> as now? Th
Stephen Hemminger wrote:
On Thu, 15 Dec 2005 21:10:03 -0500
"John W. Linville" <[EMAIL PROTECTED]> wrote:
On Thu, Dec 15, 2005 at 06:54:21PM -0600, Michael Ellerman wrote:
+ /* XXX Why are we checking for 0xff here ? */
+ return (addr[0] == 0xff) || (!is_multicast_ether_addr(ad
David S. Miller <[EMAIL PROTECTED]> wrote:
> The idea to mark, for example, IPSEC key management daemon's sockets
> as critical is flawed, because the key management daemon could hit a
> swap page over the iSCSI device. Don't even start with the idea to
> lock the IPSEC key management daemon into
> CPU usage graph attached.
> 'zc' - zero-copy transfer.
> 'recv/write' - recv()/write() transfer.
It is really attached now.
--
Evgeniy Polyakov
cpu_usage.png
Description: PNG image
On Thu, Dec 15, 2005 at 12:55:48PM -0800, Stephen Hemminger ([EMAIL PROTECTED])
wrote:
> Given the pretty extensive modifications necessary, do you have any
> useful benchmark data to show that this is a win. Previous zero
> copy (like page flipping) has not be merged because it did not
> prove to
32 matches
Mail list logo
