From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 10:10:22 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 BA2237C4; Thu, 14 Feb 2013 10:10:22 +0000 (UTC) (envelope-from lsanfil@marvell.com) Received: from na3sys009aog123.obsmtp.com (na3sys009aog123.obsmtp.com [74.125.149.149]) by mx1.freebsd.org (Postfix) with ESMTP id 8ECAC20E; Thu, 14 Feb 2013 10:10:21 +0000 (UTC) Received: from SC-OWA01.marvell.com ([199.233.58.136]) (using TLSv1) by na3sys009aob123.postini.com ([74.125.148.12]) with SMTP ID DSNKURy4B7es01S+P+//MTYCo+HzsDTHYe7Y@postini.com; Thu, 14 Feb 2013 02:10:22 PST Received: from SC-VEXCH4.marvell.com ([0000:0000:0000:0000:0000:0000:0.0.0.1]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Thu, 14 Feb 2013 02:06:56 -0800 From: Lino Sanfilippo To: John Baldwin Date: Thu, 14 Feb 2013 02:06:55 -0800 Subject: RE: Mbuf memory handling Thread-Topic: Mbuf memory handling Thread-Index: Ac4EraXPcYPlCn64TSe+AJIoHaz8HAF7NvsQ Message-ID: <175CCF5F49938B4D99B2E3EF7F558EBE1C7403C42E@SC-VEXCH4.marvell.com> References: <175CCF5F49938B4D99B2E3EF7F558EBE1C73F401F3@SC-VEXCH4.marvell.com> <175CCF5F49938B4D99B2E3EF7F558EBE1C73F4038E@SC-VEXCH4.marvell.com> <201302061605.00583.jhb@freebsd.org> In-Reply-To: <201302061605.00583.jhb@freebsd.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Thu, 14 Feb 2013 10:10:22 -0000 > -----Original Message----- > From: John Baldwin [mailto:jhb@freebsd.org] > Sent: Mittwoch, 6. Februar 2013 22:05 > To: Lino Sanfilippo > Cc: Jacques Fourie; Hackers freeBSD; Axel Fischer; Markus Althoff; Ralf > Assmann > Subject: Re: Mbuf memory handling >=20 > 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 =3D m_getjcl(how, MT_DATA, M_PKTHDR, MJUMPAGESIZE); > > left_for_next_rcv =3D 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? >=20 > 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. >=20 I implemented the solution yesterday and everything seems to work. Thank yo= u! Lino=20