From owner-freebsd-net Fri Nov 16 16:40:34 2001 Delivered-To: freebsd-net@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 CFCD537B41A; Fri, 16 Nov 2001 16:40:27 -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 QAA15761; Fri, 16 Nov 2001 16:33:19 -0800 (PST) Date: Fri, 16 Nov 2001 16:33:17 -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: <20011116160458.B85435@iguana.aciri.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@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: > On Fri, Nov 16, 2001 at 04:02:51PM -0800, Peter Wemm wrote: > > > it. MT_DUMMYNET must die, not be propagated elsewhere. > > i agree! > > cheers > luigi > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > so far there hasn't been a lot of suggestion as to how the goal can be achieved however.. things it should be: 1/ flexible 2/ queueable 3/ transparent to 3rd party code that doesn't know about it. i.e. if I have metadata with a packet that is passed to a packet filter, that decides that it should be queued (like dummynet), I want the dequeued packet to still have that metadata with it. If I give it to an encryption module, and get it back I don't want the encryption module to have deleted the metadata. We do this in netgraph successfully, where we can store packet priority data (for example) to ensure that housekeeping packets overtake data packets in frame relay. (if you don't do this the fram relay exchange will shot down the link when it gets busy and the housekeeping packets are delayed). We also include data to do with throughput limits and clasification after it has passed though a classifier node. You can't do these things unless you have per-packet information. The idea of the (struct mbuf * m_aux) field is fine by me but that is still using an mbuf, which some people seem to be against.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message