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.
