Thanks Jim for looking at this. On Mon, 2006-03-20 at 13:41, James Carlson wrote: > Thomas Bastian writes: > > We consider two major modes: one that applies at the device level > > and one that applies at the stream level: > > 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. > > How do these two mechanisms interact with each other? You say that > the device level "takes precedence," but what does that really mean? > If I set DL_PROMLOOP_DEV_ON at the device level, does this mean: > > a. Current open streams are unaffected, but newly-opened ones will > default to having the flag turned "on." > > b. All open streams at the point in time in which I send > DL_PROMLOOP_DEV_ON will be switched into loop-on mode, even > those that had previously set DL_PROMLOOP_STR_OFF. > > 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 setting is off for a device, no stream will see packet loopback regardless of its own DL_PROMLOOP_STR setting. DL_PROMLOOP_DEV has system/device wide effect. Therefore if one stream issues a DL_PROMLOOP_DEV_OFF to a device, no other stream in the system will see loopback packets from this device. The DL_PROMLOOP_STR setting is a per stream setting and will affect how a particular stream is dealing with loopback packets. If the setting is ON loopback packets are permitted for the stream (pre-requisite being that nobody has disabled loopback at the device level). If the setting is OFF, then loopback packets are dropped and not passed up-stream. So the precedence is really such as if the device has the loopback capability switched off, no stream will receive any loopback packet (because they are not generated) and in the regular case where the loopback capability of the device is on, each stream can decide whether to receive its own loopback packets.
> > 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 snoop(1M) relies on being able to catch packets > transmitted by all streams, but that since it never sends any packets, > it doesn't care about self-originated traffic. Further, raw DLPI > users simply never (as a matter of design) want to see their own > traffic looped back. Agreed. > > 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. Thanks, -Thomas > > Is there any case in which seeing the unicast traffic that you > generated on your own promiscuous-mode stream is not a bug? > > -- > 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]
