Date: Fri, 16 Nov 2001 23:22:24 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Luigi Rizzo <rizzo@aciri.org> Cc: Julian Elischer <julian@elischer.org>, 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.NEB.3.96L.1011116231323.28766C-100000@fledge.watson.org> In-Reply-To: <20011116170214.A86121@iguana.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1011116231323.28766C-100000>