On Wed, 2003-10-29 at 05:09, [email protected] wrote:
> I believe that in normal operation each packet
> (or with NICs that do interrupt coalescing, every n packets) causes an
> interrupt which causes a context switch, the kernel then copies the data
> from the DMA buffer to the shared buffer and does a RETI. That's fairly
> expensive.
The cost of handling that interrupt and doing an iret is unavoidable
(ignoring NAPI). The main point you are missing with the ring buffer is
that if packets come in at a fast enough rate, the usermode task never
context switches, because there is always data in the ring buffer, so it
loops in usermode forever.
The problem could be the packets are coming in just too slow to allow
the ring buffer to work properly and causing the application to sleep on
poll(2) every time. This would kill performance at pathelogical packet
rates I guess.
You could work around this by spinning for a few thousand spins before
calling poll(2) (or even indefinately for that matter, and allow the
kernel to preempt you if need be).
--
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source http://www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
On Thursday November 6 2003 6:08 am, Gianni Tedesco wrote:
> On Wed, 2003-10-29 at 05:09, [email protected] wrote:
> > I believe that in normal operation each packet
> > (or with NICs that do interrupt coalescing, every n packets) causes an
> > interrupt which causes a context switch, the kernel then copies the data
> > from the DMA buffer to the shared buffer and does a RETI. That's fairly
> > expensive.
>
> The cost of handling that interrupt and doing an iret is unavoidable
> (ignoring NAPI). The main point you are missing with the ring buffer is
> that if packets come in at a fast enough rate, the usermode task never
> context switches, because there is always data in the ring buffer, so it
> loops in usermode forever.
It seems to me that it can't loop in user mode forever. There is no way to
get data into user mode (the ring buffer) witout going through the kernel.
My understanding is that the NIC doesn't transfer directly to the user mode
ring buffer, but rather to a different DMA buffer. The kernel must copy it
from the DMA buffer to the ring buffer. Thus once the user mode app has
processed all the data in the ring buffer the kenel _must_ get involved to
get more data to user space. Currently the data gets there because the NIC
produces an interrupt for each packet (or for every few packets) and when the
kernel handles these the data is copied to user space. Then, as you point
out, the cost of the RETI can't be avoided.
NAPI tries to solve this problem. I don't know much about NAPI, but as I
understand it, the idea is this: The cost of the RETI's and context switches
(which occur on each interrupt) can be reduced if the NIC doesn't produce an
interrupt for every packet but instead does interrupt coalescing, but this
only goes so far. If too many packets are coalesced the data copied by the
kernel will no longer fit in the L1 cache and we'll pay the price of moving
it there twice (once when the kernel copies the data from main memory to the
ring buffer and once when the user mode application reads it out of the
ring), the latency may become a problem, we've still got a context switch
every time the user mode application has processed everything in the ring
buffer (and perhaps more often), and we're still paying the price of copying
data from the DMA buffer to the ring.
However, if the NIC could transfer the data directly to user space it wouldn't
need to cause an interrupt and the cost of the RETI and the context switch is
avoided. The user mode app really could process forever without sleeping at
that point.
> The problem could be the packets are coming in just too slow to allow
> the ring buffer to work properly and causing the application to sleep on
> poll(2) every time. This would kill performance at pathelogical packet
> rates I guess.
>
> You could work around this by spinning for a few thousand spins before
> calling poll(2) (or even indefinately for that matter, and allow the
> kernel to preempt you if need be).
On Thu, 2003-11-06 at 15:13, Oliver Dain wrote:
> It seems to me that it can't loop in user mode forever. There is no way to
> get data into user mode (the ring buffer) witout going through the kernel.
> My understanding is that the NIC doesn't transfer directly to the user mode
> ring buffer, but rather to a different DMA buffer. The kernel must copy it
> from the DMA buffer to the ring buffer. Thus once the user mode app has
> processed all the data in the ring buffer the kenel _must_ get involved to
> get more data to user space. Currently the data gets there because the NIC
> produces an interrupt for each packet (or for every few packets) and when the
> kernel handles these the data is copied to user space. Then, as you point
> out, the cost of the RETI can't be avoided.
yes, in interrupt context. My point is that that *task* will never go in
to kernel mode, it will always be running in user mode.
> However, if the NIC could transfer the data directly to user space it wouldn't
> need to cause an interrupt and the cost of the RETI and the context switch is
> avoided. The user mode app really could process forever without sleeping at
> that point.
it would need to cause an interrupt to notify of the packet, unless the
program communicated directly with the NIC in polling mode. This the
point of mmap packet socket, provides a *portable* ring buffer structure
so that userspace doesn't have to reimplement drtivers.
--
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source http://www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
Gianni Tedesco wrote:
> On Thu, 2003-11-06 at 15:13, Oliver Dain wrote:
>
>>It seems to me that it can't loop in user mode forever. There is no way to
>>get data into user mode (the ring buffer) witout going through the kernel.
>>My understanding is that the NIC doesn't transfer directly to the user mode
>>ring buffer, but rather to a different DMA buffer. The kernel must copy it
>>from the DMA buffer to the ring buffer. Thus once the user mode app has
>>processed all the data in the ring buffer the kenel _must_ get involved to
>>get more data to user space. Currently the data gets there because the NIC
>>produces an interrupt for each packet (or for every few packets) and when the
>>kernel handles these the data is copied to user space. Then, as you point
>>out, the cost of the RETI can't be avoided.
>
>
> yes, in interrupt context. My point is that that *task* will never go in
> to kernel mode, it will always be running in user mode.
In my experience (PIII 1.2GHz, i815, e100, NAPI), user mode
would read at most 7 packets at a time, even when artificial
busy loops insterted. The max packet rate acheived was
around 120Kpps, but that was limited at the driver level.
Most of the CPU was consumed while doing this (measured with
cyclesoak, especially required since NAPI was used).
P?draig.