Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
On Wed, Aug 16, 2006 at 04:32:52PM -0700, David Miller wrote: > From: [EMAIL PROTECTED] (Linas Vepstas) > > Why would you want to do this? It seems like a cruddier strategy > > than what we can already do (which is to never get an transmit > > interrupt, as long as the kernel can shove data into the device fast > > enough to keep the queue from going empty.) The whole *point* of a > > low-watermark interrupt is to never have to actually get the interrupt, > > if the rest of the system is on its toes and is supplying data fast > > enough. > > As long as TX packets get freed within a certain latency > boundary, this kind of scheme should be fine. I just had some fun making sure I wasn't making a liar out of myself. So far, I'm good. Did echo 768111 > /proc/sys/net/core/wmem_max echo 768111 > /proc/sys/net/core/wmem_default to make sure that the app never blocked on a full socket. (If the socket is small, then the app blocks, the transmit queue drains, and we do get an interupt -- about 1K/sec, which is what is expected). Ran 'vmstat 10' to watch the interrupts in real time. Ran netperf, got 904 Mbits/sec, and *no* interrupts. Yahoo! Ran oprofile to see where he time went: CPU: ppc64 Cell Broadband Engine, speed 3200 MHz (estimated) Counted CYCLES events (Processor Cycles) with a unit mask of 0x00 (No unit mask) count 10 samples %image name app name symbol name 13748742 77.6620 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .cbe_idle 9361725.2881 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .__copy_tofrom_user 5693533.2161 spidernet.ko spidernet .spider_net_xmit 4508262.5466 spidernet.ko spidernet .spider_net_release_tx_chain 2203741.2448 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 ._spin_unlock_irqrestore 1124320.6351 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 ._spin_lock 91328 0.5159 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .__qdisc_run 84804 0.4790 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .packet_sendmsg 76167 0.4302 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .kfree 74321 0.4198 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .sock_alloc_send_skb 65323 0.3690 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .kmem_cache_free 60334 0.3408 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 ._read_lock 60071 0.3393 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .dev_queue_xmit 56900 0.3214 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .kmem_cache_alloc_node 55281 0.3123 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .sock_wfree 51242 0.2894 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .dev_get_by_index 50438 0.2849 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .compat_sys_socketcall 49247 0.2782 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .fput 48589 0.2745 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .sync_buffer 46055 0.2601 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 system_call_common 40607 0.2294 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .local_bh_enable 40273 0.2275 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .__might_sleep 38757 0.2189 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .fget_light 38219 0.2159 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .__kfree_skb 36804 0.2079 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .sock_def_write_space 36443 0.2059 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .skb_release_data 32174 0.1817 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .sys_sendto 31828 0.1798 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .sock_sendmsg 30676 0.1733 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .pfifo_fast_dequeue 29607 0.1672 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .add_event_entry 25870 0.1461 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 syscall_exit 25329 0.1431 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .__alloc_skb 23885 0.1349 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .__do_softirq 22046 0.1245 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .kmem_find_general_cachep 21610 0.1221 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .__dev_get_by_index 21059 0.1190 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .dma_map_single 21044 0.1189 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 ._spin_lock_irqsave 20105 0.1136 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .memset .__copy_tofrom_user -- ouch spider does not currently do scatter-gather .spider_net_xmit -- hmmm ?? why is it this large ?? .spider_net_release_tx_chain -- ?? a lot of time being spent cleaning up tx queues. ._spin_unlock_irqrestore -- hmm ? why so high? lock contention? I presume the rest is normal
Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
On Thu, Aug 17, 2006 at 01:03:20AM +0200, Arnd Bergmann wrote: > > Could well be related to latencies when going to the remote > node for descriptor DMAs. Have you tried if the hch's NUMA > patch or using numactl makes a difference here? No. I guess I should try. > > > sounds like the right approach to simplify the code. > > > > Its not a big a driver. 'wc' says its 2.3 loc, which > > is 1/3 or 1/5 the size of tg3.c or the e1000*c files. > > Right, I was thinking of removing a lock or another, not > throwing out half of the driver ;-) There's only four lock points grand total. -- One on the receive side, -- one to protect the transmit head pointer, -- one to protect the transmit tail pointer, -- one to protect the location of the transmit low watermark. The last three share the same lock. I tried using distinct locks, but this worsened things, probably due to cache-line trashing. I tried removing the head pointer lock, but this failed. I don't know why, and was surprised by this. I thought hard_start_xmit() was serialized. --linas - 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
Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
From: [EMAIL PROTECTED] (Linas Vepstas) Date: Wed, 16 Aug 2006 18:30:28 -0500 > Why would you want o do this? It seems like a cruddier strategy > than what we can already do (which is to never get an transmit > interrupt, as long as the kernel can shove data into the device fast > enough to keep the queue from going empty.) The whole *point* of a > low-watermark interrupt is to never have to actually get the interrupt, > if the rest of the system is on its toes and is supplying data fast > enough. As long as TX packets get freed within a certain latency boundary, this kind of scheme should be fine. - 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
Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
On Thu, Aug 17, 2006 at 12:16:46AM +0200, Arnd Bergmann wrote: > Am Wednesday 16 August 2006 23:32 schrieb David Miller: > > Can spidernet be told these kinds of parameters? "N packets or > > X usecs"? > > It can not do exactly this but probably we can get close to it by Why would you want o do this? It seems like a cruddier strategy than what we can already do (which is to never get an transmit interrupt, as long as the kernel can shove data into the device fast enough to keep the queue from going empty.) The whole *point* of a low-watermark interrupt is to never have to actually get the interrupt, if the rest of the system is on its toes and is supplying data fast enough. --linas - 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
Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
On Wed, Aug 16, 2006 at 02:32:03PM -0700, David Miller wrote: > > The best schemes seem to be to interrupt mitigate using a combination > of time and number of TX entries pending to be purged. This is what > most gigabit chips seem to offer. I seem to be having a multi-hour delay for email delivery, so maybe we've crossed emails. A "low watermark interrupt" is an interrupt that is generated when some queue is "almost empty". This last set of patches implement this for the TX queue. The interrupt pops when 3/4ths of the packets in the queue have been processed. Playing with ths setting (3/4ths or some other number) seemed to make little difference. > On Tigon3, for example, we tell the chip to interrupt if either 53 > frames or 150usecs have passed since the first TX packet has become > available for reclaim. The nature of a low-watermark interrupt is that it NEVER pops, as long as the kernel keeps putting more stuff into the queue, so as to keep the queue at least 1/4'th full. I don't know how to mitigate interrupts more than that. --linas - 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
Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
Linas Vepstas wrote: On Wed, Aug 16, 2006 at 11:24:46PM +0200, Arnd Bergmann wrote: it only seems to be hard to make it go fast using any of them. Last round of measurements seemed linear for packet sizes between 60 and 600 bytes, suggesting that the hardware can handle a maximum of 120K descriptors/second, independent of packet size. I don't know why this is. DMA overhead perhaps? If it takes so many micro/nanoseconds to get a DMA going That used to be a reason the Tigon2 had such low PPS rates and issues with multiple buffer packets and a 1500 byte MTU - it had rather high DMA setup latency, and then if you put it into a system with highish DMA read/write latency... well that didn't make it any better :) rick jones - 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
Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
Am Thursday 17 August 2006 00:55 schrieb Linas Vepstas: > > it only > > seems to be hard to make it go fast using any of them. > > Last round of measurements seemed linear for packet sizes between > 60 and 600 bytes, suggesting that the hardware can handle a > maximum of 120K descriptors/second, independent of packet size. > I don't know why this is. Could well be related to latencies when going to the remote node for descriptor DMAs. Have you tried if the hch's NUMA patch or using numactl makes a difference here? > > sounds like the right approach to simplify the code. > > Its not a big a driver. 'wc' says its 2.3 loc, which > is 1/3 or 1/5 the size of tg3.c or the e1000*c files. Right, I was thinking of removing a lock or another, not throwing out half of the driver ;-) Arnd <>< - 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
Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
On Wed, Aug 16, 2006 at 11:24:46PM +0200, Arnd Bergmann wrote: > > it only > seems to be hard to make it go fast using any of them. Last round of measurements seemed linear for packet sizes between 60 and 600 bytes, suggesting that the hardware can handle a maximum of 120K descriptors/second, independent of packet size. I don't know why this is. > That may > be the fault of strange locking rules My fault; a few months ago, we were in panic mode trying to get the thing functioning reliably, and I put locks around anything and everything. This last patch removes those locks, and protects only a few pointers (the incrementing of the head and the tail pointers, and the location ofthe low watermark) that actually needed protection. They need protection because the code can get called in various different ways. > Cleaning up the TX queue only from ->poll() like all the others I'll try this ... > sounds like the right approach to simplify the code. Its not a big a driver. 'wc' says its 2.3 loc, which is 1/3 or 1/5 the size of tg3.c or the e1000*c files. --linas - 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
Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
Am Thursday 17 August 2006 00:29 schrieb David Miller: > Didn't you say spidernet's facilities were sophisticated? :) > This Tigon3 stuff is like 5+ year old technology. I was rather overwhelmed by the 34 different interrupts that the chip can create, that does not mean they chose the right events for generating them. Interestingly, spidernet has five different counters you can set up to generate interrupts after a number of received frames, but none for transmit... Arnd <>< - 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
Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
From: Arnd Bergmann <[EMAIL PROTECTED]> Date: Thu, 17 Aug 2006 00:16:46 +0200 > Am Wednesday 16 August 2006 23:32 schrieb David Miller: > > Can spidernet be told these kinds of parameters? "N packets or > > X usecs"? > > It can not do exactly this but probably we can get close to it by Oh, you can only control TX packet counts using bits in the TX ring entries :( Tigon3 can even be told to use different interrupt mitigation parameters when the cpu is actively servicing an interrupt for the chip. Didn't you say spidernet's facilities were sophisticated? :) This Tigon3 stuff is like 5+ year old technology. - 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
Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
Am Wednesday 16 August 2006 23:32 schrieb David Miller: > Can spidernet be told these kinds of parameters? "N packets or > X usecs"? It can not do exactly this but probably we can get close to it by 1.) Setting a one-time interrupt to fire x*10µs after putting a packet into the TX queue. and 2.a) Enabling end of TX queue interrupts whenever more than y frames have been queued for TX. or 2.b) Marking frame number y in the TX to fire an interrupt when it has been transmitted, and move the mark whenever we clean up TX descriptors. or 2.c) Marking frame number y to generate an interrupt, but counting y from the end of the queue, and update the mark whenever we add frames to the queue tail. I'm not sure which version of 2. would give us the best approximation. Arnd <>< - 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
Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
On Wed, Aug 16, 2006 at 01:46:40PM -0700, David Miller wrote: > From: Jeff Garzik <[EMAIL PROTECTED]> > Date: Wed, 16 Aug 2006 16:34:31 -0400 > > > Linas Vepstas wrote: > > > I was under the impression that NAPI was for the receive side only. > > > > That depends on the driver implementation. > > What Jeff is trying to say is that TX reclaim can occur in > the NAPI poll routine, and in fact this is what the vast > majority of NAPI drivers do. I'll experiment with this. When doing, say, an ftp, there are enough TCP ack packets coming back to have NAPI netdev->poll be called frequently enough? > implied. In fact, I get the impression that spidernet is limited > in some way and that's where all the strange approaches are coming > from :) Hmm. Or maybe I'm just getting old. Once upon a time, low watermarks were considered the "best" way of doing anything; never occurred to me it would be considered "strange". Based on my probably obsolete idea of what constitutes "slick hardware", I was actually impressed by what the spidernet could do. Aside from cleaning up the transmit ring in the receive poll loop, what would be the not-so-strange way of doing things? --linas - 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
Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
From: Arnd Bergmann <[EMAIL PROTECTED]>
Date: Wed, 16 Aug 2006 23:24:46 +0200
> We first had an interrupt per descriptor, then got rid of all TX
> interrupts and replaced them by timers to reduce the interrupt load,
> but reducing throughput in the case where user space sleeps on a full
> socket buffer.
The best schemes seem to be to interrupt mitigate using a combination
of time and number of TX entries pending to be purged. This is what
most gigabit chips seem to offer.
On Tigon3, for example, we tell the chip to interrupt if either 53
frames or 150usecs have passed since the first TX packet has become
available for reclaim.
That bounds the latency as well as force the interrupt if a lot of TX
work becomes available.
Can spidernet be told these kinds of parameters? "N packets or
X usecs"?
This is all controllable via ethtool btw (via ETHTOOL_{S,G}COALESCE),
so you can experiment if you want.
-
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
Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
Am Wednesday 16 August 2006 22:46 schrieb David Miller: > I'm not familiar with the spidernet TX side interrupt capabilities > so I can't say whether that is something that can be directly > implied. In fact, I get the impression that spidernet is limited > in some way and that's where all the strange approaches are coming > from :) Actually, the capabilities of the chip are quite powerful, it only seems to be hard to make it go fast using any of them. That may be the fault of strange locking rules and other bugs we had in the driver before, so maybe you can recommend which one to use. Cleaning up the TX queue only from ->poll() like all the others sounds like the right approach to simplify the code. The spider hardware offers at least these options: - end of TX queue interrupt - set a per-descriptor bit to fire an interrupt at a specific frame - an interrupt for each frame (may be multiple descriptors) - an interrupt for each descriptor - timers implemented in the spidernet hardware We first had an interrupt per descriptor, then got rid of all TX interrupts and replaced them by timers to reduce the interrupt load, but reducing throughput in the case where user space sleeps on a full socket buffer. The last patches that were suggested introduce marking a single descriptor (not the last one, but somewhere near the end of the queue) so we fire an interrupt just before the TX queue gets empty. Arnd <>< - 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
Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
From: Jeff Garzik <[EMAIL PROTECTED]> Date: Wed, 16 Aug 2006 16:34:31 -0400 > Linas Vepstas wrote: > > I was under the impression that NAPI was for the receive side only. > > That depends on the driver implementation. What Jeff is trying to say is that TX reclaim can occur in the NAPI poll routine, and in fact this is what the vast majority of NAPI drivers do. It also makes the locking simpler. In practice, the best thing seems to be to put both RX and TX work into ->poll() and have a very mild hw interrupt mitigation setting programmed into the chip. I'm not familiar with the spidernet TX side interrupt capabilities so I can't say whether that is something that can be directly implied. In fact, I get the impression that spidernet is limited in some way and that's where all the strange approaches are coming from :) - 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
Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
Linas Vepstas wrote: I was under the impression that NAPI was for the receive side only. That depends on the driver implementation. Jeff - 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
Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
On Wed, Aug 16, 2006 at 12:30:29PM -0400, Jeff Garzik wrote: > Linas Vepstas wrote: > > > >The recent set of low-waterark patches for the spider result in a > > Let's not reinvented NAPI, shall we... ?? I was under the impression that NAPI was for the receive side only. This round of patches were for the transmit queue. Let me describe the technical problem; perhaps there's some other solution for it? The default socket size seems to be 128KB; (cat /proc/sys/net/core/wmem_default) if a user application writes more than 128 KB to a socket, the app is blocked by the kernel till there's room in the socket for more. At gigabit speeds, a network card can drain 128KB in about a millisecond, or about four times a jiffy (assuming HZ=250). If the network card isn't generaing interrupts, (and there are no other interrupts flying around) then the tcp stack only wakes up once a jiffy, and so the user app is scheduled only once a jiffy. Thus, the max bandwidth that the app can see is (HZ * wmem_default) bytes per second, or about 250 Mbits/sec for my system. Disappointing for a gigabit adapter. There's three ways out of this: (1) tell the sysadmin to "echo 1234567 > /proc/sys/net/core/wmem_default" which violates all the rules. (2) Poll more frequently than once-a-jiffy. Arnd Bergmann and I got this working, using hrtimers. It worked pretty well, but seemed like a hack to me. (3) Generate transmit queue low-watermark interrupts, which is an admitedly olde-fashioned but common engineering practice. This round of patches implement this. --linas - 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
Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
Linas Vepstas wrote: Please apply and forward upstream. This patch requires the previous sequence of 4 spidernet patches to be applied. --linas The recent set of low-waterark patches for the spider result in a significant amount of computing being done in an interrupt context. This patch moves this to a "bottom half" aka work queue, so that the code runs in a normal kernel context. Curiously, this seems to result in a performance boost of about 5% for large packets. Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> Cc: Utz Bacher <[EMAIL PROTECTED]> Cc: Jens Osterkamp <[EMAIL PROTECTED]> Let's not reinvented NAPI, shall we... Jeff - 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
[PATCH 1/2]: powerpc/cell spidernet bottom half
Please apply and forward upstream. This patch requires the previous
sequence of 4 spidernet patches to be applied.
--linas
The recent set of low-waterark patches for the spider result in a
significant amount of computing being done in an interrupt context.
This patch moves this to a "bottom half" aka work queue, so that
the code runs in a normal kernel context. Curiously, this seems to
result in a performance boost of about 5% for large packets.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: Utz Bacher <[EMAIL PROTECTED]>
Cc: Jens Osterkamp <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 21 +++--
drivers/net/spider_net.h |4 +++-
2 files changed, 18 insertions(+), 7 deletions(-)
Index: linux-2.6.18-rc3-mm2/drivers/net/spider_net.c
===
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net.c 2006-08-15
14:25:50.0 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net.c 2006-08-15
14:28:56.0 -0500
@@ -883,9 +883,10 @@ out:
* spider_net_cleanup_tx_ring - cleans up the TX ring
* @card: card structure
*
- * spider_net_cleanup_tx_ring is called by the tx_timer (as we don't use
- * interrupts to cleanup our TX ring) and returns sent packets to the stack
- * by freeing them
+ * spider_net_cleanup_tx_ring is called by either the tx_timer
+ * or from a work-queue scheduled by the tx-empty interrupt.
+ * This routine releases resources associted with transmitted
+ * packets, including updating the queue tail pointer.
*/
static void
spider_net_cleanup_tx_ring(struct spider_net_card *card)
@@ -895,12 +896,20 @@ spider_net_cleanup_tx_ring(struct spider
spin_lock_irqsave(&card->tx_chain.lock, flags);
if ((spider_net_release_tx_chain(card, 0) != 0) &&
- (card->netdev->flags & IFF_UP))
+ (card->netdev->flags & IFF_UP)) {
spider_net_kick_tx_dma(card);
+ netif_wake_queue(card->netdev);
+ }
spin_unlock_irqrestore(&card->tx_chain.lock, flags);
}
+static void
+spider_net_tx_cleanup_task(void * data)
+{
+ spider_net_cleanup_tx_ring((struct spider_net_card *) data);
+}
+
/**
* spider_net_do_ioctl - called for device ioctls
* @netdev: interface device structure
@@ -1499,8 +1508,7 @@ spider_net_interrupt(int irq, void *ptr,
netif_rx_schedule(netdev);
}
if (status_reg & SPIDER_NET_TXINT ) {
- spider_net_cleanup_tx_ring(card);
- netif_wake_queue(netdev);
+ schedule_work(&card->tx_cleanup_task);
}
if (status_reg & SPIDER_NET_ERRINT )
@@ -2117,6 +2125,7 @@ spider_net_alloc_card(void)
card->netdev = netdev;
card->msg_enable = SPIDER_NET_DEFAULT_MSG;
INIT_WORK(&card->tx_timeout_task, spider_net_tx_timeout_task, netdev);
+ INIT_WORK(&card->tx_cleanup_task, spider_net_tx_cleanup_task, card);
init_waitqueue_head(&card->waitq);
atomic_set(&card->tx_timeout_task_counter, 0);
Index: linux-2.6.18-rc3-mm2/drivers/net/spider_net.h
===
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net.h 2006-08-15
14:25:50.0 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net.h 2006-08-15
14:28:56.0 -0500
@@ -24,7 +24,7 @@
#ifndef _SPIDER_NET_H
#define _SPIDER_NET_H
-#define VERSION "1.1 A"
+#define VERSION "1.1 B"
#include "sungem_phy.h"
@@ -441,6 +441,8 @@ struct spider_net_card {
atomic_t tx_timeout_task_counter;
wait_queue_head_t waitq;
+ struct work_struct tx_cleanup_task;
+
/* for ethtool */
int msg_enable;
-
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
