Date: Fri, 16 Nov 2001 17:23:21 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Luigi Rizzo <rizzo@aciri.org> Cc: 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: <Pine.BSF.4.21.0111161711470.6632-100000@InterJet.elischer.org> In-Reply-To: <20011116170214.A86121@iguana.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 16 Nov 2001, Luigi Rizzo wrote: > > so far there hasn't been a lot of suggestion as to how the goal can be > > achieved however.. > > 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. Alternatively, the ability to define a separate data area in an M_HDR mbuf.. (There's a lot of wasted space there in M_EXT packets.) [normal header][pkthdr][METADATA][normal_data] The metadata would be there regardless of whether the M_EXT flag was set or not. > > > things it should be: > > > > 1/ flexible I.e Don't screw over Luigi's NEXT project, Dummynet2. > > 2/ queueable I want to let dummynet2 do queuing of packets and keep my 'class' information with each packet. > > 3/ transparent to 3rd party code that doesn't know about it. I don't want My module to have to know about the stuff Dummynet2 is storing with the packet, and I don't want dummynet2 to need to know what I have stashed in there.. 4/ Self-descriptive: If I free a packet, I shouldn't produce a leak of some other items somewhere else. (they should describe how they should be freed!) > > cheers > luigi > 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?Pine.BSF.4.21.0111161711470.6632-100000>