Hifn driver in SMP (was Re: GELI - disk encryption GEOM class
committed.)
Sam Leffler
sam at errno.com
Tue Aug 9 22:22:19 GMT 2005
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
More information about the freebsd-current
mailing list