From owner-freebsd-current Fri Nov 16 17:40:36 2001 Delivered-To: freebsd-current@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 6040437B422; Fri, 16 Nov 2001 17:40:22 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA15998; Fri, 16 Nov 2001 17:23:22 -0800 (PST) Date: Fri, 16 Nov 2001 17:23:21 -0800 (PST) From: Julian Elischer To: Luigi Rizzo Cc: Peter Wemm , Julian Elischer , current@FreeBSD.ORG, net@FreeBSD.ORG, wollman@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. In-Reply-To: <20011116170214.A86121@iguana.aciri.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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