Date: Mon, 21 Jul 2014 12:57:35 -0400 From: John Baldwin <jhb@freebsd.org> To: Garrett Wollman <wollman@hergotha.csail.mit.edu> Cc: net@freebsd.org Subject: Re: NFS client READ performance on -current Message-ID: <2198372.PMBsJPH0RH@pippin.baldwin.cx> In-Reply-To: <201407201556.s6KFuchL013781@hergotha.csail.mit.edu> References: <2136988575.13956627.1405199640153.JavaMail.root@uoguelph.ca> <201407201556.s6KFuchL013781@hergotha.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2198372.PMBsJPH0RH>