Am 30.01.2014 um 11:42 schrieb Lars Segerlund <lars.segerl...@gmail.com>:
> It depends on the driver implementation, ie. if the kernel code is > using preempt disable or disable interrupts. The kernel execution path is _much_ longer than just the driver, and depending on the system call all sorts of issues happen well before a driver is invoked. Priority inversion, memory allocation which might block, the whole nine yards. The gist of what Nicolas said was: it's the kernel execution path of a particular syscall - meaning: no matter how bright your driver is you might well be hosed before you get there. > ALL preempt-rt performance is to a large extent dependent on the > quality of the device drivers. Can you back up that assertion with facts? the case at hand was the 7i80 UDP I/O effort. That means the whole kernel IP stack gets traversed. There obviously is a reason why Xenomai employs the RTnet stack for such jobs. For instance, it might make sense to ask Jan Kiska, the author. > If you look at osadl.org there is an effort on realtime device drivers ... What I am suggesting against: trying such approaches in isolation and hope for results based on some homegrown theory. What I am suggesting: talk to the relevant community, test your theory, listen to alternative suggestions. That has paid off hugely in the Xenomai case already. In the RT-PRREMPT case the gist I took away so far was: the UIO framework might be a solution to bypass kernel execution paths in RT - resullting in: lower latency, card dependency, no sharing with kernel stack, userland UDP handling, likely extra kernel modules, and out-of-tree support modules like uio_dma . - Michael > > / Lars > > > 2014-01-30 Michael Haberler <mai...@mah.priv.at>: >> Michal is trying hard to get the 7i80/hm2_eth.c driver working for >> RT-PREEMPT using normal socket I/O from an RT thread. >> >> The hopes with RT-PREEMPT are obviously pegged on the assumption: 'the >> kernel is hardened, so I'm free to use any system calls from an RT thread >> and still get decent latency, so we can leverage of the stock linux driver >> universe'. >> >> This might not be a valid assumption. >> >> I just had a long offline discussion with Nicholas Mc Guire from the >> rt-preempt effort on a related issue (signaling a non-RT thread from an RT >> thread; the method I proposed uses a write(2) system call on an eventfd(2) >> file descriptor; one of the most efficient ways to signal a poll(2) >> compatible event between threads). >> >> Nicholas pointed me to the fact that almost all system system calls might be >> spoilers for RT threads; _including write(2)_ , hardened kernel or not. >> While I didnt fully understand every detail he said, the message was clear: >> the above assumption might not hold. >> >> He also pointed at that hoping for low latency when using the kernel IP >> stack may be a lost cause to start with. He hinted towards a UIO-based >> userland stack being worked on for exactly this purpose. I am still >> searching for details on this. >> >> My recommendation is: >> >> peer-review your assumptions to avoid a time waster here. >> Get in touch with linux-rt-us...@vger.kernel.org, describe what you intend, >> get advice straight from the people who make it happen. >> >> >> - Michael >> >> >> -- >> >> ps: IMV the search for a low-latency network I/O method is still on. Note >> that we already have a userland PCI framework thanks to Charles, which might >> be >> a startng point. >> >> See also: >> http://static.mah.priv.at/public/rtlws-proceedings/rtlws-2012/proc/Yang.pdf >> http://os.inf.tu-dresden.de/ddekit/dde_rtlws11.pdf. >> >> semi-related: anyone looking into RT-PREEMPT on ARM CPU's should read: >> http://lwn.net/images/conf/rtlws11/papers/proc/p11.pdf >> ------------------------------------------------------------------------------ >> WatchGuard Dimension instantly turns raw network data into actionable >> security intelligence. It gives you real-time visual feedback on key >> security issues and trends. Skip the complicated setup - simply import >> a virtual appliance and go from zero to informed in seconds. >> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk >> _______________________________________________ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers > > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
