From owner-cvs-src@FreeBSD.ORG Sat Dec 23 18:58:07 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E93E16A403; Sat, 23 Dec 2006 18:58:07 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.freebsd.org (Postfix) with ESMTP id 2B6DF13C434; Sat, 23 Dec 2006 18:58:07 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.8/8.13.8) with ESMTP id kBNIRDLY065879; Sat, 23 Dec 2006 10:27:13 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <458BF314.3000702@samsco.org> Date: Sat, 23 Dec 2006 10:27:13 -0800 (PST) From: John Polstra To: Scott Long Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/bge if_bge.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Dec 2006 18:58:07 -0000 On 22-Dec-2006 Scott Long wrote: > In any case, the driver lock must not be held when calling if_input > because there are many ways the codepath can loop from there back into > if_start of the same driver or another driver. There is no way around > this without doing big decoupling steps that will impact common > performance cases. Agreed. > That said, dropping and regrabbing the driver lock in the rxeof > routine of any driver is bad. It may be safe to do, but it > incurs horrible performance penalties. It essentially allows the > time-critical, high priority RX path to be constantly preempted by > the lower priority if_start or if_ioctl paths. Even without this > preemption and priority inversion, you're doing an excessive number > of expensive lock ops in the fast path. We currently make this a lot worse than it needs to be by handing off the received packets one at a time, unlocking and relocking for every packet. It would be better if the driver's receive interrupt handler would harvest all of the incoming packets and queue them locally. Then, at the end, hand off the linked list of packets to the network stack wholesale, unlocking and relocking only once. (Actually, the list could probably be handed off at the very end of the interrupt service routine, after the driver has already dropped its lock.) We wouldn't even need a new primitive, if ether_input() and the other if_input() functions were enhanced to deal with a possible list of packets instead of just a single one. John