From owner-freebsd-net@FreeBSD.ORG Sat Mar 14 12:10:03 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A970F106564A for ; Sat, 14 Mar 2009 12:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9715C8FC18 for ; Sat, 14 Mar 2009 12:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2ECA3LZ019355 for ; Sat, 14 Mar 2009 12:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2ECA3TH019354; Sat, 14 Mar 2009 12:10:03 GMT (envelope-from gnats) Date: Sat, 14 Mar 2009 12:10:03 GMT Message-Id: <200903141210.n2ECA3TH019354@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= Cc: Subject: Re: misc/132277: poor performance using criptodevice for IPSEC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 12:10:03 -0000 The following reply was made to PR kern/132277; it has been noted by GNATS. From: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= To: bug-followup@FreeBSD.org Cc: Vasile Marii Subject: Re: misc/132277: poor performance using criptodevice for IPSEC Date: Sat, 14 Mar 2009 13:05:52 +0100 Le Sun, 8 Mar 2009 20:00:11 GMT, Patrick Lamaizière : > I've made some tests on IPsec with glxsb and the performances are > very bad (around 14 Mbits). > > I think the problem is that glxsb handles only one request at a time. > When it is busy, it blocks the Open Crypto Framework with ERESTART > and it unblocks the OCF when the previous request is completed. Then > the OCF has to wake up and to resubmit the request. It looks like > this performs very badly when using it with IPsec. > > If glxsb processes the requests synchronously it performs quite > better, around 50 Mbits. I've filled a PR with a patch for glxb(4): kern/132622 Regards.