Hi Frank, Thanks for the tip. Will check that out. I agree that promiscuous also means to see packets that are sent out. But do you think it makes sense for a stream to receive a copy of its own packets sent out? I mean other streams in the system should receive a copy for sure, but not the originating stream? Thanks, -Thomas
On Mon, 2006-03-20 at 18:36, Frank DiMambro wrote: > Hi Thomas > You may also want to check the IEEE specs for the definition of > Promiscuous. The DLPI spec follows that. It's always been well > understood that 'Promiscuous' means every packet that hits the > physical layer, which includes packets sent out. The Software > loopback compensates for hardware that cannot do loopback, > but in essence it's to achieve the same result which is to see the > packets you sent out. Not sure this is a bug.... > > cheers > Frank > > Thomas Bastian - Sun Microsystems wrote: > > Just checked the DLPI spec for this topic. There is no requirement that > > a DLPI user gets its own packets looped back. So I guess we can safely > > treat this proposal as a bug. I will file a bug instead. > > Thanks, > > -Thomas > > > > On Mon, 2006-03-20 at 15:54, Thomas Bastian - Sun Microsystems wrote: > > > >> On Mon, 2006-03-20 at 15:33, James Carlson wrote: > >> > >>> Thomas Bastian - Sun Microsystems writes: > >>> > >>>>> What is the motivation for having two separate ways to set this? Why > >>>>> not have this new feature _only_ at the stream level? Are there usage > >>>>> models that correspond to both levels? The only one I see is > >>>>> DLT_LINUX_SLL, which seems to imply stream-level (though I'm not > >>>>> positive). > >>>>> > >>>> You are right. From a feature point of view the streams level would be > >>>> enough. Were I can see the benefit with the device level setting is that > >>>> we could avoid using mac_txloop() and therefore use the fast regular way > >>>> to get packets out (since we don't need a loop copy). But maybe the > >>>> speed benefit will be negligible after all. I have not made any > >>>> measurements for this. > >>>> > >>> I'd rather not expose the details of performance optimizations to > >>> uninvolved parties. They change far too often for this to be a good > >>> way to entangle the design. > >>> > >>> In other words, if there is any performance to be gained here, then > >>> the system should detect the special cases itself and set up the right > >>> behavior. Thus, if all of the streams either are non-promiscuous or > >>> if all of the promiscuous streams elect not to have local copies, then > >>> use the "fast" version. Otherwise, don't. > >>> > >>> (I really think the complexity involved with the pointer management > >>> dwarfs any possible gain from avoiding a single, well-designed flag > >>> check, and that the current design needs a rethink. But that's > >>> probably a different topic.) > >>> > >>> > >>>>> c. All open streams are switched to loop-on mode, and, because this > >>>>> takes precedence over the stream level control, subsequent use > >>>>> of DL_PROMLOOP_STR_OFF does nothing. > >>>>> > >>>> Its partly c.) I guess my proposal is not clear enough on this point. > >>>> Let me try to rephrase it. The DL_PROMLOOP_DEV_ON enables loopback mode > >>>> for the device, hence this setting is a pre-requisite for any stream to > >>>> see loopback packets at all from this device. If the DL_PROMLOOP_DEV > >>>> > >>> So ... this means there are really *three* states for the device level > >>> flag. It can be "forced on," "forced off," or "unset." There's no > >>> way to set that third mode with the new interface; the system starts > >>> up that way by default, but if anyone ever sets either of the other > >>> modes, it's a one-way trap door. You can't get back (except, perhaps, > >>> by unplumbing). > >>> > >>> That's a bit confusing, and I'm not sure I see why it's necessary. > >>> > >>> > >>>>> Does the proposal distinguish between looped-back traffic that > >>>>> originates with the stream user and traffic that originates with other > >>>>> streams? > >>>>> > >>>> Not in the POC currently. This is an important point on which I am still > >>>> unclear what the best approach would be. > >>>> > >>> It seems to me that it's really key to the problem. > >>> > >>> > >>>>> So, why not dispense with the knob entirely, and simply change the > >>>>> definition? Fix it so that promiscuous mode in DLPI does not itself > >>>>> loop back traffic to the same stream that generated it. I.e., only > >>>>> cases that cause loopback in the non-promiscuous behavior would loop > >>>>> back. This would simplify the driver changes, the documentation, the > >>>>> user interface, and the porting work required for applications. > >>>>> > >>>> I am not sure this is possible. Agreed that it would be the simplest > >>>> approach. I am not 100% positive but I think it is a well known > >>>> "feature" of DLPI that in promiscuous mode, packets are looped back. I > >>>> think this is the way it works on other systems (HP-UX, AIX, etc...) as > >>>> well (to be confirmed). If there is such a requirement for DLPI in > >>>> promiscuous mode, then we could not go down that route because we would > >>>> break compatibility I suppose. > >>>> > >>> I don't think that's the important question. I think this one is: > >>> > >>> > >>>>> Is there any case in which seeing the unicast traffic that you > >>>>> generated on your own promiscuous-mode stream is not a bug? > >>>>> > >>> It seems to me that promiscuous DLPI streams are relatively rare. In > >>> most (nearly all) cases, they're used for snoop/ethereal/libpcap, and > >>> those applications are read-only. > >>> > >>> The narrow case where the current DLPI semantics break down for some > >>> users is in the rarest of the rare: a promiscuous DLPI stream user who > >>> also transmits unicast packets. It seems fair to me to ask whether > >>> the current behavior is something that anyone could ever have relied > >>> on in any useful way, or whether it's merely a bug. In other words, > >>> do those applications _ever_ process those packets beyond just > >>> detecting and discarding them? > >>> > >>> I'd be strongly tempted to treat this as a bug, and change it in a > >>> Minor release along with a suitable release note. The only "tunable" > >>> I might provide would be an intentionally undocumented variable (that > >>> could be tweaked with /etc/system) to reenable the old behavior, just > >>> in case there's some unknown application somewhere that's actually > >>> harmed by the new behavior. > >>> > >>> The chance of that, though, seems quite remote to me, and the risk > >>> looks reasonable for a Minor release, especially in comparison to the > >>> complexity and risk of potentially modifying multiple (and largely > >>> unknown!) DLPI applications to take advantage of this new feature, > >>> and adding lasting complexity to Solaris for the mode switch > >>> implementation that could really never be removed. > >>> > >>> (For a patch or micro release binding, the default may need to be the > >>> other way.) > >>> > >>> But, yes, I agree that verifying against the standards (which seem to > >>> say nothing about the issue) and against other implementations is a > >>> good idea. I don't think, though, that if other implementations have > >>> bugs, this necessarily means we must as well. > >>> > >> Well to be honest I am fine with treating this as a bug because I fully > >> agree with you that the current promiscous mode behaviour does not make > >> sense at all. I am happy to hear other people's opinion about this. And > >> in the meantime, I will see if I find anything in the specs about what > >> (if any) the "expected" behaviour should be. > >> > >> Thanks, > >> -Thomas > >> > >> > >>> -- > >>> James Carlson, KISS Network <[EMAIL PROTECTED]> > >>> Sun Microsystems / 1 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] > >> > > > > _______________________________________________ > > networking-discuss mailing list > > [email protected] > > > _______________________________________________ networking-discuss mailing list [email protected]
