Date: Fri, 16 Nov 2001 16:33:17 -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.0111161617160.6632-100000@InterJet.elischer.org> In-Reply-To: <20011116160458.B85435@iguana.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0111161617160.6632-100000>