From owner-freebsd-arch@FreeBSD.ORG  Fri Sep 30 12:47:37 2005
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
X-Original-To: arch@FreeBSD.org
Delivered-To: freebsd-arch@FreeBSD.ORG
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 6D0E116A42F;
	Fri, 30 Sep 2005 12:47:37 +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 2935843D48;
	Fri, 30 Sep 2005 12:47:37 +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 4555F46B11;
	Fri, 30 Sep 2005 08:47:36 -0400 (EDT)
Date: Fri, 30 Sep 2005 13:47:36 +0100 (BST)
From: Robert Watson <rwatson@FreeBSD.org>
X-X-Sender: robert@fledge.watson.org
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
In-Reply-To: <32170.1128084231@critter.freebsd.dk>
Message-ID: <20050930134526.R71864@fledge.watson.org>
References: <32170.1128084231@critter.freebsd.dk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: arch@FreeBSD.org, Gleb Smirnoff <glebius@FreeBSD.org>, net@FreeBSD.org
Subject: Re: [REVIEW/TEST] polling(4) changes 
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Sep 2005 12:47:37 -0000

On Fri, 30 Sep 2005, Poul-Henning Kamp wrote:

> I still think we should stop having this network-centric view of polling 
> and implement _real_ *device* polling, so that other device types can 
> use it as well.

While I agree that we should offer polling to non-network device drivers 
also, I think it's worth observing that the network awareness of our 
current polling code has some interesting advantages.  For one thing, the 
framework itself is aware of the notion of batching and moderating the 
workload as it is aware of the number of mbufs being processes, and knows 
to bound the workload, etc.  We'll need to revisit many of the ideas in 
the current polling implementation (designed largely around 4.x operating 
assumptions) anyway, but I think it's important we understand some of the 
implicit design benefits that are present in the current system as well...

Robert N M Watson