From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 6 21:05:08 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0DF92D55 for ; Wed, 6 Feb 2013 21:05:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D899DA13 for ; Wed, 6 Feb 2013 21:05:07 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 198F5B91E; Wed, 6 Feb 2013 16:05:07 -0500 (EST) From: John Baldwin To: Lino Sanfilippo Subject: Re: Mbuf memory handling Date: Wed, 6 Feb 2013 16:05:00 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <175CCF5F49938B4D99B2E3EF7F558EBE1C73F401F3@SC-VEXCH4.marvell.com> <175CCF5F49938B4D99B2E3EF7F558EBE1C73F4038E@SC-VEXCH4.marvell.com> In-Reply-To: <175CCF5F49938B4D99B2E3EF7F558EBE1C73F4038E@SC-VEXCH4.marvell.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201302061605.00583.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 06 Feb 2013 16:05:07 -0500 (EST) Cc: Hackers freeBSD , Axel Fischer , Jacques Fourie , Ralf Assmann , Markus Althoff X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 21:05:08 -0000 On Wednesday, February 06, 2013 2:41:32 pm Lino Sanfilippo wrote: > John, Jacques, > > thank you very much for your help. An mbuf cluster seems to be the right direction. > So I would have to do something like > > mbuf = m_getjcl(how, MT_DATA, M_PKTHDR, MJUMPAGESIZE); > left_for_next_rcv = m_split(mbuf, chunksize); > if_input(ifp, mbuf); > > right? > > >I agree that read-only buffers may be ok in this case but would like to point out that the M_WRITABLE() macro will evaluate to 0 if the refcount on the cluster is >1 > > The fact that the resulting mbufs returned by m_split() are not writeable any more is indeed a problem: > What I would like to do is keep the 'left_for_next_rcv' mbuf until the next packet arrives and > then fill it with the next packets data only up to 'chunksize', split it again to pass the new mbuf to > the protocol stack and so on until 'left_for_next_rcv' becomes too small to be splitted further. > Only then I would want to allocate a new "fresh" jumbo sized mbuf. Is it possible to > realize this with cluster mbufs? They are only read-only in the sense that you can't call routines like m_pullup() or m_prepend(), etc. Your device should still be able to DMA into the buffer, but once the buffer is passed up to the stack the stack can't mess with it. This is probably what you want anyway as you wouldn't want the stack appending to a buffer and spilling over into the cluster where your device is going to DMA the next packet. -- John Baldwin