Date: Thu, 15 Aug 2002 11:49:41 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Luigi Rizzo <rizzo@icir.org> Cc: ipfw@FreeBSD.ORG Subject: Re: RFC: new mbuf flag bit needed Message-ID: <Pine.BSF.4.21.0208151148090.27476-100000@InterJet.elischer.org> In-Reply-To: <20020815113824.B30190@iguana.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 15 Aug 2002, Luigi Rizzo wrote: > On Thu, Aug 15, 2002 at 10:49:22AM -0700, Julian Elischer wrote: > ... > > A bit to force non testing in a firewall might be useful in other places.. > > I'd however like to float an idea that maybe there should be more > > specific bits for input and output processing. > > unfortunately bits are a scarce resource in struct m_hdr which we > do not want to change in RELENG_4. Plus, many of the cases you are > mentioning are already taken care of with m_tag/annotations because > you need additional information: e.g. in the "fwd" you need the > fwd address anyways, same for divert (you need the 'next rule'), > and dummynet when you want multiple passes. > > The problem with protocol-specific bits is that you'll end up > overloading them, and once you pass the packets to a multi-protocol > module (such as netgraph, or ipfw2) you are in trouble. > E.g. M_PROTO1 has been overloaded by device drivers to report > some vlan-related info. The other M_PROTO* are all taken by > the KAME code. > > cheers > luigi > protocols should not expect to store flags there on packets that cross a protocol boundary. it would be for passing state around within a single protocol family.. such as you suggest. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" 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.0208151148090.27476-100000>