From owner-freebsd-current@FreeBSD.ORG Wed May 20 20:24:03 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 BDCA0106564A for ; Wed, 20 May 2009 20:24:03 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 30EBA8FC16 for ; Wed, 20 May 2009 20:24:02 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 35005 invoked from network); 20 May 2009 19:51:03 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 20 May 2009 19:51:03 -0000 Message-ID: <4A1460A3.2010202@freebsd.org> Date: Wed, 20 May 2009 21:57:23 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: rmacklem@uoguelph.ca, dfr@rabson.org, rwatson@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: 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:24:04 -0000 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: 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()