From owner-cvs-src@FreeBSD.ORG Mon Sep 5 16:53:31 2005 Return-Path: <owner-cvs-src@FreeBSD.ORG> X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B77516A41F; Mon, 5 Sep 2005 16:53:31 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2565C43D4C; Mon, 5 Sep 2005 16:53:31 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 5864B46B46; Mon, 5 Sep 2005 12:53:28 -0400 (EDT) Date: Mon, 5 Sep 2005 17:53:28 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> X-X-Sender: robert@fledge.watson.org To: Luigi Rizzo <rizzo@icir.org> In-Reply-To: <20050905094341.A23343@xorpc.icir.org> Message-ID: <20050905175127.L88940@fledge.watson.org> References: <200509051602.j85G2Bpo090258@repoman.freebsd.org> <20050905094341.A23343@xorpc.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, Gleb Smirnoff <glebius@FreeBSD.org>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_poll.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>, <mailto:cvs-src-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/cvs-src> List-Post: <mailto:cvs-src@freebsd.org> List-Help: <mailto:cvs-src-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>, <mailto:cvs-src-request@freebsd.org?subject=subscribe> X-List-Received-Date: Mon, 05 Sep 2005 16:53:31 -0000 On Mon, 5 Sep 2005, Luigi Rizzo wrote: > Also, what is the overall design - do you want to support multiple > polling loops running concurrently (netisr_poll, one poll_idle per CPU, > and possibly the poll_in_trap) ? Issues to be particularly careful about will be priority inversion and ordering. With a single thread associated with any given interface, the inversion problem might exist, but not the ordering issue, but if more than one thread may process a particular interface, there are potentially also ordering issues. It's been proposed that at the EuroBSDCon developer summit, we set aside a chunk of time to talk about the future structuring of polling -- in particular, how we can broaden the scope of the polling infrastructure to allow non-network device drivers also have their handlers run from a polled environment. A couple of hours of white board session would probably be quite useful, since I think there's a lot to discuss here. Robert N M Watson