Date: Tue, 09 Aug 2005 15:22:59 -0700 From: Sam Leffler <sam@errno.com> To: Andre Oppermann <andre@freebsd.org> Cc: Poul-Henning Kamp <phk@haven.freebsd.dk>, Michael Reifenberger <mike@Reifenberger.com>, freebsd-current@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, Mike Tancsa <mike@sentex.net> Subject: Re: Hifn driver in SMP (was Re: GELI - disk encryption GEOM class committed.) Message-ID: <42F92CC3.7060609@errno.com> In-Reply-To: <42F884C3.20505@freebsd.org> References: <42475.1123513974@phk.freebsd.dk> <42F786FC.1090805@freebsd.org> <42F82E23.9010307@errno.com> <42F884C3.20505@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42F92CC3.7060609>