Re: CONFIG_PACKET_MMAP revisited
From: Oliver Dain
Date: Thu Nov 06 2003 - 09:14:49 EST
On Thursday November 6 2003 6:08 am, Gianni Tedesco wrote:
> On Wed, 2003-10-29 at 05:09, odain2@xxxxxxxxxxxxxx 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
> 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).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/