Darren Reed writes: > On 18/03/09 06:48 PM, James Carlson wrote: > > What specificially is obscure? > > > > Having to mess around with fs/dev... > it doesn't seem architecturally very clean to have bits in fs/dev > that the bridge module needs to poke?
Ah, ok. Yes, it is an 'unusual' entanglement. The code that does it is fairly simple and is patterned after the existing "devnet" support in fs/dev: http://cr.opensolaris.org/~carlsonj/webrev-rbridges-2009-03-18/usr/src/uts/common/fs/dev/sdev_bridgeops.c.html The design document goes into detail about how this works because it wasn't all that easy to get right. The fs/dev plugins are not straightforward, and there are some interesting bugs in here (such as the problem with dld and taskq initialization), so I described those bits. As for the benefits: - It allows you to see all of the traffic on the bridge, much as a "monitor port" would on an external bridge. Snooping on a given port just shows the traffic sent/received on that port, which would not include any traffic that has a learned destination on a different port. After creating bridge "foo", you can do this: snoop -d foo0 (One design alternative for that would be adding a "monitor port" mode for each port. It's unclear how that would work -- whether it should function as a regular monitoring port on a bridge and actually transmit everything through the underlying port. Another alternative would be making promiscuous mode for snoop "special" on the bridge links and having it somehow bypass the bridge forwarding mechanism. That seems to violate the spirit of having a bridge, because you'd see traffic that ordinarily would have nothing to do with the port you're attached to, and it's not clear how to make it work.) - It allows us to get simple and obvious access to the bridge instance, by opening the observability device node. With access to the bridge instance, we can do useful things such as printing the forwarding tables. (Design alternatives for that are hard to find. Allowing bridge ioctls on the member links would be strange, and would require more invasive mac changes to make it work. The only other means I can think of would be using the global control node and some sort of "attach" mechanism, analogous to DL_ATTACH_REQ, to allow clients to specify the bridge they're asking about.) (Did you participate in the ARC review ... ?) -- James Carlson, Solaris Networking <[email protected]> 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 _______________________________________________ networking-discuss mailing list [email protected]
