Re: question about mbuf intialization

[Iain Hibbert <plunky%ogmig.net@localhost>]

On Wed, 18 Sep 2013, Beverly Schwartz wrote:

>
> On Sep 18, 2013, at 12:16 PM, Matt Thomas <matt%3am-software.com@localhost> 
> wrote:
>
> >
> > On Sep 18, 2013, at 8:33 AM, Beverly Schwartz <bschwart%bbn.com@localhost> 
> > wrote:
> >
> >> Any reason why we can't add
> >>    m->m_len = 0;
> >> to m_get, and
> >>    m->m_pkthdr.len = 0;
> >> to m_gethdr?
> >
> > Why not m->m_len = MLEN or MHLEN and m->m_pkthdr.len = MHLEN?
> >
> > That way you know how much space is left.
>
> m_len and m_pkthdr.len report on the data that is there, not on how much
> space exists.  At initialiation, there is no data, so should be
> initialized to 0.

Weeell, it sometimes is the space rather than the data. for example,
m_copyback() will copy data into the space that is there and then possibly
extend the chain. if you give it a mbuf with zero data lengths, and ask to
copy more data? it just adds another mbuf which contains all the data..

> > But in reality, it's expected the user knows that the length
> > fields and/or m_data need to be adjusted.

this. it is difficult for the library routines to know how much space is
available (the data buffer can be external), so the caller is mostly
responsible, I think.

> As long as functions like m_copyback exist which provide a different way
> to load up data (and these function *do* update m_len and pkthdr.len),
> it seems that we just add a burden to the user that doesn't have to be
> there.  At the very least, the mbuf man page should indicate that these
> fields need to be initialized by the user.
>
> Is there a downside to providing the initialization?  If not, why not do
> it?  It reduces the chances of error because some user doesn't realize
> these fields are not initialized.

I suspect it dates from the time when lazy initialization really made a
difference to performance. perhaps on modern processors, this is not as
much of an issue (though NetBSD still runs on VAX and amiga at least..
those are not necessarily fast machines)

the documentation could probably be improved, of course..

regards,
iain