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-net" 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>