[Ksummit-discuss] [CORE TOPIC] Redesign Memory Management layer and more core subsystem

Greg KH greg at kroah.com
Fri Jun 13 17:30:41 UTC 2014

On Fri, Jun 13, 2014 at 11:56:08AM -0500, Christoph Lameter wrote:
> On Wed, 11 Jun 2014, Greg KH wrote:
> > > Often the kernel subsystems are impeding performance. In high speed
> > > computing we regularly bypass the kernel network subsystems, block I/O
> > > etc. Direct hardware access means though that one is explosed to the ugly
> > > particularities of how a certain device has to be handled. Can we have the
> > > cake and eat it too by defining APIs that allow low level hardware access
> > > but also provide hardware abstraction (maybe limited to certain types of
> > > devices).
> >
> > What type of devices are you wanting here, block and networking or
> > something else?  We have the uio interface if you want to (and know how
> > to) talk to your hardware directly from userspace, what else do you want
> > to do here that this doesn't provide?
> Block and networking mainly. The userspace VFIO API exposes device
> specific registers. We need something that is a decent abstraction.
> IBverbs is something like that but it could be done much better.

Heh, we've been down this road before :)

In the end, userspace wants a socket-like interface to the networking
"stack", right?  So either you provide that with a custom networking
library that talks directly to a specific hardware card (like 3
different companies provide), or you just deal with the in-kernel
network stack.  What else is there that we can do here?

And as for block device, "raw access", really?  What is lacking with
what we already provide in "raw mode", and a no-op block scheduler?  How
much more "lean" can we possibly go without you having to write a custom
userspace uio driver for every block controller out there?


greg k-h

More information about the Ksummit-discuss mailing list