* RE: [patch next 3/4] netxen: fix bonding support
From: Dhananjay Phadke @ 2009-10-24 17:29 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev@vger.kernel.org
In-Reply-To: <m1skd9letu.fsf@fess.ebiederm.org>
> Yes. That should prevent the null pointer deference. Will it also
> allow setting the mac address when the NIC is down?
>
> Eric
Yes, we do save new address in netdev->dev_addr.
This is later on programmed in hardware when interface is brought up.
-Dhannajay
^ permalink raw reply
* Request: how do packet routing based on input gateway
From: Luca Dionisi @ 2009-10-24 17:14 UTC (permalink / raw)
To: netdev, linux-net
In-Reply-To: <73dbe2850910241013k7a83b07qed1f6f365e18c90e@mail.gmail.com>
On Sat, Oct 24, 2009 at 4:19 PM, Dunc <dunc@lemonia.org> wrote:
> If both of your last hops are on the same subnet you can't use incoming
> interface, so the only thing I can think of is to match the MAC address
> of the ethernet frame. If the last hop wasn't the source of the packet I
> don't think there's anything else to uniquely identify it.
There is another reason why I can't use the input interface. It's
because 2 or more gateways of mine could be accessible by the same
interface. I have to distinguish the route on the base of the last
hop, not on the base of the interface.
If I get it right, the kernel is aware of what the MAC address of the
previous hop was, but it is not aware of its IP address.
This is surprising to me. I mean, I can understand that this
information is not in the headings of the packet, but nevertheless I
thought the kernel was able to remember the gateway it came from.
If this is the situation I have to live in, then what are the commands
I must give to instruct the kernel?
Suppose I want a packet for 192.168.1.0/24 to be forwarded to
192.168.2.1 if the packet was sent to me by MAC 00:22:44:99:66:77.
Thanks alot
--Luca Dionisi
^ permalink raw reply
* Re: [RFC] net,socket: introduce build_sockaddr_check helper to catch overflow at build time
From: Cyrill Gorcunov @ 2009-10-24 16:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091024.061209.39469983.davem@davemloft.net>
[David Miller - Sat, Oct 24, 2009 at 06:12:09AM -0700]
| From: Cyrill Gorcunov <gorcunov@gmail.com>
| Date: Sat, 24 Oct 2009 01:43:06 +0400
|
| > Or say it could be something like that
| >
| > #define __sockaddr(type, src) \
| > ({ build_sockaddr_check(sizeof(type)); (type *) src; })
| >
| > and say in function af_inet.c:inet_getname instead of
| >
| > struct sockaddr_in *sin = (struct sockaddr_in *)uaddr;
| >
| > we may write like
| >
| > struct sockaddr_in *sin = __sockaddr(struct sockaddr_in, uaddr);
| >
| > which would check the size.
|
| Or even a "DECLARE_SOCKADDR(type, src, dest)" which encapsulates the
| entire declaration statement.
|
Something like this I suppose?
-- Cyrill
---
net,socket: introduce DECLARE_SOCKADDR helper to catch overflow at build time
proto_ops->getname implies copying protocol specific data
into storage unit (particulary to __kernel_sockaddr_storage).
So when we implement new protocol support we should keep such
a detail in mind (which is easy to forget about).
Lets introduce DECLARE_SOCKADDR helper which check if
storage unit is not overfowed at build time.
Eventually inet_getname is switched to use DECLARE_SOCKADDR
(to show example of usage).
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
---
include/linux/net.h | 3 +++
include/linux/socket.h | 3 +++
net/ipv4/af_inet.c | 2 +-
3 files changed, 7 insertions(+), 1 deletion(-)
Index: linux-2.6.git/include/linux/net.h
=====================================================================
--- linux-2.6.git.orig/include/linux/net.h
+++ linux-2.6.git/include/linux/net.h
@@ -198,6 +198,9 @@ struct proto_ops {
struct pipe_inode_info *pipe, size_t len, unsigned int flags);
};
+#define DECLARE_SOCKADDR(type, dst, src) \
+ type dst = ({ __sockaddr_check_size(sizeof(*dst)); (type) src; })
+
struct net_proto_family {
int family;
int (*create)(struct net *net, struct socket *sock, int protocol);
Index: linux-2.6.git/include/linux/socket.h
=====================================================================
--- linux-2.6.git.orig/include/linux/socket.h
+++ linux-2.6.git/include/linux/socket.h
@@ -24,6 +24,9 @@ struct __kernel_sockaddr_storage {
#include <linux/types.h> /* pid_t */
#include <linux/compiler.h> /* __user */
+#define __sockaddr_check_size(size) \
+ BUILD_BUG_ON(((size) > sizeof(struct __kernel_sockaddr_storage)))
+
#ifdef __KERNEL__
# ifdef CONFIG_PROC_FS
struct seq_file;
Index: linux-2.6.git/net/ipv4/af_inet.c
=====================================================================
--- linux-2.6.git.orig/net/ipv4/af_inet.c
+++ linux-2.6.git/net/ipv4/af_inet.c
@@ -685,7 +685,7 @@ int inet_getname(struct socket *sock, st
{
struct sock *sk = sock->sk;
struct inet_sock *inet = inet_sk(sk);
- struct sockaddr_in *sin = (struct sockaddr_in *)uaddr;
+ DECLARE_SOCKADDR(struct sockaddr_in *, sin, uaddr);
sin->sin_family = AF_INET;
if (peer) {
^ permalink raw reply
* Re: [PATCH] net: allow netdev_wait_allrefs() to run faster
From: Paul E. McKenney @ 2009-10-24 14:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Octavian Purdila, Benjamin LaHaise, netdev, Cosmin Ratiu
In-Reply-To: <4AE30E1B.5080008@gmail.com>
On Sat, Oct 24, 2009 at 04:24:27PM +0200, Eric Dumazet wrote:
> Paul E. McKenney a écrit :
> > On Sat, Oct 24, 2009 at 10:49:55AM +0200, Eric Dumazet wrote:
> >>
> >> On my dev machine, a synchronize_rcu() lasts between 2 an 12 ms
> >
> > That sounds like the right range, depending on what else is happening
> > on the machine at the time.
> >
> > The synchronize_rcu_expedited() primitive would run in the 10s-100s
> > of microseconds. It involves a pair of wakeups and a pair of context
> > switches on each CPU.
>
> Hmm... I'll make some experiments Monday and post results, but it seems very
> promising.
I should hasten to add that synchronize_rcu_expedited() goes fast for
TREE_RCU but not yet for TREE_PREEMPT_RCU (where it maps safely but
slowly to synchronize_rcu()).
> Do you think the "on_each_cpu(flush_backlog, dev, 1);"
> we perform right before calling netdev_wait_allrefs() could be changed
> somehow to speedup rcu callbacks ? Maybe we ould avoid sending IPI twice to
> cpus ?
This is an interesting possibility, and might fit in with some of the
changes that I am thinking about to reduce OS jitter for the heavy-duty
numerical-computing guys.
In the meantime, you could try doing the following from flush_backlog():
local_irq_save(flags);
rcu_check_callbacks(smp_processor_id(), 0);
local_irq_restore(flags);
This would emulate a much-faster HZ value, but only for RCU. This works
better in TREE_RCU than it does in TREE_PREEMPT_RCU at the moment (on my
todo list!). In older kernels, this should also work for CLASSIC_RCU.
Of course, in TINY_RCU, synchronize_rcu() is a no-op anyway. ;-)
And just to be clear, synchronize_rcu_expedited() currently just does
wakeups, not explicit IPIs.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH] net: allow netdev_wait_allrefs() to run faster
From: Eric Dumazet @ 2009-10-24 14:24 UTC (permalink / raw)
To: paulmck; +Cc: Octavian Purdila, Benjamin LaHaise, netdev, Cosmin Ratiu
In-Reply-To: <20091024135214.GB6638@linux.vnet.ibm.com>
Paul E. McKenney a écrit :
> On Sat, Oct 24, 2009 at 10:49:55AM +0200, Eric Dumazet wrote:
>>
>> On my dev machine, a synchronize_rcu() lasts between 2 an 12 ms
>
> That sounds like the right range, depending on what else is happening
> on the machine at the time.
>
> The synchronize_rcu_expedited() primitive would run in the 10s-100s
> of microseconds. It involves a pair of wakeups and a pair of context
> switches on each CPU.
>
Hmm... I'll make some experiments Monday and post results, but it seems very
promising.
Do you think the "on_each_cpu(flush_backlog, dev, 1);"
we perform right before calling netdev_wait_allrefs() could be changed
somehow to speedup rcu callbacks ? Maybe we ould avoid sending IPI twice to
cpus ?
Thanks
^ permalink raw reply
* Re: Request: how do packet routing based on input gateway
From: Dunc @ 2009-10-24 14:19 UTC (permalink / raw)
To: Luca Dionisi; +Cc: netdev, linux-net
In-Reply-To: <73dbe2850910240622s2453c252p17d928f8a94ffe33@mail.gmail.com>
If both of your last hops are on the same subnet you can't use incoming
interface, so the only thing I can think of is to match the MAC address
of the ethernet frame. If the last hop wasn't the source of the packet I
don't think there's anything else to uniquely identify it.
Cheers,
Dunc
Luca Dionisi wrote:
> Hi all
>
> I must instruct my server to route packets based on destination prefix
> and on the gateway from which the packet arrived.
> E.g.
> I am 192.168.0.1
> a packet for 192.168.1.0/24 which arrived from gateway 192.168.0.2
> must go through 192.168.1.1 dev eth0
> a packet for 192.168.1.0/24 which arrived from gateway 192.168.0.3
> must go through 192.168.1.2 dev eth1
> a packet for 192.168.1.0/24 which arrived from any other gateway must
> go through 192.168.1.3 dev eth2
>
> The gateway I mean is just the last hop traversed, before me. It's not
> necessarily the source of the packet.
>
> How am I supposed to do that?
>
> Regards.
> Luca Dionisi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] [PATCH] cxgb3: Set the rxq
From: David Miller @ 2009-10-24 14:07 UTC (permalink / raw)
To: divy; +Cc: krkumar2, netdev
In-Reply-To: <op.u193nu1zduofyu@speedy5>
From: "Divy Le Ray" <divy@chelsio.com>
Date: Fri, 23 Oct 2009 17:29:44 -0700
> On Fri, 23 Oct 2009 04:13:21 -0700, Krishna Kumar
> <krkumar2@in.ibm.com> wrote:
>
>> From: Krishna Kumar <krkumar2@in.ibm.com>
>>
>> Set the rxq# for LRO when processing the last fragment of a
>> frame. This helps in fast txq selection for routing workloads.
>>
>> Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
>
> Acked-by: Divy Le Ray <divy@chelsio.com>
Applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: [PATCH] Modify bonding hash transmit policies to use the packet's source MAC address
From: David Miller @ 2009-10-24 14:02 UTC (permalink / raw)
To: fubar; +Cc: spaans, eric.dumazet, netdev
In-Reply-To: <15644.1256314992@death.nxdomain.ibm.com>
From: Jay Vosburgh <fubar@us.ibm.com>
Date: Fri, 23 Oct 2009 09:23:12 -0700
> Jasper Spaans <spaans@fox-it.com> wrote:
>
>>Modify bonding hash transmit policies to use the psource MAC address of
>>the packet instead of the MAC address configured for the bonding device.
>>
>>The old sitation conflicts with the documentation.
>>
>>Signed-off-by: Jasper Spaans <spaans@fox-it.com>
>
> Looks good.
>
> Dave, please apply. This may be suitable for -stable, as it's
> pretty much a day one bug.
Applied, and queued up for stable, thanks everyone.
^ permalink raw reply
* Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2
From: Sven Geggus @ 2009-10-24 14:02 UTC (permalink / raw)
To: Mel Gorman
Cc: Frans Pop, Jiri Kosina, Karol Lewandowski, Tobias Oetiker,
Rafael J. Wysocki, David Miller, Reinette Chatre, Kalle Valo,
David Rientjes, KOSAKI Motohiro, Mohamed Abbas, Jens Axboe,
John W. Linville, Pekka Enberg, Bartlomiej Zolnierkiewicz,
Greg Kroah-Hartman, Stephan von Krawczynski, Kernel Testers List,
netdev, linux-kernel, linux-mm@kvack.org
In-Reply-To: <1256221356-26049-1-git-send-email-mel@csn.ul.ie>
Mel Gorman schrieb am Donnerstag, den 22. Oktober um 16:22 Uhr:
> Test 1: Verify your problem occurs on 2.6.32-rc5 if you can
Problem persists. RAID resync in progress :(
Sven
--
"linux is evolution, not intelligent design"
(Linus Torvalds)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC] [PATCH] udp: Don't save dst in udpv6_sendmsg()
From: Krishna Kumar2 @ 2009-10-24 14:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091024.064915.76607526.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote on 10/24/2009 07:19:15 PM:
>
> >> Who actually uses connected UDP sockets? :-)
> >
> > Just something I found when running netperf RR tests, and the code is
there
> > doing it anyway. Maybe I can drop doing this testing, but upto you.
>
> Eric Dumazet or someone else made comments recently about how
> nobody uses connected UDP sockets.
>
> And if someone actually does, they can complain and we can
> go back to looking into it :-)
Agreed. Please drop it.
Thanks,
- KK
^ permalink raw reply
* Re: [PATCH] Remove bond_dev from xmit_hash_policy call.
From: David Miller @ 2009-10-24 14:00 UTC (permalink / raw)
To: fubar; +Cc: spaans, eric.dumazet, netdev
In-Reply-To: <15659.1256315071@death.nxdomain.ibm.com>
From: Jay Vosburgh <fubar@us.ibm.com>
Date: Fri, 23 Oct 2009 09:24:31 -0700
> Jasper Spaans <spaans@fox-it.com> wrote:
>
>>Now that the bonding device is no longer used in determining the device to
>>which to send packets, it can be dropped from the argument list of the various
>>xmit_hash_policy calls.
>>
>>Signed-off-by: Jasper Spaans <spaans@fox-it.com>
>
> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] pktgen: Dont leak kernel memory
From: David Miller @ 2009-10-24 13:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4ADE95C6.40103@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 21 Oct 2009 07:01:58 +0200
> [PATCH] pktgen: Dont leak kernel memory
>
> While playing with pktgen, I realized IP ID was not filled and a random value
> was taken, possibly leaking 2 bytes of kernel memory.
>
> We can use an increasing ID, this can help diagnostics anyway.
>
> Also clear packet payload, instead of leaking kernel memory.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: DM9000: Fix revision ID for DM9000B
From: David Miller @ 2009-10-24 13:53 UTC (permalink / raw)
To: ben; +Cc: netdev, linux
In-Reply-To: <20091023102631.373421273@fluff.org.uk>
From: Ben Dooks <ben@simtec.co.uk>
Date: Fri, 23 Oct 2009 11:26:31 +0100
> The DM9000B revision ID is 0x1A, not 0x1B as set in the curernt dm9000.h
> header.
>
> Fix bug reported by Paolo Zebelloni.
>
> Signed-off-by: Ben Dooks <ben@simtec.co.uk>
> Signed-off-by: Simtec Linux Team <linux@simtec.co.uk>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: allow netdev_wait_allrefs() to run faster
From: Paul E. McKenney @ 2009-10-24 13:52 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Octavian Purdila, Benjamin LaHaise, netdev, Cosmin Ratiu
In-Reply-To: <4AE2BFB3.3060407@gmail.com>
On Sat, Oct 24, 2009 at 10:49:55AM +0200, Eric Dumazet wrote:
> Paul E. McKenney a écrit :
> > On Sat, Oct 24, 2009 at 06:35:53AM +0200, Eric Dumazet wrote:
> >
> >> Maybe we could call it once only, if we had to call 1 times
> >> the jiffie delay ?
> >
> > This could be a very useful approach!
> >
> > However, please keep in mind that although synchronize_rcu_expedited()
> > forces a grace period, it does nothing to speed the invocation of other
> > RCU callbacks. In short, synchronize_rcu_expedited() is a faster version
> > of synchronize_rcu(), but doesn't necessarily help other synchronize_rcu()
> > or call_rcu() invocations.
> >
> > The reason I point this out is that it looks to me that the code below is
> > waiting for some other task which is in turn waiting on a grace period.
> > But I don't know this code, so could easily be confused.
> >
>
> Normally, we need a synchronize_rcu() calls, but I feel its bit more than really
> needed here.
>
> On my dev machine, a synchronize_rcu() lasts between 2 an 12 ms
That sounds like the right range, depending on what else is happening
on the machine at the time.
The synchronize_rcu_expedited() primitive would run in the 10s-100s
of microseconds. It involves a pair of wakeups and a pair of context
switches on each CPU.
Thanx, Paul
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.580259] synchronize_net() 4045596 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.588262] synchronize_net() 7769327 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.625014] synchronize_net() 4772052 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.633008] synchronize_net() 7773896 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.669260] synchronize_net() 3958141 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.677259] synchronize_net() 7755817 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.712011] synchronize_net() 2502544 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.720011] synchronize_net() 7767748 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.754259] synchronize_net() 2087946 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.762258] synchronize_net() 7738054 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.796011] synchronize_net() 3392760 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.808025] synchronize_net() 11814619 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.848010] synchronize_net() 8970220 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.856015] synchronize_net() 7800782 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.893008] synchronize_net() 6650174 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.897012] synchronize_net() 3744808 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.940202] synchronize_net() 8354366 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.952137] synchronize_net() 11693215 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.985010] synchronize_net() 2355970 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.989009] synchronize_net() 3771419 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.028137] synchronize_net() 7661195 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.036152] synchronize_net() 7800056 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.083135] synchronize_net() 6774026 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.089145] synchronize_net() 5727189 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.130385] synchronize_net() 10133932 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.134399] synchronize_net() 3773058 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.170136] synchronize_net() 4479194 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.178138] synchronize_net() 7710466 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.217198] synchronize_net() 4323437 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.226206] synchronize_net() 8723108 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.268013] synchronize_net() 6221155 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.280007] synchronize_net() 11719297 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.324008] synchronize_net() 11654511 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.332009] synchronize_net() 7744182 ns
>
^ permalink raw reply
* Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2
From: Frans Pop @ 2009-10-24 13:51 UTC (permalink / raw)
To: Mel Gorman
Cc: Jiri Kosina, Sven Geggus, Karol Lewandowski, Tobias Oetiker,
Rafael J. Wysocki, David Miller, Reinette Chatre, Kalle Valo,
David Rientjes, KOSAKI Motohiro, Mohamed Abbas, Jens Axboe,
John W. Linville, Pekka Enberg, Bartlomiej Zolnierkiewicz,
Greg Kroah-Hartman, Stephan von Krawczynski, Kernel Testers List,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org"
In-Reply-To: <1256221356-26049-1-git-send-email-mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org>
On Thursday 22 October 2009, Mel Gorman wrote:
> Since 2.6.31-rc1, there have been an increasing number of GFP_ATOMIC
> failures. A significant number of these have been high-order GFP_ATOMIC
> failures and while they are generally brushed away, there has been a
> large increase in them recently and there are a number of possible areas
> the problem could be in - core vm, page writeback and a specific driver.
I needed a break and have thus been off-line for a few days. Good to see
there's been progress. I'll try to do some testing tomorrow.
Cheers,
FJP
^ permalink raw reply
* Re: [RFC] [PATCH] udp: Don't save dst in udpv6_sendmsg()
From: David Miller @ 2009-10-24 13:49 UTC (permalink / raw)
To: krkumar2; +Cc: netdev, netdev-owner
In-Reply-To: <OF34F531CA.C8E6FDAE-ON65257659.004B6782-65257659.004B99F8@in.ibm.com>
From: Krishna Kumar2 <krkumar2@in.ibm.com>
Date: Sat, 24 Oct 2009 19:15:46 +0530
> David Miller wrote on 10/24/2009 07:10:10 PM:
>>
>> > Performance: I ran netperf UDPv6 RR to use connected sockets.
>> > Tested with a 70 min run, aggregate of 5 netperf runs for
>> > each result.
>>
>> Who actually uses connected UDP sockets? :-)
>
> Just something I found when running netperf RR tests, and the code is there
> doing it anyway. Maybe I can drop doing this testing, but upto you.
Eric Dumazet or someone else made comments recently about how
nobody uses connected UDP sockets.
And if someone actually does, they can complain and we can
go back to looking into it :-)
^ permalink raw reply
* Re: [PATCHv2 2.6.32-rc5] r8169: fix Ethernet Hangup for RTL8110SC rev d
From: David Miller @ 2009-10-24 13:48 UTC (permalink / raw)
To: simon.wunderlich; +Cc: netdev, simon.wunderlich, bernhard.schmidt, romieu
In-Reply-To: <20091023065717.GA22484@pandem0nium>
From: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
Date: Fri, 23 Oct 2009 08:57:17 +0200
...
> Signed-off-by: Bernhard Schmidt <bernhard.schmidt@saxnet.de>
> Signed-off-by: Simon Wunderlich <simon.wunderlich@saxnet.de>
> Acked-by: Francois Romieu <romieu@zoreil.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2
From: Mel LKML @ 2009-10-24 13:46 UTC (permalink / raw)
To: Karol Lewandowski
Cc: Mel Gorman, Frans Pop, Jiri Kosina, Sven Geggus, Tobias Oetiker,
Rafael J. Wysocki, David Miller, Reinette Chatre, Kalle Valo,
David Rientjes, KOSAKI Motohiro, Mohamed Abbas, Jens Axboe,
John W. Linville, Pekka Enberg, Bartlomiej Zolnierkiewicz,
Greg Kroah-Hartman, Stephan von Krawczynski, Kernel Testers List,
netdev, linux-kernel, linux-mm@kvack.org
In-Reply-To: <20091023211239.GA6185@bizet.domek.prywatny>
Hi,
This is the same Mel as mel@csn.ul.ie. The mail server the address is
on has no power until Tuesday so I'm not going to be very unresponsive
until then. Monday is also a public holiday here and apparently they
are upgrading the power transformers near the building.
On 10/23/09, Karol Lewandowski <karol.k.lewandowski@gmail.com> wrote:
> On Fri, Oct 23, 2009 at 06:58:10PM +0200, Karol Lewandowski wrote:
>> On Thu, Oct 22, 2009 at 03:22:31PM +0100, Mel Gorman wrote:
>> > Test 3: If you are getting allocation failures, try with the following
>> > patch
>> >
>> > 3/5 vmscan: Force kswapd to take notice faster when high-order
>> > watermarks are being hit
>
>> No, problem doesn't go away with these patches (1+2+3). However, from
>> my testing this particular patch makes it way, way harder to trigger
>> allocation failures (but these are still present).
>>
>> This bothers me - should I test following patches with or without
>> above patch? This patch makes bug harder to find, IMVHO it doesn't
>> fix the real problem.
> ..
>
>> Test 4: If you are still getting failures, apply the following
>> 4/5 page allocator: Pre-emptively wake kswapd when high-order watermarks
>> are hit
>
> Ok, I've tested patches 1+2+4 and bug, while very hard to trigger, is
> still present. I'll test complete 1-4 patchset as time permits.
>
And also patch 5 please which is the revert. Patch 5 as pointed out is
probably a red herring. Hwoever, it has changed the timing and made a
difference for some testing so I'd like to know if it helps yours as
well.
As things stand, it looks like patches 1+2 should certainly go ahead.
I need to give more thought on patches 3 and 4 as to why they help
Tobias but not anyone elses testing.
Thanks
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC] [PATCH] udp: Don't save dst in udpv6_sendmsg()
From: Krishna Kumar2 @ 2009-10-24 13:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev, netdev-owner
In-Reply-To: <20091024.064010.145864194.davem@davemloft.net>
David Miller wrote on 10/24/2009 07:10:10 PM:
>
> > Performance: I ran netperf UDPv6 RR to use connected sockets.
> > Tested with a 70 min run, aggregate of 5 netperf runs for
> > each result.
>
> Who actually uses connected UDP sockets? :-)
Just something I found when running netperf RR tests, and the code is there
doing it anyway. Maybe I can drop doing this testing, but upto you.
Thanks,
- KK
^ permalink raw reply
* Re: PATCH 23/10]Optimize the upload speed for PPP connection.
From: David Miller @ 2009-10-24 13:46 UTC (permalink / raw)
To: william.allen.simpson; +Cc: huananhu, netdev, linux-kernel, zihan, greg, haegar
In-Reply-To: <4AE19780.3020507@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Fri, 23 Oct 2009 07:46:08 -0400
> Concur. I'd go further than that, my code usually made room for at
> least
> a full MTU (MRU) with HDLC escaping. To minimize context switches,
> that
> should be 3014 ((1500 MRU + 2 FCS + 4 header) * 2 escapes + 2 flags).
>
> Even in the old days, when memory was tight, context switches and
> interrupt
> time were more expensive, too. PPP is supposed to scale to OC-192.
Actually I'd like to see ->obuf allocated externally and then
make it simply PAGE_SIZE.
^ permalink raw reply
* iwl3945, after a while stops working with "No space for Tx"
From: Frederik Nosi @ 2009-10-24 13:44 UTC (permalink / raw)
To: Zhu Yi, Reinette Chatre, Intel Linux Wireless, John W. Linville,
Tomas Winkler <tomas.
Cc: netdev, linux-kernel
Hi,
first sorry if somebody is not the right contact, got the adressess from ./scripts/get_maintainer.pl -f drivers/net/wireless/iwlwifi.
>From some kernel versions now, after some time that im using this card it stops working and on messages i get this errors:
Oct 24 14:38:24 kotys NetworkManager: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) complete.
[snip pulseaudio's stuppid log spam warning]
Oct 24 14:40:07 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out after 500ms.
Oct 24 14:40:09 kotys pulseaudio[16469]: sap.c: sendmsg() failed: Invalid argument
Oct 24 14:40:10 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_SCAN_CMD: time out after 500ms.
Oct 24 14:40:11 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out after 500ms.
Oct 24 14:40:11 kotys kernel: iwl3945 0000:04:00.0: Error sending POWER_TABLE_CMD: time out after 500ms.
Oct 24 14:40:14 kotys kernel: iwl3945 0000:04:00.0: set power fail, ret = -110
Oct 24 14:40:14 kotys kernel: No probe response from AP 00:1c:df:82:63:c9 after 500ms, disconnecting.
Oct 24 14:40:14 kotys NetworkManager: <info> (wlan0): supplicant connection state: completed -> disconnected
Oct 24 14:40:14 kotys NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning
Oct 24 14:40:14 kotys pulseaudio[16469]: sap.c: sendmsg() failed: Invalid argument
Oct 24 14:40:14 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_RXON: time out after 500ms.
Oct 24 14:40:14 kotys kernel: iwl3945 0000:04:00.0: Error setting new configuration (-110).
Oct 24 14:40:15 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_SCAN_CMD: time out after 500ms.
Oct 24 14:40:15 kotys kernel: wlan0: direct probe to AP 00:1c:df:82:63:c9 (try 1)
Oct 24 14:40:15 kotys NetworkManager: <info> (wlan0): supplicant connection state: scanning -> associating
Oct 24 14:40:15 kotys kernel: wlan0: direct probe to AP 00:1c:df:82:63:c9 (try 2)
Oct 24 14:40:15 kotys kernel: wlan0: direct probe to AP 00:1c:df:82:63:c9 (try 3)
Oct 24 14:40:15 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_RXON: time out after 500ms.
Oct 24 14:40:15 kotys kernel: iwl3945 0000:04:00.0: Error setting new configuration (-110).
Oct 24 14:40:15 kotys kernel: wlan0: direct probe to AP 00:1c:df:82:63:c9 timed out
Oct 24 14:40:16 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out after 500ms.
Oct 24 14:40:16 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_RXON: time out after 500ms.
Oct 24 14:40:16 kotys kernel: iwl3945 0000:04:00.0: Error setting new configuration (-110).
When this happens i am able to use the card only after reloading the related modules, iwl3945 ecc. But the problem happens again after some minutes that im connected.
Kernel is 2.6.32-rc5 but his started happening around 2.6.31, not sure exactly what version as i update kernel often. Firmware is iwl3945-ucode-15.32.2.9.
Every other info that you need just ask. I hope i dont have to bisect as this is the laptop i use for work too, but if it's needed i'll do.
I'm not subscribed on any ML, so in case please cc me.
Thanks for all the work!
F.
^ permalink raw reply
* Re: [RFC] [PATCH] udp: Don't save dst in udpv6_sendmsg()
From: David Miller @ 2009-10-24 13:40 UTC (permalink / raw)
To: krkumar2; +Cc: netdev
In-Reply-To: <20091023111336.4733.4901.sendpatchset@localhost.localdomain>
From: Krishna Kumar <krkumar2@in.ibm.com>
Date: Fri, 23 Oct 2009 16:43:36 +0530
> Performance: I ran netperf UDPv6 RR to use connected sockets.
> Tested with a 70 min run, aggregate of 5 netperf runs for
> each result.
Who actually uses connected UDP sockets? :-)
^ permalink raw reply
* Re: [PATCH net-next-2.6] xfrm6_tunnel: RCU conversion
From: Eric Dumazet @ 2009-10-24 13:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev, yoshfuji
In-Reply-To: <20091024.060920.258223911.davem@davemloft.net>
David Miller a écrit :
> Nice work Eric, I applied all of your RCU conversions to
> net-next-2.6, thanks!
>
> Applying: ipv6 sit: RCU conversion phase I
> Applying: ipv6 sit: RCU conversion phase II
> Applying: xfrm6_tunnel: RCU conversion
> Applying: ipip: convert hash tables locking to RCU
> Applying: ip6tnl: convert hash tables locking to RCU
> Applying: gre: convert hash tables locking to RCU
Thanks a lot !
^ permalink raw reply
* Re: Irq architecture for multi-core network driver.
From: David Miller @ 2009-10-24 13:26 UTC (permalink / raw)
To: ebiederm
Cc: jesse.brandeburg, ddaney, cfriesen, netdev, linux-kernel,
linux-mips
In-Reply-To: <m17huln1ab.fsf@fess.ebiederm.org>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Fri, 23 Oct 2009 16:22:36 -0700
> irqbalance is actually more likely to move irqs than the hardware.
> I have heard promises it won't move network irqs but I have seen
> the opposite behavior.
It knows what network devices are named, and looks for those keys
in /proc/interrupts. Anything names 'ethN' will not be moved and
if you name them on a per-queue basis properly (ie. 'ethN-RX1' etc.)
it will flat distribute those interrupts amongst the cpus in the
machine.
So if you're doing "silly stuff" and naming your devices by some other
convention, you would end up defeating the detations built into
irqbalanced.
Actually, let's not even guess, go check out the sources of the
irqbalanced running on your system and make sure it has the network
device logic in it. :-)
^ permalink raw reply
* Re: Irq architecture for multi-core network driver.
From: David Miller @ 2009-10-24 13:23 UTC (permalink / raw)
To: ddaney; +Cc: cfriesen, netdev, linux-kernel, linux-mips
In-Reply-To: <4AE0DB98.1000101@caviumnetworks.com>
From: David Daney <ddaney@caviumnetworks.com>
Date: Thu, 22 Oct 2009 15:24:24 -0700
> Certainly this is one mode of operation that should be supported, but
> I would also like to be able to go for raw throughput and have as many
> cores as possible reading from a single queue (like I currently have).
You can't do this, at least within the same flow, since as you even
mention in your original posting this can result in packet reordering
which we must avoid as much as is possible.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox