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
[EMAIL PROTECTED]      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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to