Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 01 Jun 2000 22:39:08 -0700
From:      Julian Elischer <julian@elischer.org>
To:        Archie Cobbs <archie@whistle.com>
Cc:        freebsd-net@freebsd.org
Subject:   Re: Patch review request (ng_ether(4))
Message-ID:  <3937487C.41C67EA6@elischer.org>
References:  <200006020145.SAA98179@bubba.whistle.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Archie Cobbs wrote:
> 
> Hi,
> 
> I'd appreciate any reviews of this patch:
> 
>   ftp://ftp.whistle.com/pub/archie/misc/NGETHER.patch
> 
> What this does is:
> 
>   - Change the ng_ether(4) netgraph node type to get rid of the
>     "divert" and "orphans" hooks, replacing them with these hooks:
> 
>       "lower" - connection to the raw device
>       "upper" - connection to the upper protocol layers
> 
>     This should allow much more interesting Ethernet operations
>     using netgraph, especially things that filter, etc. For example,
>     bridging can all be done with a netgraph node.
> 
>   - Moves all the netgraph-specific functionality out of net/if_ethersubr.c
>     and into a new file netgraph/ng_ether.c
> 
>   - Allows a KLD for ng_ether.ko so your kernel doesn't have to
>     be compiled with options NETGRAPH to use it. When loaded, all
>     ethernet interfaces become netgraph nodes as well.. including
>     PCCARDS inserted later.

This change removes the ability to only catch packets that are
unknown to the exisiting infrastructure.(i.e. orphans).
So you'd have to write code to do that especially in the netgraph
node..
The topography of the new interceptions are interesting and useful,
but I have a couple of concerns.

1/ impact. My original design was done as it was, so that in the 
case of no netgraph option, the path through the driver would
be unchanged. The new code is implemented so that 
under all cases there is an extra test and function call,
as ether_input() calls ether_input2().
I don't know the cost of this, but it should be investigated.

2/ Compatibility..
because there is no 'orphans' node, pppoe will probably have to
pass packets back to ether_input2()
which will be considerably slower than
what was going on before.

I'm interested in knowing what others think.


> 
> Note: ppp(8) will have to be modified slightly before this gets commited;
> haven't done this yet but it should be trivial.
> 
> Thanks,
> -Archie
> 
> ___________________________________________________________________________
> Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com

-- 
      __--_|\  Julian Elischer
     /       \ julian@elischer.org
    (   OZ    ) World tour 2000
---> X_.---._/  presently in:  Perth
            v


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?3937487C.41C67EA6>