From owner-freebsd-net Tue Apr 10 11:37:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from rgmail.regenstrief.org (rgmail.regenstrief.org [134.68.31.197]) by hub.freebsd.org (Postfix) with ESMTP id 96A0C37B424 for ; Tue, 10 Apr 2001 11:37:07 -0700 (PDT) (envelope-from gunther@aurora.regenstrief.org) Received: from aurora.regenstrief.org (rgnout.regenstrief.org [134.68.31.38]) by rgmail.regenstrief.org (8.11.0/8.8.7) with ESMTP id f3AIceA24556; Tue, 10 Apr 2001 13:38:40 -0500 Message-ID: <3AD352CA.179721B@aurora.regenstrief.org> Date: Tue, 10 Apr 2001 18:36:58 +0000 From: Gunther Schadow Organization: Regenstrief Institute for Health Care X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: snap-users@kame.net, freebsd-net@freebsd.org Subject: FreeBSD fxp driver, offloading cryptography ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, question: is anyone working on the Intel Pro/100 S support in the fxp driver? I have found Intel to distribute a Linux driver and looking at the source code I found: - no mention of the crypto functions in the Linux driver - that the FreeBSD fxp driver looks noticeably different from the Intel supplied Linux driver source I suppose that we have no good documentation on the crypto functions of the Pro/100 S right? How could we get that information? Is anyone working on this? The driver source for Linux shows tons of definitions for wizardy control bits, CPU saver microcode, ethernet frames, TCP/UDP checksum calculation, etc., which I can't find in the fxp driver. This means to me, that the Intel card can do *much* more than we make it do with FreeBSD. We could significantly improve FreeBSD's use of the card resulting in better throughput at lower CPU and PCI bus load, at least so goes my reckoning. Is there any fill-in on the history of the fxp development? Are we trying to use more of this Intel driver source code? How would the KAME/IPsec code make use of the card's crypto chip? Does the fact that the NIC hardware can do crypto calculation trouble the layered design of KAME/IPsec code? Would it be a big mess to circumvent the KAME crypto code and use the Intel hardware instead? Is anyone interested and or working on this? Thanks, -Gunther -- Gunther Schadow, M.D., Ph.D. gschadow@regenstrief.org Medical Information Scientist Regenstrief Institute for Health Care Adjunct Assistent Professor Indiana University School of Medicine tel:1(317)630-7960 http://aurora.regenstrief.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message