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]
