> Mark, > > Thanks for the code/proposal. We also toyed with having the MAC > layer pass > a dls_impl_t down and back up but we didn't like messing up the > DLS/MACinterface so much. I hope you'll like solution that Dong- > Hai and I are > experimenting with, which we will post soon (I'm hoping within 24 > hours).
(As MIke promised, within 24 hours. :-) ) Hello, Mark, I am posting the materials Mike mentioned earlier, the webrev of the changes is: http://www.omnicron.com/~ford/webrev_bridging_dlpi.premacplugin/ As the path implies, it's not the latest snv version( I can't post the latest version since some of other changes are not open yet) , but it's newer than the version on opensolaris I guess, and we think you (and others) will not have problem understanding it. And, below is the proposal we sent out to some internal aliases a while ago: Best, Donghai. ---------------------------------------------------------------------------------------------------------------------------- DLPI loopback changes proposal by bridging project Overview ======== The bridging project i-team proposes changing loopback logic of DLPI, specifically for Nemo, some of the implementation details need changes. This change is needed for adding bridge function to Solaris, and this change is designed and implemented to not affect the users of DLPI. Of course, since this proposal changes the loopback logic, some potential problems may occur, and in future, other projects will have to take this into consideration. Background ========== The loopback function has been in Solaris DLPI implementations for a while, the main usage is for applications like snoop to gather packets sent out from local stack, and till now, it's bound to the promiscuous mode, that is, only when there are promiscuous users, the Data Link Provider will loop packets back. This logic worked well, since it used to be that only promiscuous users are interested in looped back packets. However, when bridge function( yes, it's the common bridge, or switch function) is added to Solaris, things change, a packet bridged by the bridge module may be headed for local ip stack, which is not promiscuous, that means, we have to loop packets back to non-promiscuous users. Also, this imposes another request, that the loopback mechanism must identify the sender of a packet and avoid loopking the packet back to the sender. Current loopback implementation in Nemo does the loopback at MAC layer while most of the loopback happens between DLS users, and the MAC layer couldn't( and shouldn't) distinguish DLS users, so it's hard to avoid the loopback to sender problem. Also, though with careful design, current MAC layer loopback doesn't have any performance problem, it has some logic problems by doing all the loopback at MAC layer. Proposed Solution ================= Based on the requirements of bridge, here we propose following changes[1] to the loopback logic: 1. Whenever a DLPI user receives packets, it is a potential acceptor of loopback packets. 2. Whenever there are multiple DLPI users on a DLS provider, and at least one of the users is sending packets, the potential acceptor should start receiving loopback packets. [1]For a more complete description of the idea behind these changes, please refer to the article and CR in the Reference section. Ideally this logic should work for all the situations, however, in practice, it will impose performance problems, for example, when we plumb an interface using ifconfig(1M), ip and arp will be added to the user list of the interface, and with these two users, the above logic is met and loopback will be enabled, which is not necessary of course. Because of this, some restrictions are added( currently, in Nemo implementation)[2]: 1. At least one of the DLPI users is in promiscuous mode, this works now since currently bridge is behind all these changes, and bridge module is a promiscuous user. However, if in the future the situations change, this should be changed too. 2. If no user is promiscuous, then loopback is enabled when there are users with same sap. Of course, a user with sap X could send packets to sap Y, but in real world, no such user is normal. [2]Ideally we should do what Mike Ditto has described in his article and the CR, that is, the transmit path should check each packet and see if the destination MAC address "macthes" the local MAC address, however, Because of fear of performance problems, this step is omitted, it would be a more pure design to add the destination address comparison but it's not necessary for the immediate goal of supporting bridging. Based on above conceptual changes, we have finished the prototype for Nemo, the changes are: 1. The loopbcak happens at multi-level, including MAC layer and DLS layer, that is, MAC layer do loopback for MAC users like DLS and AGGR, while DLS layer do loopback for it's users, like IP stack, snoop, and bridge. This way, it utilizes the well designed DLS layer, and it's very easy to distinguish the sender(dls_imp_t) of the packets. 2. mac_tx_get now returns mi_txloopinfo only when there are users registered through mac_txloop_add, disregarding it's promiscuous or not. With these changes to loopback behaviour, please be noted that in new code DLS uses the MAC layer's transmit loopback, receive, and "active" client features in subtly different ways from the original design, now it works this way: 1. DLS will register an rx callback with the MAC provider whenever there is at least one bound DLS user. "active" mode does not enter into this. 2. DLS will register a txloop callback with the MAC module whenever there is at least one bound DLS user and no active DLS users (whether bound or not). This allows the (one) active MAC client to have its transmitted packets looped back to all of the inactive MAC clients, but not to itself. 3. DLS will (attempt to) claim active client status with the MAC module whenever there is at least one active DLS user, whether bound or not. This means that it is possible for an unbound DLS user to occupy the special "active" position without actually being able to send, which is somewhat undesirable but there shouldn't be any reason for any DLS user to invoke this odd situation (DLD, for example, will never do this for more than an instant). Reference ========= [internal] Article: DLPI Improved Loopback Handling, by Mike Ditto ... The CR for this issue 6402493 DLPI provider loopback behavior should be improved Discussion on OpenSolaris.org http://www.opensolaris.org/jive/message.jspa?messageID=28615 [internal] Bridging project wiki ... Bridging on OpenSolaris http://www.opensolaris.org/os/project/ethbridge/ [internal] Prototype workspace ... _______________________________________________ networking-discuss mailing list [email protected]
