From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Sat, 03 Dec 2005 02:25:53 +0100
> Note that on a router (ie most packets are not locally delivered), copybreak
> is useless and expensive.
>
> But if most packets are locally delivered (on local TCP or UDP
> queues), then copybreak is a win because les
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Sat, 3 Dec 2005 03:03:28 +0100
> On Fri, Dec 02, 2005 at 05:01:39PM -0800, John Ronciak wrote:
> > On 12/2/05, Grant Grundler <[EMAIL PROTECTED]> wrote:
> >
> > > Yup. We can tune for workload/load-latency of each architecture.
> > > I think tuning for a
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 03 Dec 2005 09:59:31 +1100
> Sorry but I disagree. First of all this is inside a net_ratelimit() so
> DoS potentials are well, limited :)
>
> More importantly, you should never see this unless there is a hardware
> fault or a serious software bug.
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Date: Fri, 2 Dec 2005 15:03:07 -0200
> Dave can we expect a rebase of 2.6.16.git to get these
> things there? I'll need it to load, hum, dccpv6.ko :-)
I'll see what I can do over this weekend :)
-
To unsubscribe from this list: send the line "uns
Hi Guys,
This is a quick patch I made for the Prism54 driver to display
bit-rates in the scan output. This patch was made for 2.6.15-rc4 and
seem to do the right thing.
If one of you could push that to the various Prism54
repository, I would be glad.
Have fun...
On Fri, Dec 02, 2005 at 05:01:39PM -0800, John Ronciak wrote:
> On 12/2/05, Grant Grundler <[EMAIL PROTECTED]> wrote:
>
> > Yup. We can tune for workload/load-latency of each architecture.
> > I think tuning for all of them in one source code is the current problem.
> > We have to come up with a w
Ronciak, John a écrit :
In this combination of hardware and in this forwarding test
copybreak is bad but prefetching helps.
e1000 vanilla 1150 kpps
e1000 6.2.151084
e1000 6.2.15 copybreak disabled
On 12/2/05, Grant Grundler <[EMAIL PROTECTED]> wrote:
> Yup. We can tune for workload/load-latency of each architecture.
> I think tuning for all of them in one source code is the current problem.
> We have to come up with a way for the compiler to insert (or not)
> prefetching at different places
> In this combination of hardware and in this forwarding test
> copybreak is bad but prefetching helps.
>
> e1000 vanilla 1150 kpps
> e1000 6.2.151084
> e1000 6.2.15 copybreak disabled 1216
> e1000
Al Boldi wrote:
The current ip / ifconfig configuration is arcane and inflexible. The reason
being, that they are based on design principles inherited from the last
century.
In a GNU/OpenSource environment, OpenMinds should not inhibit themselves
achieving new design-goals to enable a flexi
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> The netdev_rx_csum_fault function shouldn't show the stack. The backtrace
> can cause way more output than necessary, and could be a potential DoS.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Sorry but I disagree. First of all this is i
On 12/2/05, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2 Dec 2005, Al Boldi wrote:
>
> > The current ip / ifconfig configuration is arcane and inflexible. The
> > reason
> > being, that they are based on design principles inherited from the last
> > century.
> >
> > In a GNU/O
- Original Message -
From: "Benjamin LaHaise" <[EMAIL PROTECTED]>
To: "JaniD++" <[EMAIL PROTECTED]>
Cc:
Sent: Friday, December 02, 2005 10:26 PM
Subject: Re: e1000 performance question.
> On Fri, Dec 02, 2005 at 09:23:33PM +0100, JaniD++ wrote:
> > I have 4 HW-equal disk nodes, what i
On Fri, Dec 02, 2005 at 09:23:33PM +0100, JaniD++ wrote:
> I have 4 HW-equal disk nodes, what i use with NBD.
> When i try to get the top performance, i seriously found the network as the
> bottleneck.
What motherboard are you using? On my test box I am able to get 100MB/s
reads over the networ
Since udp_checksum_init always returns 0 there is no point in
having it return a value.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- sky2-2.6.orig/net/ipv4/udp.c
+++ sky2-2.6/net/ipv4/udp.c
@@ -1094,7 +1094,7 @@ static int udp_v4_mcast_deliver(struct s
* Otherwise, csum completion r
On Fri, 2 Dec 2005, Al Boldi wrote:
> The current ip / ifconfig configuration is arcane and inflexible. The reason
> being, that they are based on design principles inherited from the last
> century.
>
> In a GNU/OpenSource environment, OpenMinds should not inhibit themselves
> achieving new des
Al Boldi wrote:
The current ip / ifconfig configuration is arcane and inflexible. The reason
being, that they are based on design principles inherited from the last
century.
In a GNU/OpenSource environment, OpenMinds should not inhibit themselves
achieving new design-goals to enable a flexib
On Fri, 2 Dec 2005, Al Boldi wrote:
Consider this new approach for better address management:
1. Allow the definition of an address pool
2. Relate links to addresses
3. Implement to make things backward-compatible.
The obvious benefit here, would be the transparent ability for apps to bind
to ad
The current ip / ifconfig configuration is arcane and inflexible. The reason
being, that they are based on design principles inherited from the last
century.
In a GNU/OpenSource environment, OpenMinds should not inhibit themselves
achieving new design-goals to enable a flexible non-redundant c
On Fri, Dec 02, 2005 at 11:04:14AM -0700, Grant Grundler wrote:
> At the time you did this, I read the Intel docs on P3 and P4 cache
> behaviors. IIRC, the P4 HW prefetches very aggressively. ie the SW
> prefetching just becomes noise or burns extra CPU cycles. My guess
I don't think they can foll
On Thu, Dec 01, 2005 at 09:32:37PM -0500, jamal wrote:
> > I think until a counter case is shown, the prefetches should
> > remain on unconditionally. Proof of detriment is the burdon
> > of the accusor, especially since the Intel folks aparently
> > did a lot of testing :-)
We've already been do
On Wed, Nov 23, 2005 at 05:45:36PM -0500, Jeff Garzik wrote:
> Andrew Grover wrote:
> >As presented in our talk at this year's OLS, the Bensley platform, which
> >will be out in early 2006, will have an asyncronous DMA engine. It can be
> >used to offload copies from the CPU, such as the kernel c
On 12/2/05, David S. Miller <[EMAIL PROTECTED]> wrote:
> From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
> Date: Fri, 02 Dec 2005 11:21:50 +0900 (JST)
>
> > Here it is:
> >
> > [IPV6]: Load protocol module dynamically.
> >
> > Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
>
> Applied, thanks a l
On Fri, Dec 02, 2005 at 08:31:01PM +0530, madanagopal wrote:
> hai,
>Sorry to ask again. Was this exact problem noticed and fixed in some
> kernel version? If so which version is it? If it is not possible to get
> that info, which version should we use and are we guaranteed that this
> probl
hai,
Sorry to ask again. Was this exact problem noticed and fixed in some
kernel version? If so which version is it? If it is not possible to get
that info, which version should we use and are we guaranteed that this
problem will not be present in it?
> That kernel is beyond ancient -- a 2.
That kernel is beyond ancient -- a 2.4.9 errata kernel was released on
the day that Red Hat 7.2 shipped. It is known buggy and superceeded by
many kernels with substantial bugfixes.
-ben
On Fri, Dec 02, 2005 at 05:05:28PM +0530, madanagopal wrote:
> hai,
>We have a socket a
jamal writes:
> I will test with a newer piece of hardware and one of the older ones i
> have (both Xeons) - perhaps this weekend.
> Robert may have some results perhaps on this driver, Robert?
> It would also be nice for the intel folks to post their full results
> somewhere.
I agree with
Hi,
> > OK, i will try it, if i can (this is a productive online system,
maybe
> > next reboot)
>
> I'd rather suggest to _not_ run -rc kernels on productive systems. :)
Thanks for the warning! :-)
I know it, already.
But have no choice. :(
The older kernels didnt know what i have needed! :-
hai,
We have a socket application in C which connects to a Java application
through TCP sockets. We use read() system call to read from the socket.
The Java application sends more than 2 bytes of data sometimes. In the
C program, we read those bytes as Type,Length,Value fields where a
se
On Fri, Dec 02, 2005 at 07:47:45AM +0100, Eric Dumazet wrote:
> Herbert Xu a écrit :
> >Jayachandran C. <[EMAIL PROTECTED]> wrote:
[incorrect patch deleted]
> >
> >This is wrong. If we're peeking, we've incremented the refcount of the
> >skb without taking it off the list. So if it isn't on the l
Herbert Xu a écrit :
That's a good idea. Dave, here is a patch for 2.6.16.
[IP]: Simplify and consolidate MSG_PEEK error handling
When a packet is obtained from skb_recv_datagram with MSG_PEEK enabled
it is left on the socket receive queue. This means that when we detect
a checksum error we
On Fri, Dec 02, 2005 at 07:47:45AM +0100, Eric Dumazet wrote:
>
> Then maybe we could just do something like that :
>
> if (skb == skb_peek(&sk->sk_receive_queue)) {
> __skb_unlink(skb, &sk->sk_receive_queue);
> atomic_dec(&skb->users); /* drop reference */
>
32 matches
Mail list logo
