On Thu, 13 May 2004, Pantelis Antoniou wrote:Thanks for the answers.
Is there a mechanism that I get retreive packets already pending in the transmit queue so that I can fill the free hardware buffer from within the transmit interrupt handler?
Do you really have such small hardware buffers that the softirq scheduling latency is significant?
Most devices hava a transmit ring buffer or similar which absorbs this latency by buffering more than one packet. As long as the buffer is refilled before it is completely drained you are fine from a performance point of view, and doing it more often only adds overhead.
In general it is adviceable to have the hardware IRQ handlers do as little as possible as these block all other activity including many other hardware IRQs and leave the bulk of the work to softirq handlers.
If you really need to have the hardware IRQ refill your buffers you can
always extend the packet queue within your driver by adding a in-memory
ring buffer or similar which can safely be polled by the interrupt
handler, but I am afraid this will only increase the overhead of your
driver for little or no performance gain only making your driver more
complex. But you know the properties of your hardware device better than me..
The thing is that I'm not interested in just absorbing the latency without holes in the transmit path.
I'm targetting a bridging application (soft switch) and I'm trying to minimize
the latency of packets entering one port and leaving another.
I know it is not a very general case, so I'm asking if there's an API that applies in my case.
Otherwise I'm forced to duplicate or modify the netif scheduling core so that
I can call it from within an interrupt context.
RegardsRegards Henrik
Pantelis
- : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
