On Mon, Jun 27, 2016 at 3:51 AM, TJF <jeli.freih...@gmail.com> wrote: > I think Suman did already know what libpruio (and many other high > performance PRU projects) need. But here's a private lesson for you: There > is no "need for communications with Linux in a tight control loop". We need > direct memory access between PRU and ARM CPU. No Linux inbetween. We need to > bypass all that vring and RPMsg magic. We gain for speed and small memory > footprints. We want to save resources for future extensions and we don't > want to spend resources for features that we neither need nor want.
This is a valid design pattern and you did very impressive things with it, but it's not compatible with the basic design of Linux hardware integration: I don't know of a single mainline kernel driver designed this way. The whole point of a kernel driver is that it abstracts the hardware and presents the unified abstraction to the rest (open/read/write/ioctl/skbuf/etc). Of course this costs performance, and so the development identifies those bottlenecks and tries to come up with more abstractions like no-copy networking, etc. The challenge for those abstractions is to provide speed while still maintaining security, e.g. by disallowing full control of the entire physical address space. There have to be address space checks on those kernel-userspace transitions, and they will use up some cycles; you can optimize them but can't just not do them. It seems to me that you just don't want the Linux machinery to intervene: your design does feel like a bare metal, tight control loop, using Linux mostly for setup, program loading and administration. Also, I would be personally obliged to you if you could refrain from commenting on other people's motivations and abilities, and just keep focused on the technical points everyone is making. The discussion is much more productive this way. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGAQBn%2BAgt76ivjMW3h3Yon7hXbEROcU%2BwubWS4YG6%3DJg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
