Am 30.01.2014 um 12:55 schrieb Lars Segerlund <lars.segerl...@gmail.com>:
> 2014-01-30 Michael Haberler <mai...@mah.priv.at>: >> >> 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. >> > > This is a general observation from running preempt-rt, I did not > contest your statements, I simply added that if you have bad device > drivers you are out of luck with preempt-rt. > It's one of the things you have to make sure of when using it, but > it's getting better, thanks to multiprocessing large parts of the > kernen are undergoing efforts to use lockless datatypes or mechanisms. > > If you have a set of different computers and run some tests on > preempt-rt you will soon find that some perform much worse due to poor > drivers, and networking is one are where there are some 'known bad' > cards and drivers. > > Or in engineering english, some systems suck and some don't ... makes sense It might be just the assumption 'we get away with using the Linux driver universe and kernel support now with RT, too' needs a second look - I had the impression this stood behind Michal's work, and I dont like to see energy wasted on what might not be viable. I would have liked to see that fly, but obviously one cant have all of it at once: shared kernel services, stock drivers, predictable behavior -m > > / regarrds, Lars > >> 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 > > ------------------------------------------------------------------------------ > 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
