From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 17:03:37 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4076735 for ; Mon, 21 Jul 2014 17:03:37 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9C23F2D26 for ; Mon, 21 Jul 2014 17:03:37 +0000 (UTC) Received: from pippin.baldwin.cx (75-48-77-17.lightspeed.cncrca.sbcglobal.net [75.48.77.17]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 18C4BB91E; Mon, 21 Jul 2014 13:03:35 -0400 (EDT) From: John Baldwin To: Garrett Wollman Subject: Re: NFS client READ performance on -current Date: Mon, 21 Jul 2014 12:57:35 -0400 Message-ID: <2198372.PMBsJPH0RH@pippin.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: <201407201556.s6KFuchL013781@hergotha.csail.mit.edu> References: <2136988575.13956627.1405199640153.JavaMail.root@uoguelph.ca> <201407201556.s6KFuchL013781@hergotha.csail.mit.edu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 21 Jul 2014 13:03:35 -0400 (EDT) Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 17:03:37 -0000 On Sunday 20 July 2014 11:56:38 Garrett Wollman wrote: > In article <201407151034.54681.jhb@freebsd.org>, jhb@freebsd.org writes: > >Hmm, I am surprised by the m_pullup() behavior that it doesn't just > >notice that the first mbuf with a cluster has the desired data already > >and returns without doing anything. > > The specification of m_pullup() is that it returns a *writable* mbuf > (and thus also that the "length" provided is less than MHLEN). > Clusters are read-only. Well, my patch to if_em is definitely correct then as it doesn't want a writable mbuf, it just wants a certain portion of the mbuf chain to be stored in the first segment. Also, you should fix the manpage. It doesn't mention writable at all, just that the data is accessible so that mtod() will work: m_pullup(mbuf, len) Arrange that the first len bytes of an mbuf chain are contiguous and lay in the data area of mbuf, so they are accessible with mtod(mbuf, type). It is important to remember that this may involve reallocating some mbufs and moving data so all pointers referencing data within the old mbuf chain must be recalculated or made invalid. Return the new mbuf chain on success, NULL on fail- ure (the mbuf chain is freed in this case). Note: It does not allocate any mbuf clusters, so len must be less than or equal to MHLEN. -- John Baldwin