Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 18 Nov 2001 10:09:46 -0800 (PST)
From:      Archie Cobbs <archie@dellroad.org>
To:        Julian Elischer <julian@elischer.org>
Cc:        Luigi Rizzo <rizzo@aciri.org>, Peter Wemm <peter@wemm.org>, Julian Elischer <julian@vicor-nb.com>, current@FreeBSD.ORG, net@FreeBSD.ORG, wollman@FreeBSD.ORG
Subject:   Re: re-entrancy and the IP stack.
Message-ID:  <200111181809.fAII9lp04548@arch20m.dellroad.org>
In-Reply-To: <Pine.BSF.4.21.0111161711470.6632-100000@InterJet.elischer.org> "from Julian Elischer at Nov 16, 2001 05:23:21 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer writes:
> > i actually suggested one i.e. have explicit pointers
> > to metadata area(s) in the pkthdr. I think you forget the
> > most fundamental feature which is performance.
> > This is way more important than flexibility i think.
> 
> Which is the reason that this problem exists..
> no-one ever thinks that people will want to do things different
> to what they want to do at the time they write it..
> 
> Flexibility is I think much more important than you suggest.
> Wouldn't it have made it easier for you if there had been a flexible
> method to pass such information available?
> The m_aux field sounds right to me.

IMHO m_aux is fine for this. It already includes built-in
support for 'blind' free'ing -- when you free an mbuf any
aux data automatically gets free'd with it, whether you put
it there or not. I've been using this for work-related stuff
and it works great.

As for performance, if there's only one or two m_aux structures
associated with an mbuf, then the linear search of the m_aux
list is not a big deal. If we start getting tons of m_aux's
piling up, *then* we can start worrying about optimization
(and there are plenty of options there).

-Archie

__________________________________________________________________________
Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200111181809.fAII9lp04548>