Re: Hifn driver in SMP (was Re: GELI - disk encryption GEOM class committed.)

Sam Leffler wrote:
> Andre Oppermann wrote:
> 
>> Poul-Henning Kamp wrote:
>>
>>> I belive there is a bug in the HiFn chips that makes them do a soft 
>>> reset
>>> under some set of circumstances which we have never been able to nail
>>> down.
>>>
>>> I have contacted HiFn about this and asked for a workaround, but
>>> they seem somewhat less than eager to work the case.
>>>
>>> I belive the message before last was that they hard reproduced it.
>>>
>>> The last message was from somebody going through the piles on a
>>> former employees table.
>>
>> What's the deal with HiFn?  IMHO Cavium are way better and much more
>> performant.
>>
> Not sure how you come to this conclusion about Cavium.  Last time I 
> looked at their h/w it was heavily firmware-based and the whole 
> environment was problematic to integrate with crypto(9).  OTOH it wasn't 
> clear that integrating their stuff through the crypto subsystem would 
> most effectively use their h/w; much better to integrate directly to 
> ipsec and/or ssl using higher-level commands--just like hifn, broadcom, 
> safenet, and everybody else.  I also have my opinions about the quality 
> of their code but that's another matter.

I don't know the crypto(9) API very well but from reading the man page
and the Cavium crypto processor documentation there seems to be a rather
nice fit.  What Cavium gets right is their kick-ass DMA engine on the
processors.  Very good to write drivers for and very efficient and
performant on the PCI bus.  There is microcode to be loaded onto the
cards but it is a rather small code segment and all the critical functions
are built in hardware (from the docs).  I agree that the FreeBSD driver
wasn't written by someone with great BSD driver experience.  On the other
hand they managed to put all the kernel level driver stuff under the BSD
license.  For some reason the crypto operation setup code in the OpenSSL
patch is proprietary code.  OTOH pretty much the same code functionality
in the Linux FreeSWAN HW accel patch is under a BSD license.  From that
point on there is very little preventing a new, properly written FreeBSD
driver from happening.  I can send you all code parts under permissible
licenses for a sneek peek.  If there is genuine interest in writing such a
driver I can try to get you the programmer docs with an NDA permitting a new
BSD driver.  My account manager is pretty high up in the food chain there.
He's certainly the right guy to talk to and take the decision.

-- 
Andre