Kernel driver vs libusb performance

Kernel driver vs libusb performance

[Ozan Çağlayan]

Hi,

I have a device which I'm currently accessing using libusb. It's
basically a HID compliant USB device. It reports 32bytes of data with
a time resolution of 128Hz, e.g. I have to read and store 32bytes each
1/128 second. One performance drawback is that those 32bytes chunks
are encrypted with AES so once I receive them through the USB endpoint
I first decrypt them.

So 128Hz is quite a low polling frequency and can be handled in a
single-thread using a modern CPU, but I'm planning to run this loop on
a Raspberry Pi or namely low-end, cheap embedded processors. I'm also
using Python which is significantly slow on Raspberry Pi.

So I wonder whether writing a kernel driver which decrypts the packets
using in-kernel crypto API and then exposing them through a character
device node would bring a performance gain at all. At least on the
userspace side I may get rid of all the bus searching, crypto key
generation, fetching and decrypting boilerplate, am I in the wrong
way?

Thanks,

-- 
Ozan Çağlayan
Research Assistant
Galatasaray University - Computer Engineering Dept.
http://www.ozancaglayan.com

Re: Kernel driver vs libusb performance

[Greg KH]

On Fri, Jan 11, 2013 at 11:53:36AM +0200, Ozan Çağlayan wrote:
> Hi,
> 
> I have a device which I'm currently accessing using libusb. It's
> basically a HID compliant USB device. It reports 32bytes of data with
> a time resolution of 128Hz, e.g. I have to read and store 32bytes each
> 1/128 second. One performance drawback is that those 32bytes chunks
> are encrypted with AES so once I receive them through the USB endpoint
> I first decrypt them.
> 
> So 128Hz is quite a low polling frequency and can be handled in a
> single-thread using a modern CPU, but I'm planning to run this loop on
> a Raspberry Pi or namely low-end, cheap embedded processors. I'm also
> using Python which is significantly slow on Raspberry Pi.

Ah, my sympathies, USB on a rpi is horrible, and you will have all sorts
of nasty issues, no matter how you end up doing this (in the kernel or
userspace).

> So I wonder whether writing a kernel driver which decrypts the packets
> using in-kernel crypto API and then exposing them through a character
> device node would bring a performance gain at all. At least on the
> userspace side I may get rid of all the bus searching, crypto key
> generation, fetching and decrypting boilerplate, am I in the wrong
> way?

Test it out and see.  I really don't think that user vs. kernel space is
going to be the issue here, I think you are going to see some very real
problems with the hardware itself in this area.

Best of luck,

greg k-h

Re: Kernel driver vs libusb performance

[Ozan Çağlayan]

> Ah, my sympathies, USB on a rpi is horrible, and you will have all sorts
> of nasty issues, no matter how you end up doing this (in the kernel or
> userspace).

What kind of issues? Currently I can read from the device without
problem. But, I had very weird problems with 2 uvc cameras, you're
right.

> Test it out and see.  I really don't think that user vs. kernel space is
> going to be the issue here, I think you are going to see some very real
> problems with the hardware itself in this area.
>
> Best of luck,

Well If I were you I would probably write that simple driver in a few
hours but seen that I am not you, I wanted to learn will the effort
worth the result :)

Anyway, thanks!

-- 
Ozan Çağlayan
Research Assistant
Galatasaray University - Computer Engineering Dept.
http://www.ozancaglayan.com

Re: Kernel driver vs libusb performance

[Greg KH]

On Fri, Jan 11, 2013 at 04:10:30PM +0200, Ozan Çağlayan wrote:
> > Ah, my sympathies, USB on a rpi is horrible, and you will have all sorts
> > of nasty issues, no matter how you end up doing this (in the kernel or
> > userspace).
> 
> What kind of issues? Currently I can read from the device without
> problem. But, I had very weird problems with 2 uvc cameras, you're
> right.

High cpu usage is one problem, and low overall USB bandwidth is another,
combined with slow response times.  The hardware really is bad for USB,
and the driver is a whole other beast, something that no one in the
community can, or will, touch at all.

> > Test it out and see.  I really don't think that user vs. kernel space is
> > going to be the issue here, I think you are going to see some very real
> > problems with the hardware itself in this area.
> >
> > Best of luck,
> 
> Well If I were you I would probably write that simple driver in a few
> hours but seen that I am not you, I wanted to learn will the effort
> worth the result :)

It all depends on what you want to do, but I really think that user vs.
kernelspace is not going to be the real problem here.  Start with libusb
and if you find that you are having problems, use 'perf' to see if the
kernel part is really the problem.  I think you will find all of your
time is going to be spent in the USB hardware itself, and the USB
driver, once you get the data out of that, user vs. kernel is not going
to be noticable at all.

Best of luck, and I bet you, in the end, you pick a better hardware
platform for your project (hint, go buy a Beaglebone, it actually works
and the tiny increase in cost more than makes up for the time you will
waste fighting the RPI hardware.)

greg k-h

Re: Kernel driver vs libusb performance

[Ozan Çağlayan]

> It all depends on what you want to do, but I really think that user vs.
> kernelspace is not going to be the real problem here.  Start with libusb
> and if you find that you are having problems, use 'perf' to see if the
> kernel part is really the problem.  I think you will find all of your
> time is going to be spent in the USB hardware itself, and the USB
> driver, once you get the data out of that, user vs. kernel is not going
> to be noticable at all.
>
> Best of luck, and I bet you, in the end, you pick a better hardware
> platform for your project (hint, go buy a Beaglebone, it actually works
> and the tiny increase in cost more than makes up for the time you will
> waste fighting the RPI hardware.)

My mainloop is sth like this actually:

(I never thought of multi-processing & multi-threading but I may give
a chance on cooperative multitasking using Python greenlets)

1. [Simultaneously]
  {Fetch 32bytes in 128Hz + Decrypt + Queue them} AND
  {Flicker 2 LEDs with 10Hz/7.5Hz respectively using GPIO}
    (This is the step I'm afraid off, I expect jitters of course but
up to a limit. I also think about trying RT-patched kernel if that
will help at all...)

2. Take FFT of the signal queued using SciPy (I timed this: It takes
230~ uS for FFT of 128 integers on Rpi)

3. Do some simple math on FFT'ed signal &&
    Send a command to another device over a USB-FTDI channel if some
threshold is attained.

You are right that Beaglebone brings a huge improvement with
acceptable increase in the price but what I'm trying to do is to show
people that
"Hey what you are doing on your decent 1000$ i7 desktop with Matlab
over Windows works on my 30$ Linux box using Python" and that is
exactly why I'm pushing the limits of the device.

Thank you very much :)

-- 
Ozan Çağlayan
Research Assistant
Galatasaray University - Computer Engineering Dept.
http://www.ozancaglayan.com