Re: [PATCH 2/3] netpoll: rework skb transmit queue

2006-10-21 Thread David Miller
From: Dave Jones [EMAIL PROTECTED] Date: Sat, 21 Oct 2006 01:00:16 -0400 Practically no-one cared about it, so it bit-rotted really fast after we shipped RHEL4. That, along with the focus shifting to making kdump work seemed to kill it off over the last 12 months. Then we can truly kill off

Re: [PATCH 2/3] netpoll: rework skb transmit queue

2006-10-20 Thread David Miller
From: Stephen Hemminger [EMAIL PROTECTED] Date: Thu, 19 Oct 2006 10:15:43 -0700 The original skb management for netpoll was a mess, it had two queue paths and a callback. This changes it to have a per-instance transmit queue and use a tasklet rather than a work queue for the congested case.

Re: [PATCH 2/3] netpoll: rework skb transmit queue

2006-10-20 Thread Stephen Hemminger
On Fri, 20 Oct 2006 00:15:30 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Thu, 19 Oct 2006 10:15:43 -0700 The original skb management for netpoll was a mess, it had two queue paths and a callback. This changes it to have a per-instance

[PATCH 2/3] netpoll: rework skb transmit queue

2006-10-20 Thread Stephen Hemminger
Change netpoll to use a skb queue for transmit. This solves problems where there are two tx paths that can cause things to get out of order and different semantics when netconsole output goes through fast and slow paths. The only user of the drop hook was netconsole, and I fixed that path. This

Re: [PATCH 2/3] netpoll: rework skb transmit queue

2006-10-20 Thread David Miller
From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 08:18:57 -0700 Netdump is not in the tree, so I can't fix it. Also netdump is pretty much superseded by kdump. Unless kdump is %100 ready you can be sure vendors will ship netdump for a little while longer. I think gratuitously

Re: [PATCH 2/3] netpoll: rework skb transmit queue

2006-10-20 Thread Stephen Hemminger
On Fri, 20 Oct 2006 12:24:27 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 08:18:57 -0700 Netdump is not in the tree, so I can't fix it. Also netdump is pretty much superseded by kdump. Unless kdump is %100 ready you

Re: [PATCH 2/3] netpoll: rework skb transmit queue

2006-10-20 Thread David Miller
From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 08:40:15 -0700 The only user of the drop hook was netconsole, and I fixed that path. This probably breaks netdump, but that is out of tree, so it needs to fix itself. I believe that netdump needs to requeue things because

Re: [PATCH 2/3] netpoll: rework skb transmit queue

2006-10-20 Thread Stephen Hemminger
On Fri, 20 Oct 2006 12:27:53 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 08:40:15 -0700 The only user of the drop hook was netconsole, and I fixed that path. This probably breaks netdump, but that is out of tree, so it

Re: [PATCH 2/3] netpoll: rework skb transmit queue

2006-10-20 Thread David Miller
From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 12:25:27 -0700 Sorry, but why should we treat out-of-tree vendor code any differently than out-of-tree other code. I think what netdump was trying to do, provide a way to requeue instead of fully drop the SKB, is quite

Re: [PATCH 2/3] netpoll: rework skb transmit queue

2006-10-20 Thread Stephen Hemminger
On Fri, 20 Oct 2006 12:52:26 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 12:25:27 -0700 Sorry, but why should we treat out-of-tree vendor code any differently than out-of-tree other code. I think what netdump was

Re: [PATCH 2/3] netpoll: rework skb transmit queue

2006-10-20 Thread Stephen Hemminger
On Fri, 20 Oct 2006 12:52:26 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 12:25:27 -0700 Sorry, but why should we treat out-of-tree vendor code any differently than out-of-tree other code. I think what netdump was

Re: [PATCH 2/3] netpoll: rework skb transmit queue

2006-10-20 Thread David Miller
From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 08:40:15 -0700 -static void queue_process(void *p) +static void netpoll_run(unsigned long arg) { ... - spin_unlock_irqrestore(queue_lock, flags); + netif_tx_lock(dev); + if

Re: [PATCH 2/3] netpoll: rework skb transmit queue

2006-10-20 Thread Stephen Hemminger
On Fri, 20 Oct 2006 13:42:09 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 08:40:15 -0700 -static void queue_process(void *p) +static void netpoll_run(unsigned long arg) { ... -

Re: [PATCH 2/3] netpoll: rework skb transmit queue

2006-10-20 Thread Andi Kleen
But, it also violates the assumptions of the network devices. It calls NAPI poll back with IRQ's disabled and potentially doesn't obey the semantics about only running on the same CPU as the received packet. netpoll always played a little fast'n'lose with various locking rules. Also often

Re: [PATCH 2/3] netpoll: rework skb transmit queue

2006-10-20 Thread David Miller
From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 13:48:26 -0700 On Fri, 20 Oct 2006 13:42:09 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: We really can't handle TX stopped this way from the netpoll_send_skb() path. All that old retry logic in netpoll_send_skb() is

Re: [PATCH 2/3] netpoll: rework skb transmit queue

2006-10-20 Thread David Miller
From: Andi Kleen [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 23:01:29 +0200 netpoll always played a little fast'n'lose with various locking rules. The current code is fine, it never reenters -poll, because it maintains a -poll_owner which it checks in netpoll_send_skb() before trying to call back

Re: [PATCH 2/3] netpoll: rework skb transmit queue

2006-10-20 Thread Andi Kleen
On Friday 20 October 2006 23:08, David Miller wrote: From: Andi Kleen [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 23:01:29 +0200 netpoll always played a little fast'n'lose with various locking rules. The current code is fine, it never reenters -poll, because it maintains a -poll_owner which

Re: [PATCH 2/3] netpoll: rework skb transmit queue

2006-10-20 Thread Stephen Hemminger
On Fri, 20 Oct 2006 23:16:03 +0200 Andi Kleen [EMAIL PROTECTED] wrote: On Friday 20 October 2006 23:08, David Miller wrote: From: Andi Kleen [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 23:01:29 +0200 netpoll always played a little fast'n'lose with various locking rules. The current

Re: [PATCH 2/3] netpoll: rework skb transmit queue

2006-10-20 Thread Dave Jones
On Fri, Oct 20, 2006 at 01:25:32PM -0700, Stephen Hemminger wrote: On Fri, 20 Oct 2006 12:52:26 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 12:25:27 -0700 Sorry, but why should we treat out-of-tree vendor

[PATCH 2/3] netpoll: rework skb transmit queue

2006-10-19 Thread Stephen Hemminger
The original skb management for netpoll was a mess, it had two queue paths and a callback. This changes it to have a per-instance transmit queue and use a tasklet rather than a work queue for the congested case. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- drivers/net/netconsole.c |