On Sat, Nov 22, 2014 at 12:23:49AM +0100, Jeroen Van den Keybus wrote: > > > > > > - the NAPI will be implemented. The NAPI thread will run with the > > priority of the highest priority waiting thread, and will call > > rt_stack_deliver, in order not to increase the RX latency compared > > to the current solution. > > > Would you just poll this thread continuously, at high rate ? I'm asking > because I'd expect the poll method to be called only at moderate rates and > registers may be read or written.
You can not really guarantee low RX latency if the NAPI thread does not poll hardware as soon as a packet is received. One thing to understand though is that the NAPI thread will generally be sleeping, and be just woken up on the reception of the first RX irq, at which point RX irq will be disabled at the NIC level, all the received packets will be processed, then the RX irq will be re-enabled at NIC level, and the NAPI thread will go back to sleep. > > Maybe the RTnet drivers contain some modifications for low latency > > like reducing the TX ring length, but I believe putting these > > modifications in the drivers is not a so good idea: > > - it means that the modification is to be made in each driver, and > > needs to be maintained; > > - in the particular case of the TX ring, reducing the number of > > queued packets in hardware is not a really precise way to guarantee > > a bounded latency, because the latency is proportional to the number > > of bytes queued, not on the number of packets, and ethernet packets > > have widely varying sizes. > > > > I fully agree. > > > > Please feel free to send any reaction to this mail. > > > > I've always been wondering if it would be possible to emulate the entire > Linux netdev system in realtime instead, essentially avoiding any driver > modification at all. The plan is to approach this goal. We have to rename the functions to avoid the symbol names clashes, but I would like the conversion to be really automatic. One thing I will not do, however, is spend time trying and emulating the last 20% of the netdev API that would cost me 80% of the development effort. > However, this would also include the handling of the > various task registrations (INIT_WORK) a driver typically does (the e1000e > registers five). But these may still be handled by Linux, perhaps. Actually, I have added the rtdm_schedule_nrt_work() service allowing to trigger workqueues in Linux domain, from Xenomai domain: http://git.xenomai.org/xenomai-gch.git/commit/?h=for-forge&id=ee703d9785f7e242057ef689bc500b965cd75294 > > Though it could very well be a large undertaking, I'm not sure if modifying > the individual drivers (and often the various codepaths for different card > variants inside them) would entail less effort in the end. Well, part, if not majority of the maintenance work is to get the drivers to follow mainline changes. We need this because it allows supporting new hardware, and in case the mainline changes contain fixes. To make that job easy, we need to modify them as little as possible to integrate into RTnet, because every change we make will have to be carried from one version to the next, and have chance to get broken by the mainline changes. -- Gilles. ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
