Jim,
I have included below a proposal which would allow bridging to
cleanly integrate with mac without the introduction of special
cases in the common data-path, and enabling bridging to
leverage the layer-2 classification that was introduced
by Crossbow. The proposal takes into account the issues we
discussed earlier in this thread.
- per bridge table
- based on existing bridging implementation, captures MAC
addresses associated with ports, time stamps needed
to track lifetime of entries, etc.
- table could be a flow table, but this is not the main
goal of this proposal.
- new promiscuous callback flag, synchronous
- bridge registers promiscuous callback with mac,
specifies (new) sync flag
- mac calls the registered callback with original packet
(read-only)
- bridge inspects packet to extract MAC addresses
- bridge updates its table according to MAC address
- bridge calls mac to add entries to the layer-2 flow tables
of the ports associated with the bridge.
- updates to the MAC layer-2 flows
- entries are added and removed to and from the layer-2
classification table of a MAC instance (port) via a flow
API provided by mac to the bridging code.
- updates to these MAC classification tables are done
when addresses are added to/removed from the bridge table
- The callback function is a bridge processing function,
the cookie points to the bridge table entry for the
MAC address
- The flow addition/deletion API can be restructured
to no longer require the MAC perimeter to be held
when flow entries are added and deleted by the bridge.
This would allow the updates to be done without the
help of a worker thread, and would scale better with
frequent updates.
- The flow API can be extended to allow a set of flows
to be removed with a single call. A MAC client handle
and cookie could be used to identify the set of
flows to be removed.
- TX/RX data path
- does not require special processing on data-path
- RX and TX classification causes the MAC addresses
registered by the bridge to be matched against
the destination MAC address of sent and received packets
- packets are passed to bridge callback along with
registered cookie
- bridge gets packet, and knows destination to forward packet
to appropriate destination associated with the MAC address
- in the future, can takes advantage of TX fastpath
transparently
- introduce a new "no match" mac callback, invoked when there's
no match on a MAC address lookup. Currently this is hard-coded
in the data-path to send the packet on the wire, and
a more generic mechanism would allow a bridge to receive
a copy of such packets.
Nicolas.
--
Nicolas Droux - Solaris Kernel Networking - Sun Microsystems, Inc.
droux at sun.com - http://blogs.sun.com/droux
