From owner-freebsd-current@FreeBSD.ORG Wed May 20 20:06:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55C191065771; Wed, 20 May 2009 20:06:06 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 305228FC1D; Wed, 20 May 2009 20:06:06 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id DDE6146B86; Wed, 20 May 2009 16:06:05 -0400 (EDT) Date: Wed, 20 May 2009 21:06:05 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andre Oppermann In-Reply-To: <4A1460A3.2010202@freebsd.org> Message-ID: References: <4A1460A3.2010202@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: rmacklem@uoguelph.ca, freebsd-current@freebsd.org Subject: Re: Socket related code duplication in NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 20:06:06 -0000 On Wed, 20 May 2009, Andre Oppermann wrote: > While working on an optimized soreceive_stream() function [1] and checking > the code how it is used I've come across quite a bit of code duplication in > the various NFS directories. > > Socket (read) operations are handled multiple times in a very similar manner > in these places: My recommendation would be to do this analysis against the new NFS client and server found in sys/{kgssapi,nlm,fs/{nfs,nfsclient,nfsserver}}, which is the NFSv234 implementation. Note in particular that in the new world order there's a centralize RPC implementation. The code you're looking at is a blend of the old NFSv23 client/server (nfsclient/nfsserver) and the old NFSv4 client (rpc/nfs4client), all if which are on a gradual de-orbit burn. Robert N M Watson Computer Laboratory University of Cambridge > > sys/rpc > sys/nfsclient > sys/nfsserver > > Also how the soreceive call is used is interesting. It certainly can be made > more efficient overall. > > My questions/observations/suggestions are as follows: > > a) Can the socket handling code be unified in one place for all NFS? > > b) The socket upcall mechanism is done per packet and can get expensive > for fast networks. It also has some additional unlock/lock overhead > plus that is delays protocol processing (even more so with netisr > direct dispatch where the code is run from an ithread). > > c) Can NFS be made to use a select() mechanism where it gets notified > when new data arrives? Just like in userspace. > > d) If not, it may be beneficial to have a taskqueue handle the upcall and > have the soappend call return immediately to complete processing of > the the protocol. > > e) The socket buffer is most efficient when it can aggregate a number of > packets together before they are processed. Can the NFS code set a low > water mark on the socket to get called only after a few packets have > arrived instead of each one? (In the select and taskqueue model.) > > f) I've been thinking of an modular socket filter approach (much like the > accept filter) scanning for upper layer specific markers or boundaries > and then signalling data availability. > > -- > Andre > > [1] Perforce: > //depot/user/andre/soreceive_stream/kern/uipc_socket.c::soreceive_stream() >