Mbuf memory handling

Lino Sanfilippo lsanfil at marvell.com
Thu Feb 14 10:10:22 UTC 2013



> -----Original Message-----
> From: John Baldwin [mailto:jhb at 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
> 
> 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.
> 

I implemented the solution yesterday and everything seems to work. Thank you!

Lino 


More information about the freebsd-hackers mailing list