Cathy Zhou writes:
>
> >I'm not sure what the reference to PPPoE "devices" in section 3.1.1
> >means.
> >
> I thought that when sppptun plumbs an interface, it gives the interface
> the name in the form of <devname>.pppoe(d)?
Actually more like "<devname><instance>:pppoe(d)" -- so, for "hme0,"
you'd have "hme0:pppoe" and "hme0:pppoed." PPPoE is weird in many
ways; one of them is that it uses two Ethertypes.
> In the future, sppptun will be able to plumb the sppptun device using
> its link name. But the PPPoE interface name will still in the form of
> <linkname>.pppoe(d), and that will not be changed by the vanity naming
> component.
OK, then it sounds like vanity naming *IS* supported for PPPoE, and
this text can just be removed.
With vanity naming, I expect:
- The user can rename "hme0" to "foobar0".
- The user can then do "sppptun plumb pppoed foobar0" and get
"foobar0:pppoed".
As long as that works, we're in sync, and everything's fine. There's
no reason to allow a user to rename "foobar0:pppoed" into "blah" -- in
fact, that'd rather severely break the existing design and would have
no possible administrative use.
> Seb already has this change in his binary compatibility mac_t wad. The
> format for MAC names will be <drvname>N.
Cool!
> >I do not think that changing "create-aggr -d" to "create-aggr -l" is
> >necessarily warranted. I recognize that you're trying to enforce the
[...]
> I discussed this within our I-team. We think that as "-l" is used in
> other sub-commands to represent a link, (for example, create-vlan), it's
> very important to be consistent.
I'm a bit less convinced, but I suppose I also don't care much. As
long as "-d" is either not being removed or is following the standard
EOF process, I can live with it. It feels gratuitous, but I suppose
"dladm" itself might still be young enough to consider it to be still
twistable.
> >Why is the subcommand named "discard-phys"? It looks to me like this
> >discards the configuration of a _link_, not a physical device,
> >
> By our definition, "phys" is a type of link, just like other link types
> such as "vlan" and "aggr".
OK ... but it still seems odd to me, because what's being discarded is
the link configuration. From the user's point of view, the "phys"
part is long gone.
> >though
> >it is the physical device that was removed. (Maybe I'm just confused
> >about the distinction between the verbs "discard" and "delete," as
> >both seem to be used for the same thing.)
> >
> >
> >
> Yes, "discard" roughly equals to "delete", except that unlike
> "delete-aggr" or "delete-vlan", "discard-phys" will not only delete the
> physical link itself but also remove the specific physical link from all
> associated link configurations (for example, delete all associated
> VLANs).
and ... ?
I happen to like aggressive delete commands ("delete this thing and
the horse it rode in on") rather than wimpy ones that demand the user
delete all the references first ("error: you still haven't typed those
307 other commands you need to run first"), but I see that choice as
essentially orthogonal to the choice of keyword here.
Instead, if a distinction must be made, I'd rather see it be made as
an option. E.g., use "-f" to mean "force." So, if the user does
"delete-phys" and there are still references, it fails. If the user
does "delete-phys -f", the references are torched as well.
Using "discard" to mean "delete with extreme prejudice" seems harder
to remember and explain. I'm not sure I can come up with another case
in which that design pattern was used.
> If you think that "delete-phys" itself is clear enough to imply
> that difference, sure, we will think about that. In fact, we are still
> working with UI experts of the UI design, what we proposed here might
> change later.
Just for usability (if nothing else), I think it'd be nice to have
"delete-<X>" be the pattern everywhere.
> Or, if what you are suggesting is something like "delete-link", which
> deletes (discard) links based on the type of the link the administrator
> specifies, and replaces delete-aggr, delete-vlan and discard-phys, I may
> not agree. It seems more natural to me to have delete-aggr if we have
> create-aggr to create the aggregation.
That does point out a bit of strangeness in the existing command set,
but I sort of doubt that it's fixable now as S10 has left the barn.
It would have been nicer to have a simple "create" command with some
sort of option to specify what type of link you want to create, and
then have a single "delete" command that doesn't *need* to know a
thing about type.
As it is, this current design means that the user can't just say
"please delete this thing." The user must reassert the "type" of the
thing in order to delete it, even though the "type" may well be
irrelevant to the user, and the system certainly knows full well what
the type is when given just the name. There isn't a separate name
space for aggregations versus VLANs or physical links.
Thus, "delete-aggr somevlan0" will fail and say something like "you
gave me a VLAN, but all I want to do is kill aggregations; type your
command again in frustration." Sort of like the "we cannot complete
your call as dialed; please dial '1' for toll calls" error message.
I suppose I can live with separate "delete-<X>" commands. It'd sort
of be nice, though, to consider having a single "delete" that can
eventually take over.
> >Of all of the changes in the document, I think 3.1.6 is on the
> >shakiest ground. It doesn't make sense to me to assert here that
[...]
> I agree it is a big risk. But as long as link names can be different
> from device names, applications will *not* be able to get the correct
> link names directly using libdevinfo. I think we have to accept this and
> warn users that vanity naming may cause problems for applications using
> libdevinfo. We will certainly update ON gate to use the new interfaces
> to enumelate links. For third-party applications, we can also work with
> them to update their code.
I think this needs a big readme entry, blogs, comp.unix.solaris
postings, and any other advertisements we can think of.
It also needs to be pointed out as soon as possible in ARC review. I
wouldn't be surprised to find that you run into resistance on this (it
seems to me to break the model of that interface), so getting it over
with early -- before more design and coding uses it -- would be good.
> >Why does softmac attempt to coalesce messages from the lower stream?
> >This doesn't sound like a win to to me -- if coalescing is to be done
> >at all, shouldn't it be done at the lowest possible level? Has any
> >measurement been done to see the positive (presumably lower CPU cycle
> >usage) and negative (latency and jitter) impact of this?
> >
> >
> >
> How can it be done even lower than the softmac if we cannot change the
> underlying driver?
You're planning to change those drivers anyway to support VLAN MAC
overhead properly, right? That's your big chance, _if_ it's something
necessary and valuable to do. I'm somewhat less sure that it is.
Frankly, I'd rather see the effort expended on porting those older
drivers over to Nemo than tweaking their performance.
> If what you are suggesting is to evaluate the
> performance impact first, sure we will do that.
Yes, exactly.
> >What about wificonfig updates to support vanity link names? Any
> >changes required here?
> >
> AFAIK, the current plan is to replace wificonfig with dladm.
When does the wificonfig->dladm transition occur? Just because of the
potential for great confusion, I don't think this (vanity naming)
design should ship before those are somehow in sync. Either
wificonfig has to work right with vanity names (would it?) or the
migration has to happen.
--
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]
