From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 21:16:29 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 892144A7; Fri, 18 Jan 2013 21:16:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4749185D; Fri, 18 Jan 2013 21:16:29 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5A8A0B94C; Fri, 18 Jan 2013 16:16:28 -0500 (EST) From: John Baldwin To: Adrian Chadd Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() Date: Fri, 18 Jan 2013 16:03:32 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <1358519440.88044.YahooMailClassic@web121605.mail.ne1.yahoo.com> <201301181149.42277.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301181603.32393.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 18 Jan 2013 16:16:28 -0500 (EST) Cc: freebsd-net@freebsd.org, Luigi Rizzo , Barney Cordoba X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 21:16:29 -0000 On Friday, January 18, 2013 3:07:35 pm Adrian Chadd wrote: > For my purposes, rescheduling the taskqueue means that other things > (such as TX, reset processing, other state handling, etc) can run > before the next pass at RX completion. That only works if your taskqueue thread has a priority <= those things. I think the e1000 drivers use the same priority for their taskqueue threads as the ithreads use, so the effectively preempt just about everything and are not preempted by other task queues or swi threads, etc. > Also, IIRC, acquiring mutexes are one of those magic points where the > scheduler may decide to switch things around in a preemption kernel. No, releasing mutexes (and any other place that makes a non-runnable thread runnable), and only if it wakes up a thread with a more important priority. -- John Baldwin