Re: [IPv4] Fix issue reported by Coverity in net/ipv4/udp.c

2005-12-02 Thread Herbert Xu
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 */ }

Re: [IPv4] Fix issue reported by Coverity in net/ipv4/udp.c

2005-12-02 Thread Eric Dumazet
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

Re: [IPv4] Fix issue reported by Coverity in net/ipv4/udp.c

2005-12-02 Thread Jayachandran C.
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 list

Data corruption when using TCP sockets

2005-12-02 Thread madanagopal
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

Re: 2.6.15-rc3: adduser: unable to lock password file

2005-12-02 Thread JaniD++
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! :-/

Re: Resend [PATCH netdev-2.6 2/8] e1000: Performance Enhancements

2005-12-02 Thread Robert Olsson
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 you

Re: Data corruption when using TCP sockets

2005-12-02 Thread Benjamin LaHaise
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

Re: Data corruption when using TCP sockets

2005-12-02 Thread madanagopal
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

Re: Data corruption when using TCP sockets

2005-12-02 Thread Benjamin LaHaise
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 problem

Re: [PATCH] [IPV6]: Load protocol module dynamically (is Re: [IPv4] Fix issue reported by Coverity in net/ipv4/af_inet.c)

2005-12-02 Thread Arnaldo Carvalho de Melo
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 lot Yoshifuji-san.

Re: [RFC] [PATCH 0/3] ioat: DMA engine support

2005-12-02 Thread Jon Mason
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 copies

Re: Resend [PATCH netdev-2.6 2/8] e1000: Performance Enhancements

2005-12-02 Thread Grant Grundler
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 down this

Re: Resend [PATCH netdev-2.6 2/8] e1000: Performance Enhancements

2005-12-02 Thread Andi Kleen
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 follow

[RFC] ip / ifconfig redesign

2005-12-02 Thread Al Boldi
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

Re: [RFC] ip / ifconfig redesign

2005-12-02 Thread Pekka Savola
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

Re: [RFC] ip / ifconfig redesign

2005-12-02 Thread Ben Greear
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

Re: [RFC] ip / ifconfig redesign

2005-12-02 Thread linux-os \(Dick Johnson\)
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

[PATCH] udp_checksum_init return value

2005-12-02 Thread Stephen Hemminger
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

Re: e1000 performance question.

2005-12-02 Thread Benjamin LaHaise
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 network

Re: e1000 performance question.

2005-12-02 Thread JaniD++
- Original Message - From: Benjamin LaHaise [EMAIL PROTECTED] To: JaniD++ [EMAIL PROTECTED] Cc: netdev@vger.kernel.org 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

Re: [RFC] ip / ifconfig redesign

2005-12-02 Thread Jesper Juhl
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/OpenSource

Re: [PATCH] nedev_rx_csum_fault backtrace unnecessary

2005-12-02 Thread Herbert Xu
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 inside a

Re: [RFC] ip / ifconfig redesign

2005-12-02 Thread Jeff V. Merkey
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

RE: Resend [PATCH netdev-2.6 2/8] e1000: Performance Enhancements

2005-12-02 Thread Ronciak, John
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 6.2.15

Re: Resend [PATCH netdev-2.6 2/8] e1000: Performance Enhancements

2005-12-02 Thread John Ronciak
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 for

Re: Resend [PATCH netdev-2.6 2/8] e1000: Performance Enhancements

2005-12-02 Thread Eric Dumazet
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

Re: Resend [PATCH netdev-2.6 2/8] e1000: Performance Enhancements

2005-12-02 Thread Andi Kleen
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 way for

[PATCH 2.6.15] Add bit-rates to scan output

2005-12-02 Thread Jean Tourrilhes
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...

Re: [PATCH] nedev_rx_csum_fault backtrace unnecessary

2005-12-02 Thread David S. Miller
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. In

Re: [PATCH] [IPV6]: Load protocol module dynamically (is Re: [IPv4] Fix issue reported by Coverity in net/ipv4/af_inet.c)

2005-12-02 Thread David S. Miller
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

Re: Resend [PATCH netdev-2.6 2/8] e1000: Performance Enhancements

2005-12-02 Thread David S. Miller
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 less