On Mon, 2006-03-20 at 21:16, Frank DiMambro wrote: > Hi Thomas > How it's supposed to be implemented is only streams that say > they are promiscuous get a copy. Yes. Sorry. I assumed we talked about promiscous mode. Mike Ditto's proposal is very comprehensive about the cases. Thanks, -Thomas > > Thomas Bastian - Sun Microsystems wrote: > > >Hi Frank, > >Thanks for the tip. Will check that out. > > > > > You may also want to check out the hardware specs for defintion > of Promiscuous, In my experience largely with Ethernet it has > always meant loopback of sent packets. > > >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? > > > If the stream says it's promiscuous then yes. This does not mean you > spray it to other streams, who are not marked as promiscuous. > > >I mean other streams in the system should receive > >a copy for sure, but not the originating stream? > > > > > No that's not the way is's supposed to work. Only streams that say > they are promiscuous should see the sent packets. It's this > functionality that lets you snoop a ip stream, and see that's going > in and out of ip. > > cheers > Frank > > >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]
