Redirecting to crossbow-discuss at opensolaris.org... Nicolas Droux wrote:>> One important issue did come up here: we need to define the relative >> ordering between L2 filtering and bridging, and I believe it makes >> sense to put L2 filtering closer to the physical I/O. In other words, >> L2 filter should do its work underneath the bridge. > > There''s filtering which needs to occur between multiple MAC clients > (VNICs are MAC clients) defined on top of the same data-link. For > example to be consistent with the way things work in the physical > world, one might want to prevent a VM to be able to specific send > packets on the wire, which in this case would include a bridge. On the > transmit side these checks would have to be done before the packet is > potentially sent through a bridge, i.e. the L2 filtering would have to > be done "on top" of the bridge.I think we have a very urgent need to make the function pointer games with rx and tx (that Crossbow encourages and makes possible) into a proper interface where we can specify ordering, etc. Looking at what''s being done for L2 filtering does not give me a whole lot of confidence about it being a reliable way to achieve something. As an example of another use of these hooks, one might want to use them for in-line observability rather than using mac_open() and causing lots of packets to be duplicated. Now where would that fit in the stack of functions to do filtering and bridging? And how would that desire be conveyed? Darren
Darren Reed writes:> I think we have a very urgent need to make the function pointer > games with rx and tx (that Crossbow encourages and makes possible) > into a proper interface where we can specify ordering, etc. Looking > at what''s being done for L2 filtering does not give me a whole lot > of confidence about it being a reliable way to achieve something.I can''t tell. The existing Crossbow code seems to make ordering a matter of design: where you hook in relative to everyone else determines what order things happen in. There''s no separate specified ordering mechanism.> As an example of another use of these hooks, one might want to > use them for in-line observability rather than using mac_open() > and causing lots of packets to be duplicated. Now where would > that fit in the stack of functions to do filtering and bridging? > And how would that desire be conveyed?In another system I worked on long ago, we recognized that there just was no single answer to the observability problem. For some circumstances, it makes sense to get data as fresh off the wire as can be achieved. In other circumstances, you want it after some L2 processing has been done or L3 or even higher. The architecture we ended up with was a single "tap" interface that allowed the client to specify which of a set of pre-defined ''levels'' would be used. We then had a set of internal interfaces that allowed the "tap" code to intercept at any of those levels. I don''t know whether that has to happen here, but I do think that the existing DLPI-based observation mode has aged well past its prime. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677