But are they Linux friendly?
Since Linux has SMP functionality, they are in theory Linux friendly. And they are to large extent as long as Kernel controls the hardware accelerators and Ethernet ports.
There are many reasons why Network device vendors don't like to deal with the hardware from Kernel space. Let us take the two accelerators in question - Regex accelerator and Crypto accelerator. Any device vendor providing security functionality mostly implement using Linux user space daemons for several reasons such as
- User space programming is easier to debug.
- Some security functions require proxies which work on top of socket interface - hence user space applications.
- More memory can be accessed from user space.
- Taking advantage of SWAP.
- IDS/IPS - One user space process, multiple threads.
- Network AV - HTTP/S Proxy - One user space process, multiple threads.
- Network AV - SMTP/S proxy - One user space process, multiple threads.
- Network AV - POP3/S Proxy - One user space process, multiple threads.
- Network AV - IMAP/S proxy - One user space process, multiple threads.
- ClamAV or any equivalent Anti Virus package - Multiple user processes created dynamically at run time.
- Spam Assasin or equivalent Anti Spam package - Multiple user processes.
- IPsec : Kernel level function.
- Network AV - HTTPS proxy, SMTP/S Proxy, POP3S Proxy and IMAP/S proxy.
- IPsec in kernel space.
- ClamAV daemons.
- Spam Assasin daemon
- IDS/IPS daemon
- Content Security daemon (HTTP Proxy).
Unfortunately, the Multicore processors today don't have that capability. I hope new Multicore processors would have this capability.
Let us see the expectations by the software on hardware accelerator devices.
- Accelerator device should be instantiable.
- Each instance can be memory mappable by the appropriate user space daemon.
- Only owned process/thread should be able to submit and get hold of responses.
- Each instance of hardware device should have its own interrupt and this interrupt line should wake up the appropriate thread.
- When a user process dies, it should not affect other processes using the same device with different instance.
- When the user process dies, software should be able to stop the instance of device.
Comments?
3 comments:
Cavium Octeon also has crypto at instruction level. So, Octeon does not have this issue.
What about NetLogic XLP and Freescale P4080? Since they don't have crypto instructions, do they have issues which you have detailed in your post?
Crypto at instruction level works very good in virtualization environment. No hassles and headaches in providing drivers in kernel space.
I wonder why other Multicore processor vendors don't implement crypto at Core level. What advantages these other Multicore vendors have?
It is balance between performance & flexibility.
Asynchronous Crypto accelerators in general give better performance for IPsec, PDCP, MACSec, SRTP. These packet processing modules are in general simple to modify to take advantage of asynchronous acceleration. While crypto engine executes the crypto algorithm, processors can do some thing else. Some Multicore processors such as P4080 from Freescale does more than crypto. It also does protocol offload.
Crypto level instruction sacrifice the performance with flexibility.
My view is that eventually Multicore processors would support both modes - Synchronous & Asynchronous. Synchronous for SSL based applications and Asynchronous for packet processing based applications.
Recently Freescale announced that future SoCs would have Altivec SIMD in its cores. See here: http://media.freescale.com/phoenix.zhtml?c=196520&p=irol-newsArticle&ID=1474744.
I think that would provide best of both worlds.
Post a Comment