Messages in this thread | | | Date | Wed, 16 Aug 2006 15:30:43 -0500 | Subject | Re: [PATCH 1/2]: powerpc/cell spidernet bottom half | From | (Linas Vepstas) |
| |
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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |