From owner-freebsd-current Mon Mar 12 13:44:33 2001 Delivered-To: freebsd-current@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 7C86C37B71A for ; Mon, 12 Mar 2001 13:44:20 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f2CLi3f92042; Mon, 12 Mar 2001 23:44:05 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200103122144.f2CLi3f92042@gratis.grondar.za> To: Matt Dillon Cc: current@FreeBSD.ORG Subject: Re: Ethernet entropy harvesting seriously pessimizes performance References: <200103122103.f2CL3YZ74166@earth.backplane.com> In-Reply-To: <200103122103.f2CL3YZ74166@earth.backplane.com> ; from Matt Dillon "Mon, 12 Mar 2001 13:03:34 PST." Date: Mon, 12 Mar 2001 23:45:00 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I don't understand what is so difficult about simply rate-limiting > the code at the proper point -- at the very beginning of the > call that the interrupt harvester makes, removing most of the fixed > overhead for the case where a system is getting a large number of > interrupts per second? Why are you going through loops to create > complex, sensitive code paths when a simple solution can be plopped > down and will work, SNAP, just like that? Because I need to make folks other than you happy. Lots of security minded people what _all_ the interrupt entropy they can get, and this method gives them that while allowing others to throttle the harvester back. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message