From owner-freebsd-net@FreeBSD.ORG  Fri Mar 16 13:21:27 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 7208F16A404
	for <freebsd-net@freebsd.org>; Fri, 16 Mar 2007 13:21:27 +0000 (UTC)
	(envelope-from rwatson@FreeBSD.org)
Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42])
	by mx1.freebsd.org (Postfix) with ESMTP id 1CB4C13C44C
	for <freebsd-net@freebsd.org>; Fri, 16 Mar 2007 13:21:27 +0000 (UTC)
	(envelope-from rwatson@FreeBSD.org)
Received: from fledge.watson.org (fledge.watson.org [209.31.154.41])
	by cyrus.watson.org (Postfix) with ESMTP id 356864741F;
	Fri, 16 Mar 2007 08:21:25 -0500 (EST)
Date: Fri, 16 Mar 2007 14:21:25 +0100 (BST)
From: Robert Watson <rwatson@FreeBSD.org>
X-X-Sender: robert@fledge.watson.org
To: Aniruddha Bohra <bohra@cs.rutgers.edu>
In-Reply-To: <45FA98DD.3080205@cs.rutgers.edu>
Message-ID: <20070316141836.J60288@fledge.watson.org>
References: <45FA98DD.3080205@cs.rutgers.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: freebsd-net@freebsd.org
Subject: Re: ether_input question
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2007 13:21:27 -0000


On Fri, 16 Mar 2007, Aniruddha Bohra wrote:

> In two drivers, fxp and em, the assumptions about entering the ether_input 
> routine are different. From em_rxeof:
>
> #ifdef DEVICE_POLLING
> EM_UNLOCK()
> (*ifp->if_input)()
> EM_UNLOCK()
> #else
> (*ifp->if_input)()
> #endif
>
> While in fxp:
>
> FXP_UNLOCK()
> (*ifp->if_input)()
> FXP_LOCK()
>
> My question is : Does ether_input() assume it is the only thread executing 
> the code? If it is the case, what is the reason for dropping the lock in the 
> DEVICE_POLLING case?

I can't speak to the details of the above, but can speak generally on the 
issue of the link layer input path and locking.  There is no assumption that 
the caller will provide serialization, and fully concurrent input from 
multiple threads is supported.  The reason the drivers drop their locks is 
that the network stack frequently holds locks over calls to driver output 
routines.  As a result, driver locks tend to follow network stack locks in the 
lock order--at least, for drivers that have a single lock covering both send 
and receive paths (quite common).  As a result, the driver must drop the 
driver lock before calling into the stack to avoid a lock order reversal.

Robert N M Watson
Computer Laboratory
University of Cambridge