From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 6 17:04:09 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 127216B8; Wed, 6 Feb 2013 17:04:09 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 56C78AC2; Wed, 6 Feb 2013 17:04:08 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id r6so1314141wey.5 for ; Wed, 06 Feb 2013 09:04:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NopDyO40xAK74thNTluM2wmELVwmb4wQx4dxHhoQ3hE=; b=c107JQq8lXkbdsUkOrbknUfuWx1RYHjgNFNl45TrxrNSRsO/eSxiciD96IymgGgPgJ jf3ZtHMfDpm6MYNoPs2UrEqoidoEH/a+1JMF+m/51x6Sge3Ekvitn5Sg49uEHS5s+WuI rM0nj2Mre+pIOaPlY25J/HGPyYOd02HGhtTieY/r34DWlexGGVPfV0EJT15721XIYDf7 Q6QkjvBewhRSLo9rRDgsH0e/4SrcVwttDVdF0FWZNOaMoKP4vZFeBTOlskkkt3VsDGKx gE3WbCHMTNYrhU4BLuhDQz4PEWPkbtRb6C2khmzg9CvSlGpd2s81UdMful2/oER9jDhX LguA== MIME-Version: 1.0 X-Received: by 10.194.158.100 with SMTP id wt4mr51215150wjb.37.1360170247407; Wed, 06 Feb 2013 09:04:07 -0800 (PST) Received: by 10.194.110.132 with HTTP; Wed, 6 Feb 2013 09:04:07 -0800 (PST) In-Reply-To: <201302061137.35651.jhb@freebsd.org> References: <175CCF5F49938B4D99B2E3EF7F558EBE1C73F401F3@SC-VEXCH4.marvell.com> <201302060836.55404.jhb@freebsd.org> <201302061137.35651.jhb@freebsd.org> Date: Wed, 6 Feb 2013 19:04:07 +0200 Message-ID: Subject: Re: Mbuf memory handling From: Jacques Fourie To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Hackers freeBSD , Axel Fischer , Lino Sanfilippo , 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 17:04:09 -0000 On Wed, Feb 6, 2013 at 6:37 PM, John Baldwin wrote: > On Wednesday, February 06, 2013 10:20:50 am Jacques Fourie wrote: > > On Wed, Feb 6, 2013 at 3:36 PM, John Baldwin wrote: > > > > > On Wednesday, February 06, 2013 4:50:39 am Lino Sanfilippo wrote: > > > > > > > > Hi all, > > > > > > > > I want to implement a device driver for a NIC which stores received > data > > > into chunks within > > > > a page (>=4k) in host memory. One page shall be used for multiple > > > packets and freed > > > > after all mbufs linked to that page have been processed. So I would > like > > > to know what is the recommended way > > > > to handle this in FreeBSD? Any hints are very appreciated. > > > > > > I think you can get what you want by allocating M_JUMBOP mbuf clusters > for > > > your receive buffers. When you want to split out a packet, allocate a > new > > > packet header mbuf and use m_split() to let it take over the rest of > the 4k > > > buffer and pass the original mbuf up to if_input() as the new packet. > The > > > new mbufs you attach to the cluster via m_split() will all hold a > reference > > > on the backing cluster and it won't be freed until all the mbufs are > freed. > > > > > > The resulting mbufs will not be writeable (M_WRITABLE() will evaluate > to > > 0), right? I don't know if this will be an issue in this particular > > application. > > No, they only propagate an existing M_RDONLY flag: > > n->m_flags |= m->m_flags & M_RDONLY; > > If the first mbuf is writable the splits remain writable from my reading > of the code. OTOH, I think in this case read-only buffers passed up to > the stack are probably fine since they are already contiguous so any > pullup should be a NOP, etc. > > 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, even if the M_RDONLY flag is not set. So the various parts of the networking code that uses M_WRITABLE() to decide if the mbuf is writeable will treat the mbuf as read-only. > -- > John Baldwin >