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

Andre Oppermann wrote:
> 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.
> 

I can only guess you have been looking at Cavium's low-end parts if the 
dma engine is what impresses you.  There are plenty of crypto parts that 
can use a full 64/133 PCI bus (and more); in fact many companies assign 
the dma engine work to summer interns 'cuz it's so drop-dead easy (mind 
you I've also seen plenty of dma engines the _looked_ like they were 
designed by summer interns :)).

Cavium's high-end parts that promise very high throughput will perform 
suboptimally if hooked up to crypto(9) because you simply cannot keep 
the crypto engine(s) busy.  You must use the higher-level directives 
that do things like processs complete ipsec frames.

I have more that passing experience with Cavium.  You might want to try 
actually working with them and not just reading docs.

	Sam