From owner-freebsd-net Fri Nov 16 20:23: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 7301E37B416; Fri, 16 Nov 2001 20:22:53 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fAH4MPi30016; Fri, 16 Nov 2001 23:22:25 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 16 Nov 2001 23:22:24 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Luigi Rizzo Cc: Julian Elischer , 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-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In my MAC tree, I add an additional: struct mbuf *aux; /* extra data buffer; ipsec/others */ + struct mac label; /* label of data in packet */ }; As we move towards more generalized access control, it would similarly be nice to have a place to 'hang' additional labeling information for network transmission objects (packets, control messages, whatever). One of my primary concerns for such as system, and one of the reasons I haven't seriously contemplated implementing it, is how to maintain performance. In a non-SMPng world, it's already an issue, but once you throw in fine-grained locking/etc, you begin to worry about locking and referencing counting for these objects. Ideally, I think such as 'hooking' mechanism would be extremely flexible and transparent, but as you point out, performance is (and will continue to be) a primary concern in this code. It might be interesting to do some experimentation with various schemes for adding this extensibility. I've done a little bit of work to look at run-time vs. compile-time extensibility for the network stack. For example, I'm interested in the idea that the TCP/IP IPv4 implementation be pluggable via a kernel module. Adding such dynamicism would necessarily introduce locking/atomicity concerns during registration and removal. I'd like for it to be the case that if you link the module in at compile time (or before the kernel goes live during the boot), you'd maintain current native speed, but that if you dynamically load it, you accept the additional cost. One way to do this might be to have an optimized dynamically compiled structure (maybe derived from linker sets) either when the kernel is compiled or linked, for "fast path" processing. When there is a fast path miss, then the kernel falls back to a slower dynamic path. E.g., const struct ipproto *ipprotolist[] = {, , , ... NULL}; struct mtx ipprotolist_extensions_lock; struct ipproto *ipprotolist_extensions[]; Fast path hits would not require use of the mutex, but slow path would; dynamically introduced protocols would by definition be on the slow path, but if compiled in, would be attached to the fast path. Likewise, you could imagine mbuf extensibility working the same way: depending on how to consuming feature is loaded, it is provided a lock-free/fast extension capability, and if it is dynamically loaded, the slower alternative is selected. This would allow many locking costs to be avoided in the network code for optimized environment, but still allow the necessarily expensive extensibility. Just a thought. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services 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. > > > things it should be: > > > > 1/ flexible > > 2/ queueable > > 3/ transparent to 3rd party code that doesn't know about it. > > cheers > luigi > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message