On Thu, 13 May 2004, Pantelis Antoniou wrote: > The thing is that I'm not interested in just absorbing the latency > without holes in the transmit path. Please elaborate on what the difference is. > I'm targetting a bridging application (soft switch) and I'm trying to > minimize the latency of packets entering one port and leaving another. How does keeping your hardware buffers more full than never empty benefits your hardware? Or how does your hardware device benefit from having the hardware transmit buffers always completely filled compared to reasonably filled before drained? Is it the case that your hardware device processes the transmit buffers non-sequentially, effectively having more than one transmit queue you need to keep filled and each of these is too small to effectively keep your hardware working with the latency of the softirq? > I know it is not a very general case, so I'm asking if there's an API > that applies in my case. The API is there on how your driver gets packets from the kernel, how you buffer, reorder etc within your driver is up to you. If your hardware buffers is not full and the queue is running then there is no latency involved as the transmit function is called immediately. If your hardware buffers is or was very recently full then there is a latency for the transmit queue to restart. Reducing this by introducing yet another small buffer layer between netif transmit handler and your hardware interrupt handler is not hard, but it may be hard to find a good balance between overhead and buffer refill latency. > Otherwise I'm forced to duplicate or modify the netif scheduling core so > that I can call it from within an interrupt context. I don't see why this would be needed. Why can't you just add an additional layer of buffering in your driver if the hardware buffers it not sufficient for what your hardware is doing? You can not transmit a packet before it is available to the netif core, and you can easily make a driver which accepts and queues packets for it's interrupt handler when no hardware buffers are immediately available. But as you then have two paths for filling your hardware buffers you better be careful to mediate access properly, and also remember to not spend too much time in the hardware IRQ as this will have adverse effects on all other components in your system, possibly including but not limited to your own ability to receive packets.. Regards Henrik - : 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
