|
Replies:
62
-
Last Post:
Jan 13, 2006 7:42 PM
by: meem
|
|
|
Posts:
766
From:
US
Registered:
6/14/05
|
|
|
|
Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 8, 2005 10:21 AM
|
|
OpenSolaris networking community,
As described in several other threads, Clearview is a project which
aims to rationalize, unify, and enhance the way network interfaces
are handled in Solaris. The four components of Clearview are:
IPMP Rearchitecture
IP Tunneling Device Driver
IP-Level Observability Devices
Vanity Naming and Nemo Unification
The final document, covering Vanity Naming and Nemo Unification, is
now available at:
http://opensolaris.org/os/community/networking/uv-design.pdf
This work aims to allow:
* _All_ network devices to be administered at the link layer
through a single command (dladm). In the process, this lays the
groundwork for all future link layer administration.
* _All_ Ethernet devices to have 802.1q VLAN's and 802.3ad link
aggregations established over them.
* _All_ network devices to be given administratively-chosen names.
This not only provides administrative convenience, but also allows
the networking configuration of the machine to be decoupled from
its underlying hardware.
The timer for comments is set at two weeks (December 23). Thank you
very much for any comments.
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
Posts:
215
From:
Scotland
Registered:
9/15/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 8, 2005 12:54 PM
in response to: yun
|
|
Hi Cathy,
On Fri, 9 Dec 2005, Cathy Zhou wrote:
> The timer for comments is set at two weeks (December 23). Thank you
> very much for any comments.
6.1.4 - DL_CAPAB_UNBOUNDED_PKT
Might it be an idea to instead have a capability to explicitly state the
maximum packet size the hardware can handle? DL_CAPAB_PKT_MAX_SIZE or
somesuch?
Legacy drivers not supporting the driver can then simply be assumed to
have a max of 1500. Further, it would also make life easier for
administrators trying to deploy jumbo frames (not all hardware supports
same sizes of jumbo frames i think), if they could see the result of
this capability from dladm.
Then, additionally, rather than providing a "force" flag for vlan
creation, it might be better to instead just allow administrators to
specify the PKT_MAX_SIZE manually for devices lacking the capability.
The implications of what they've done and why it might cause problems
might be clearer, plus it avoids encouraging admins to 'force' things.
regards,
--paulj
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
766
From:
US
Registered:
6/14/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 12, 2005 1:49 AM
in response to: paulj
|
|
Paul,
Thank you for your comments, see inline:
> 6.1.4 - DL_CAPAB_UNBOUNDED_PKT
>
> Might it be an idea to instead have a capability to explicitly state
> the maximum packet size the hardware can handle? DL_CAPAB_PKT_MAX_SIZE
> or somesuch?
Good suggestion. I will incorporate this suggestion into my document.
> Legacy drivers not supporting the driver can then simply be assumed to
> have a max of 1500. Further, it would also make life easier for
> administrators trying to deploy jumbo frames (not all hardware
> supports same sizes of jumbo frames i think), if they could see the
> result of this capability from dladm.
Instead of showing the hardware attribute such as max_pkt_size directly,
I think it might be better to display the interface's capabilities (For
example, the jumbo frames capability.)
>
> Then, additionally, rather than providing a "force" flag for vlan
> creation, it might be better to instead just allow administrators to
> specify the PKT_MAX_SIZE manually for devices lacking the capability.
> The implications of what they've done and why it might cause problems
> might be clearer, plus it avoids encouraging admins to 'force' things.
I am not sure I understand this. Are you suggesting that "max_pkt_size"
is configurable? (which I don't think is possible for legacy drivers?)
The administrator might be able to specify the MTU, and we can check the
PKT_MAX_SIZE with the MTU and see whether the VLAN can be created. But
as is described in the document, specifying a small MTU can only work
around the issue on the transmit-side.
Thanks again
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
215
From:
Scotland
Registered:
9/15/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 12, 2005 3:38 AM
in response to: yun
|
|
On Mon, 12 Dec 2005, Cathy Zhou wrote:
>> Legacy drivers not supporting the driver can then simply be assumed
>> to have a max of 1500. Further, it would also make life easier for
>> administrators trying to deploy jumbo frames (not all hardware
>> supports same sizes of jumbo frames i think), if they could see the
>> result of this capability from dladm.
> Instead of showing the hardware attribute such as max_pkt_size directly, I
> think it might be better to display the interface's capabilities (For
> example, the jumbo frames capability.)
Sure. But if you explicitely know the maximum size, might as well
display it to avoid confusion, e.g.:
- is there a standard 'jumbo frame' size that all hardware agrees on?
(Jumbo could mean different things to different hardware, and I
strongly suspect this is the case for older jumbo capable hardware)
- even if so, maybe there is hardware capable of greater than jumbo
size. (Now or in future).
I.e. I think dealing in explicit sizes possibly is more future-proof
than a capability. E.g. What about Jumbo + VLAN? Is that Jumbo size or
something else? Or Jumbo + VLAN + Some-future-new-802-additional-header?
;)
> I am not sure I understand this. Are you suggesting that
> "max_pkt_size" is configurable? (which I don't think is possible for
> legacy drivers?)
Yes. Only for hardware whose driver did not support the capability and
did not supply a value. I.e. you could 'force' the maximum packet size
for legacy drivers and override a default of 1500. (If possible).
If the administrator must intervene, then making them intervene once to
manually specify a "maximum frame size this hardware handles" is
possibly clearer than a more vague "force vlan creation" flag.
> The administrator might be able to specify the MTU, and we can check
> the PKT_MAX_SIZE with the MTU and see whether the VLAN can be created.
> But as is described in the document, specifying a small MTU can only
> work around the issue on the transmit-side.
ACK.
--paulj
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
766
From:
US
Registered:
6/14/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 15, 2005 8:45 PM
in response to: paulj
|
|
> Sure. But if you explicitely know the maximum size, might as well
> display it to avoid confusion, e.g.:
>
> - is there a standard 'jumbo frame' size that all hardware agrees on?
> (Jumbo could mean different things to different hardware, and I
> strongly suspect this is the case for older jumbo capable hardware)
>
> - even if so, maybe there is hardware capable of greater than jumbo
> size. (Now or in future).
>
> I.e. I think dealing in explicit sizes possibly is more future-proof
> than a capability. E.g. What about Jumbo + VLAN? Is that Jumbo size or
> something else? Or Jumbo + VLAN +
> Some-future-new-802-additional-header? ;)
Okay. Let me summarize what we agreed on so far:
Drivers which announce the DL_CAPAB_UNBOUNDED_PKT capability will send
the capability notificaiton with the maximam size of the hardware can
handle to the DLS consumer. If the DL_CAPAB_UNBOUNDED_PKT capability is
not supported, the DLS consumer will assume that the underlying hardware
can only handle packet size (mtu and mru) of 1500.
Then the size announced by the driver can be used to determine whether a
VLAN can be safely created, and also whether the underlying driver can
handle the jumbo frames.
> Yes. Only for hardware whose driver did not support the capability and
> did not supply a value. I.e. you could 'force' the maximum packet size
> for legacy drivers and override a default of 1500. (If possible).
Sorry that I still didn't get it. Assume a legacy driver which has below
check (both on the transmit-side and on the receive-side), how can we
override the default of 1500 without changing its code? If we cannot,
does that mean that we simply will not create VLAN over such NICs?
if (pkt_size > 1514)
goto drop;
The best thing we can to is to configure a smaller MTU, which only
relieves the transmit-side check.
Thanks
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
215
From:
Scotland
Registered:
9/15/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 15, 2005 9:48 PM
in response to: yun
|
|
On Fri, 16 Dec 2005, Cathy Zhou wrote:
> Okay. Let me summarize what we agreed on so far:
>
> Drivers which announce the DL_CAPAB_UNBOUNDED_PKT capability will send the
> capability notificaiton with the maximam size of the hardware can handle to
> the DLS consumer. If the DL_CAPAB_UNBOUNDED_PKT capability is not supported,
> the DLS consumer will assume that the underlying hardware can only handle
> packet size (mtu and mru) of 1500.
>
> Then the size announced by the driver can be used to determine whether a VLAN
> can be safely created, and also whether the underlying driver can handle the
> jumbo frames.
And exactly what size of jumbo frames.
ACK, sounds good!
> Sorry that I still didn't get it. Assume a legacy driver which has
> below check (both on the transmit-side and on the receive-side), how
> can we override the default of 1500 without changing its code?
Nope. As in your document, obviously we simply don't know what the
hardware is capable of, and 1500 is the safe default unless the
administrator knows better.
> If we cannot, does that mean that we simply will not create VLAN over
> such NICs?
Well, you had proposed allowing the administrator to force VLAN creation
in such cases, if they knew better. I'm saying you could instead let
them manually specify the size which the legacy driver /didn't/ provide.
Seems clearer.
> if (pkt_size > 1514)
> goto drop;
>
> The best thing we can to is to configure a smaller MTU, which only relieves
> the transmit-side check.
Well, the driver could have
if (pkg_size > 9600)
we just wouldn't know for legacy drivers;). The administrator /might/
know though for such drivers. I.e. I'm just suggesting some kind of
command be provided to specify the hardware max-packet size for such
cases:
dladm set-link -M 9600
for example. And 'show-link' might show what the max-packet size is, if
the driver reported it.
It's better than using "the force". ;)
regards,
--paulj
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
215
From:
Scotland
Registered:
9/15/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 15, 2005 9:55 PM
in response to: paulj
|
|
On Fri, 16 Dec 2005, Paul Jakma wrote:
>> check (both on the transmit-side and on the receive-side), how can we
>> override the default of 1500 without changing its code?
>
> Nope.
^^^^
Oops, that should of course have read "We can't".
--paulj
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
766
From:
US
Registered:
6/14/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 15, 2005 10:07 PM
in response to: paulj
|
|
Paul Jakma wrote:
> As in your document, obviously we simply don't know what the hardware
> is capable of, and 1500 is the safe default unless the administrator
> knows better.
Okay.
> The administrator /might/ know though for such drivers. I.e. I'm just
> suggesting some kind of command be provided to specify the hardware
> max-packet size for such cases:
>
> dladm set-link -M 9600
... and if the administrator wants to create a VLAN over a legacy
device, he must issue "dladm set-link -M 1518 (or even bigger)" before
creating the VLAN? But I would expect such command will fail because the
legacy device doesn't have the DL_CAPAB_UNBOUNDED_PKT capability and it
really is not able to handle the packet size of 1518.
Further, what exactly the "dladm set-link" subcommand means for drivers
explcitly announced their "max_size"? Can it succeed or not?
I still don't see why it is prefered than the "-f" option.
Thanks
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
215
From:
Scotland
Registered:
9/15/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 16, 2005 6:18 AM
in response to: yun
|
|
On Fri, 16 Dec 2005, Cathy Zhou wrote:
> ... and if the administrator wants to create a VLAN over a legacy
> device, he must issue "dladm set-link -M 1518 (or even bigger)" before
> creating the VLAN?
Right.
> But I would expect such command will fail because the legacy device
> doesn't have the DL_CAPAB_UNBOUNDED_PKT capability and it really is
> not able to handle the packet size of 1518.
Well, we don't know what the legacy device/driver is capable of. Maybe
it can handle large frames just fine. We don't know ;).
> Further, what exactly the "dladm set-link" subcommand means for drivers
> explcitly announced their "max_size"? Can it succeed or not?
I don't think it should, if the driver provides a size it should be
correct.
> I still don't see why it is prefered than the "-f" option.
Ah.. well cause "Use the force" type things become 'lore' amongst
admins, handed down from one to the next "Hmm, no idea why you're having
problems, but try forcing it". It's opaque as to what it does and why it
is needed. Allowing manual setting of max-packet for legacy drivers
makes it far more obvious what is going on.
If some young Solaris admin sets up VLANs and then at lunch asks the old
and battle-scarred network administrator "I setup VLANs but had to
provide a max-packet-size for it to work, any idea what that's about?",
there's a decent chance the network admin could enlighten him. (OTOH, if
the Solaris admin asks "but had to -force it for it to work", the
network admin won't be able to enlighten him).
Maybe I have an irrational hatred of force flags, but I simply can't
stand them. ;)
> Thanks
> - Cathy
--paulj
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
766
From:
US
Registered:
6/14/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 19, 2005 1:34 AM
in response to: paulj
|
|
>> But I would expect such command will fail because the legacy device
>> doesn't have the DL_CAPAB_UNBOUNDED_PKT capability and it really is
>> not able to handle the packet size of 1518.
>
>
> Well, we don't know what the legacy device/driver is capable of. Maybe
> it can handle large frames just fine. We don't know ;).
Yes, we don't know, and we cannot just assume that it can handle bigger
size and return success.
> Ah.. well cause "Use the force" type things become 'lore' amongst
> admins, handed down from one to the next "Hmm, no idea why you're
> having problems, but try forcing it". It's opaque as to what it does
> and why it is needed. Allowing manual setting of max-packet for legacy
> drivers makes it far more obvious what is going on.
>
> If some young Solaris admin sets up VLANs and then at lunch asks the
> old and battle-scarred network administrator "I setup VLANs but had to
> provide a max-packet-size for it to work, any idea what that's
> about?", there's a decent chance the network admin could enlighten
> him. (OTOH, if the Solaris admin asks "but had to -force it for it to
> work", the network admin won't be able to enlighten him).
>
> Maybe I have an irrational hatred of force flags, but I simply can't
> stand them. ;)
Understood. If you have better solution, let us know.
Thanks
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 15, 2005 10:20 PM
in response to: paulj
|
|
> dladm set-link -M 9600
>
> for example. And 'show-link' might show what the max-packet size is, if
> the driver reported it.
This sounds like the kind of property that could end up in the upcoming
dladm set-prop interface that I plan to add as part of integrating wifi
support into dladm. Similarly, these properties will be able to be
viewed through show-prop (or maybe get-prop, depending on what the UIRB
says) -- though if we think enough people will be interested, show-link
could also display it.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
766
From:
US
Registered:
6/14/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 15, 2005 10:24 PM
in response to: meem
|
|
Peter Memishian wrote:
> > dladm set-link -M 9600
> >
> > for example. And 'show-link' might show what the max-packet size is, if
> > the driver reported it.
>
>This sounds like the kind of property that could end up in the upcoming
>dladm set-prop interface that I plan to add as part of integrating wifi
>support into dladm.
>
Yes. But for this particular case, I would think that "max-size" is a
READ-ONLY property.
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 15, 2005 10:30 PM
in response to: yun
|
|
> Yes. But for this particular case, I would think that "max-size" is a
> READ-ONLY property.
I'd think so, too.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 16, 2005 6:46 AM
in response to: meem
|
|
Peter Memishian writes:
>
> > dladm set-link -M 9600
> >
> > for example. And 'show-link' might show what the max-packet size is, if
> > the driver reported it.
>
> This sounds like the kind of property that could end up in the upcoming
> dladm set-prop interface that I plan to add as part of integrating wifi
> support into dladm.
Suppose it becomes a variable computed by someone else -- what happens
then?
For example, how would we evolve this interface if we added LLDP to
the system. Would the user have to set "dladm set-prop -p mtu=auto
x0"?
> Similarly, these properties will be able to be
> viewed through show-prop (or maybe get-prop, depending on what the UIRB
> says) -- though if we think enough people will be interested, show-link
> could also display it.
Just a nit, but don't count on UIRB here. They're focusing on GUIs.
You'll need to deal with the ARC. ;-}
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 12, 2006 11:19 PM
in response to: carlsonj
|
|
> > > dladm set-link -M 9600
> > >
> > > for example. And 'show-link' might show what the max-packet size is, if
> > > the driver reported it.
> >
> > This sounds like the kind of property that could end up in the upcoming
> > dladm set-prop interface that I plan to add as part of integrating wifi
> > support into dladm.
>
> Suppose it becomes a variable computed by someone else -- what happens
> then?
>
> For example, how would we evolve this interface if we added LLDP to
> the system. Would the user have to set "dladm set-prop -p mtu=auto
> x0"?
I would think that the model would be roughly similar to something like
DHCP. For example, if the user uses LLDP, then they would expect that a
bunch of stuff such as MTU would be automatically set by the system.
However, if they subsequently wanted to override some values, they could.
I would expect LLDP to be triggered using a less obtuse mechanism than
tweaking properties in dladm, and thus I'm not crazy about having
something like "-p mtu=auto". But maybe I could be convinced otherwise.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 13, 2006 9:36 AM
in response to: meem
|
|
Peter Memishian writes:
> I would think that the model would be roughly similar to something like
> DHCP. For example, if the user uses LLDP, then they would expect that a
> bunch of stuff such as MTU would be automatically set by the system.
> However, if they subsequently wanted to override some values, they could.
> I would expect LLDP to be triggered using a less obtuse mechanism than
> tweaking properties in dladm, and thus I'm not crazy about having
> something like "-p mtu=auto". But maybe I could be convinced otherwise.
OK. As long as the model isn't "dladm overrides," I think we're in
sync.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 13, 2006 10:40 AM
in response to: carlsonj
|
|
> > I would think that the model would be roughly similar to something like
> > DHCP. For example, if the user uses LLDP, then they would expect that a
> > bunch of stuff such as MTU would be automatically set by the system.
> > However, if they subsequently wanted to override some values, they could.
> > I would expect LLDP to be triggered using a less obtuse mechanism than
> > tweaking properties in dladm, and thus I'm not crazy about having
> > something like "-p mtu=auto". But maybe I could be convinced otherwise.
>
> OK. As long as the model isn't "dladm overrides," I think we're in
> sync.
Overrides in what way? After auto-configuration has occured, I'd think it
reasonable to allow the user to use dladm to change the auto-configured
value using dladm set-prop. However, I would expect a request to perform
auto-configuration to override any previously configured properties.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 13, 2006 11:04 AM
in response to: meem
|
|
Peter Memishian writes:
> > OK. As long as the model isn't "dladm overrides," I think we're in
> > sync.
>
> Overrides in what way? After auto-configuration has occured, I'd think it
> reasonable to allow the user to use dladm to change the auto-configured
> value using dladm set-prop. However, I would expect a request to perform
> auto-configuration to override any previously configured properties.
That latter bit is the important part. It wasn't clear to me before
whether you meant that we'd nail that value to the wall or if learned
values could be preferred.
The behavior is always a bit ambiguous when there are both static
configuration and automatic configuration mechanisms.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 13, 2006 11:12 AM
in response to: carlsonj
|
|
> > Overrides in what way? After auto-configuration has occured, I'd think it
> > reasonable to allow the user to use dladm to change the auto-configured
> > value using dladm set-prop. However, I would expect a request to perform
> > auto-configuration to override any previously configured properties.
>
> That latter bit is the important part. It wasn't clear to me before
> whether you meant that we'd nail that value to the wall or if learned
> values could be preferred.
>
> The behavior is always a bit ambiguous when there are both static
> configuration and automatic configuration mechanisms.
Indeed -- and yes, I think we're in sync on the way it should behave.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 16, 2005 12:43 AM
in response to: yun
|
|
Cathy Zhou wrote:
> Drivers which announce the DL_CAPAB_UNBOUNDED_PKT capability will send
> the capability notificaiton with the maximam size of the hardware can
> handle to the DLS consumer. If the DL_CAPAB_UNBOUNDED_PKT capability is
> not supported, the DLS consumer will assume that the underlying hardware
> can only handle packet size (mtu and mru) of 1500.
Cathy,
Why is the unbounded packet size information handled as a DL capability
rather than a simple datum accessible via M_IOCTL or the like? Can you
give some hints on when an interposed STREAMS module should participate
in the negotiation of this capability, or block its use (by ignoring
it)?
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
429
From:
GB
Registered:
6/15/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 16, 2005 1:28 AM
in response to: mditto
|
|
On 12/16/05, Mike Ditto <Michael dot Ditto at sun dot com> wrote:
>
> Why is the unbounded packet size information handled as a DL capability
> rather than a simple datum accessible via M_IOCTL or the like? Can you
> give some hints on when an interposed STREAMS module should participate
> in the negotiation of this capability, or block its use (by ignoring
> it)?
Yes, this confuses me too. As I understand it from the doc. this
capability is only used by softmac to try to figure out what the
'real' max frame size of a device with a legacy driver is.
Since, to implement the capability, the legacy driver has to be
changed then why not simply have it return its 'real' max frame size
in the DL_INFO_ACK?
Paul
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 16, 2005 1:36 AM
in response to: pdurrant
|
|
Paul Durrant wrote:
> Since, to implement the capability, the legacy driver has to be
> changed then why not simply have it return its 'real' max frame size
> in the DL_INFO_ACK?
I recall this idea being discussed long ago for some other project. I
think this would be a problem because IP will start sending illegal
(oversized) frames on these less restrictive NICs. So we can't report the
real limit in DL_INFO_ACK, it has to be a new property of some kind; I
just don't think it's appropriate as a negotiated DL capability.
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
429
From:
GB
Registered:
6/15/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 16, 2005 2:16 AM
in response to: mditto
|
|
On 12/16/05, Mike Ditto <Michael dot Ditto at sun dot com> wrote:
>
> I recall this idea being discussed long ago for some other project. I
> think this would be a problem because IP will start sending illegal
> (oversized) frames on these less restrictive NICs. So we can't report the
> real limit in DL_INFO_ACK, it has to be a new property of some kind; I
> just don't think it's appropriate as a negotiated DL capability.
>
Yes, I was in the process of filing a PSARC case for such an idea and
discussed it at length with Randy Fishel (and maybe you too). I know
IP uses the value in the DL_INFO_ACK as the MTU at the moment but it
does not have to be this way. It would be perfectly feasible to have
IP apply a limit based on media type rather than what the NIC says it
*can* do.
Thinking back, there is another issue though. The driver needs to know
what MTU the stack is using at any given time. E.g. say a driver can
handle 8k packets. It would be seriously bad for it to allocate 8k
buffers everywhere if the stack is only ever going to pass 1500 byte
packets around. So, I think the eventual plan was to report the normal
1500 byte MTU in the DL_INFO_ACK but then have a new DL_SET_MTU
primitive which is sent by IP to test whether an MTU greater than 1500
can be used (when an admin types ifconfig XXX mtu YYY) on the command
line. This gives the driver a chance to either say 'no' (specifically
or by implication if the primitive is unrecognized) or re-allocate any
necessary buffers and say 'yes'.
Paul
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 16, 2005 2:29 AM
in response to: pdurrant
|
|
Paul Durrant wrote:
> Thinking back, there is another issue though. The driver needs to know
> what MTU the stack is using at any given time. E.g. say a driver can
> handle 8k packets. It would be seriously bad for it to allocate 8k
> buffers everywhere if the stack is only ever going to pass 1500 byte
> packets around. So, I think the eventual plan was to report the normal
> 1500 byte MTU in the DL_INFO_ACK but then have a new DL_SET_MTU
> primitive which is sent by IP to test whether an MTU greater than 1500
> can be used (when an admin types ifconfig XXX mtu YYY) on the command
> line. This gives the driver a chance to either say 'no' (specifically
> or by implication if the primitive is unrecognized) or re-allocate any
> necessary buffers and say 'yes'.
That makes sense. And for Clearview, I guess that means we needn't have
an unbounded packet capability nor a true max sdu property, but instead
have an "increase your max sdu by 4 bytes" command, which may succeed or
fail.
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
766
From:
US
Registered:
6/14/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 19, 2005 1:19 AM
in response to: mditto
|
|
Mike Ditto wrote:
> That makes sense. And for Clearview, I guess that means we needn't have
> an unbounded packet capability nor a true max sdu property, but instead
> have an "increase your max sdu by 4 bytes" command, which may succeed or
> fail.
I don't think I get it. In any case, the SDU size reported to the DLS
clients should not include the size of ethernet header. Even for drivers
can handle VLAN, they should not report dl_max_sdu of 1504.
There are actually two seperate issues here: One is the VLAN issue
described in section 6.1.4, another is the Jumbo frame support. For
Jumbo frame support, we do report the Jumbo frame size in the dl_max_sdu
field of DL_INFO_ACK, but that size doesn't include the size of ethernet
header, so it won't help the VLAN issue.
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
429
From:
GB
Registered:
6/15/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 19, 2005 1:58 AM
in response to: yun
|
|
On 12/19/05, Cathy Zhou <Cathy dot Zhou at sun dot com> wrote:
>
> There are actually two seperate issues here: One is the VLAN issue
> described in section 6.1.4, another is the Jumbo frame support. For
> Jumbo frame support, we do report the Jumbo frame size in the dl_max_sdu
> field of DL_INFO_ACK, but that size doesn't include the size of ethernet
> header, so it won't help the VLAN issue.
>
Yes, indeed - sorry for confusing the issue. As soon as I see a new
packet size negotiation interface I think 'jumbo frames'. As for
VLANs, how about simply using the dl_reserved field of the DL_INFO_ACK
as a flag to say 'I can handle jumbo frames'? The DLPI spec. says it
has to be set to zero in the normal case so any 3rd party DLPI driver
should set it to that but that doesn't mean you can't set it to
something else since the softmac/legacy driver interface is private.
Paul
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 19, 2005 10:48 AM
in response to: pdurrant
|
|
> Yes, indeed - sorry for confusing the issue. As soon as I see a new
> packet size negotiation interface I think 'jumbo frames'. As for
> VLANs, how about simply using the dl_reserved field of the DL_INFO_ACK
> as a flag to say 'I can handle jumbo frames'? The DLPI spec. says it
> has to be set to zero in the normal case so any 3rd party DLPI driver
> should set it to that but that doesn't mean you can't set it to
> something else since the softmac/legacy driver interface is private.
Personally, I don't think this is a dire enough situation to justify
consuming the one remaining field in the DL_INFO_ACK.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 16, 2005 2:21 AM
in response to: pdurrant
|
|
Paul Durrant wrote:
> Since, to implement the capability, the legacy driver has to be
> changed then why not simply have it return its 'real' max frame size
> in the DL_INFO_ACK?
Oh, are you suggesting returning the real limit in DL_INFO_ACK but in
some place other than dl_max_sdu? That would work very nicely if we're
able and willing to extend the definition of dl_info_ack_t.
Fundamentally, what's needed here is for a driver to provide two pieces
of data: max_sdu for "ordinary" users, and real_max_sdu for users who have
some a priori knowledge of when and how it's permitted to exceed the
nominal max_sdu on this device.
I don't know this is sufficiently mainstream at this point to justify,
say, commandeering the dl_reserved field in dl_info_ack_t.
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
766
From:
US
Registered:
6/14/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 19, 2005 12:01 AM
in response to: mditto
|
|
> Why is the unbounded packet size information handled as a DL capability
> rather than a simple datum accessible via M_IOCTL or the like? Can you
> give some hints on when an interposed STREAMS module should participate
> in the negotiation of this capability, or block its use (by ignoring
> it)?
Ah, yes. I agree an ioctl is much simpler.
Thank you very much!
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
123
From:
Registered:
6/15/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 15, 2005 8:01 PM
in response to: yun
|
|
Cathy,
how do you deal with NICs that automatically strip VLAN tags?
e.g. for bge, there is a flag that we set to tell the hardware to not do that.
for e1000g, there is no such flag and we have to insert the vtag in the driver.
if you only aim to support sun legacy devices, then this probably won't be a
problem because I think our NICs do not do this. but if support is meant for all
non-sun NICs then this might be an issue since we cannot change third party source.
would it make sense to change DL_CAPAB_UNBOUNDED_PKT to DL_CAPAB_VLAN since you
do need explicit changes in the legacy driver (rather than simply making it
accept a larger packet size) to support VLANs?
I'll have more comments on your doc later on.
eric
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
766
From:
US
Registered:
6/14/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 15, 2005 8:52 PM
in response to: tlc
|
|
> how do you deal with NICs that automatically strip VLAN tags?
Which one are you refering to? The receive-side or the transmit-side?
> e.g. for bge, there is a flag that we set to tell the hardware to not
> do that. for e1000g, there is no such flag and we have to insert the
> vtag in the driver.
>
> if you only aim to support sun legacy devices, then this probably
> won't be a problem because I think our NICs do not do this. but if
> support is meant for all non-sun NICs then this might be an issue
> since we cannot change third party source.
>
> would it make sense to change DL_CAPAB_UNBOUNDED_PKT to DL_CAPAB_VLAN
> since you do need explicit changes in the legacy driver (rather than
> simply making it accept a larger packet size) to support VLANs?
This capability can also be used for jumbo frames. Please see the
discussion between Paul and I (under the same thread).
> I'll have more comments on your doc later on.
Thank you!
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
123
From:
Registered:
6/15/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 16, 2005 12:20 AM
in response to: yun
|
|
>
> > how do you deal with NICs that automatically strip VLAN tags?
>
> Which one are you refering to? The receive-side or the transmit-side?
>
I was refering to receive side.
if the hardware strips the vtag, usually the vtag info is conveyed to
the driver through a field in the buffer descriptor. a vlan-aware
driver would use this info for constructing a tagged frame before
passing it upwards. a driver that is not vlan-aware would likely
ignore the vtag field and pass the tagless frame upwards.
> > e.g. for bge, there is a flag that we set to tell the hardware to not
> > do that. for e1000g, there is no such flag and we have to insert the
> > vtag in the driver.
> >
> > if you only aim to support sun legacy devices, then this probably
> > won't be a problem because I think our NICs do not do this. but if
> > support is meant for all non-sun NICs then this might be an issue
> > since we cannot change third party source.
> >
> > would it make sense to change DL_CAPAB_UNBOUNDED_PKT to DL_CAPAB_VLAN
> > since you do need explicit changes in the legacy driver (rather than
> > simply making it accept a larger packet size) to support VLANs?
>
> This capability can also be used for jumbo frames. Please see the
> discussion between Paul and I (under the same thread).
keeping the DL_CAPAB_UNBOUND_PKT name is fine as long as its meaning
is extended to include the case I described above. i.e. a driver
that acks this capability must re-insert vtags if the hardware strips
them.
eric
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
766
From:
US
Registered:
6/14/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 18, 2005 11:59 PM
in response to: tlc
|
|
>
>
>I was refering to receive side.
>if the hardware strips the vtag, usually the vtag info is conveyed to
>the driver through a field in the buffer descriptor. a vlan-aware
>driver would use this info for constructing a tagged frame before
>passing it upwards. a driver that is not vlan-aware would likely
>ignore the vtag field and pass the tagless frame upwards.
>
>
But I would expect that the vtag info should be included in the packets
unless the driver explicitly requests it to be passed seperately as a
field in the buffer descriptor. And it should be very unusual that a
driver unaware of VLAN to request that. Do you know any driver which
does such thing?
That said, sure, we can include the DL_CAPAB_UNBOUNDED_PKT check (or
change to another name) to include the case you described.
Thanks
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2
From:
US
Registered:
11/16/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 16, 2005 1:16 AM
in response to: yun
|
|
Cathy,
This looks very good. I have a few general questions & comments:
* 4.1.5: Could you provide an example/mockup of the new show-aggr
command since you're changing its output format.
* 4.2: If create-aggr specifies the aggr_link name instead of the
key, you should specify how the unique key is picked (the answer is
in section 6.2.6 I think, but it might be worth mentioning here.)
Also I guess that the key will still be displayed by show-aggr?
* 6.1.1: Nice :-)
* 6.1.3: Some DLPI drivers save the ptr to the IPv4 and IPv6 read
queues that they use as an optimization for received IPv4 and IPv6
packets. A single stream with DL_PROMISC_SAP set can disable that
optimization for legacy device driver, which could have a non-
negligible performance impact for these drivers.
* 6.2.7: How are cfgadm unconfigure commands handled? IIRC currently
any plumbed interface on a NIC must be unplumbed before that NIC can
be unconfigured using cfgadm. Is that still the case?
* 6.2.8: It would be nice to have a graph representing these SMF
dependencies.
Nicolas.
On Dec 8, 2005, at 10:21 AM, Cathy Zhou wrote:
> OpenSolaris networking community,
>
> As described in several other threads, Clearview is a project which
> aims to rationalize, unify, and enhance the way network interfaces
> are handled in Solaris. The four components of Clearview are:
>
> IPMP Rearchitecture
> IP Tunneling Device Driver
> IP-Level Observability Devices
> Vanity Naming and Nemo Unification
>
> The final document, covering Vanity Naming and Nemo Unification, is
> now available at:
>
> http://opensolaris.org/os/community/networking/uv-design.pdf
>
> This work aims to allow:
>
> * _All_ network devices to be administered at the link layer
> through a single command (dladm). In the process, this lays the
> groundwork for all future link layer administration.
>
> * _All_ Ethernet devices to have 802.1q VLAN's and 802.3ad link
> aggregations established over them.
>
> * _All_ network devices to be given administratively-chosen names.
> This not only provides administrative convenience, but also allows
> the networking configuration of the machine to be decoupled from
> its underlying hardware.
>
> The timer for comments is set at two weeks (December 23). Thank you
> very much for any comments.
>
> - Cathy
>
> _______________________________________________
> networking-discuss mailing list
> networking-discuss at opensolaris dot org
>
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
429
From:
GB
Registered:
6/15/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 16, 2005 1:42 AM
in response to: ndroux
|
|
On 12/16/05, Nicolas Droux <nicolas at droux dot org> wrote:
>
> * 6.1.3: Some DLPI drivers save the ptr to the IPv4 and IPv6 read
> queues that they use as an optimization for received IPv4 and IPv6
> packets. A single stream with DL_PROMISC_SAP set can disable that
> optimization for legacy device driver, which could have a non-
> negligible performance impact for these drivers.
>
Indeed. The GLD (v2) code can serve as a reference for this. I think
it would be better to optimize by pre-binding streams for IPv4, IPv6
and ARP. Providing no upper stream is bound to a SAP other than this
then you'll catch all the packets you need.
If an upper stream is bound to anything else *then* you can set one of
these streams in DL_PROMISC_SAP mode to catch everything.
Paul
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
766
From:
US
Registered:
6/14/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 19, 2005 1:03 AM
in response to: ndroux
|
|
Nicolas,
Thanks for your comments. See inline:
>
> This looks very good. I have a few general questions & comments:
Thanks!
>
> * 4.1.5: Could you provide an example/mockup of the new show-aggr
> command since you're changing its output format.
Sure. I will update the document.
>
> * 4.2: If create-aggr specifies the aggr_link name instead of the
> key, you should specify how the unique key is picked (the answer is
> in section 6.2.6 I think, but it might be worth mentioning here.)
Okay.
> Also I guess that the key will still be displayed by show-aggr?
No, the key thing will be marked as obolete, so that it will not be
displayed by show-aggr.
> * 6.1.3: Some DLPI drivers save the ptr to the IPv4 and IPv6 read
> queues that they use as an optimization for received IPv4 and IPv6
> packets. A single stream with DL_PROMISC_SAP set can disable that
> optimization for legacy device driver, which could have a non-
> negligible performance impact for these drivers.
I would expect that there will not be many downstream queues - actually
there should be only one pair of queues unless there are applications
opening the legacy /dev node directly. Also, because that particular
downstream stream is set to DL_PROMISC_SAP, we don't need to classify
the packets based on the SAP value at all.
That said, we might find performance issue when our initial prototyping
is done. We will analyze the issue and optimize the code path in order
to reach our performance goal in that case.
>
> * 6.2.7: How are cfgadm unconfigure commands handled? IIRC currently
> any plumbed interface on a NIC must be unplumbed before that NIC can
> be unconfigured using cfgadm. Is that still the case?
"cfgadn disconnet" implies the "cfgadm unconfigure" step before it
requests to disconnect the device (see the cfga_change_state() function
in each cfgadm plubgin module). So they follow the same code path.
>
> * 6.2.8: It would be nice to have a graph representing these SMF
> dependencies.
I will see what I can do.
Thanks again for your comments.
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
429
From:
GB
Registered:
6/15/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 16, 2005 1:56 AM
in response to: yun
|
|
On 12/8/05, Cathy Zhou <Cathy dot Zhou at sun dot com> wrote:
>
> This work aims to allow:
>
> * _All_ network devices to be administered at the link layer
> through a single command (dladm). In the process, this lays the
> groundwork for all future link layer administration.
>
> * _All_ Ethernet devices to have 802.1q VLAN's and 802.3ad link
> aggregations established over them.
>
> * _All_ network devices to be given administratively-chosen names.
> This not only provides administrative convenience, but also allows
> the networking configuration of the machine to be decoupled from
> its underlying hardware.
>
Any chance you'll be able to re-enable the ability for 'physical' mac
devices to register multiple ports? I was forced to concede this point
before Nemo was originally integrated because we could not figure out
a good way of coming up with a default name for, say, mynic instance
0, port 1 - should it be mynic0_1 or port1_mynic0 etc. By limiting the
registration of multiple ports to the single instance aggr driver then
we avoided the problem rather than solving it. Perhaps a solution can
now be found?
The reason I ask is that it would make life significantly easier when
dealing with devices like the one I'm currently working on, which has
a single PCI function but two network ports. The only way one can
register both ports today is to write a nexus driver and fake up two
dips that a child driver can bind to. The child driver can register
each instance separately with the mac layer.
Paul
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
766
From:
US
Registered:
6/14/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 19, 2005 1:30 AM
in response to: pdurrant
|
|
Paul Durrant wrote:
>Any chance you'll be able to re-enable the ability for 'physical' mac
>devices to register multiple ports? I was forced to concede this point
>before Nemo was originally integrated because we could not figure out
>a good way of coming up with a default name for, say, mynic instance
>0, port 1 - should it be mynic0_1 or port1_mynic0 etc. By limiting the
>registration of multiple ports to the single instance aggr driver then
>we avoided the problem rather than solving it. Perhaps a solution can
>now be found?
>The reason I ask is that it would make life significantly easier when
>dealing with devices like the one I'm currently working on, which has
>a single PCI function but two network ports. The only way one can
>register both ports today is to write a nexus driver and fake up two
>dips that a child driver can bind to. The child driver can register
>each instance separately with the mac layer.
>
>
>
I guess with vanity naming, administrators will be able to give the
mynic0_1 interface (or whatever the default name is) a more meaningful
name. But what you exactly request is out of the scope of the Clearview
project. It might be a good RFE.
Thanks
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,575
From:
GB
Registered:
4/27/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo
Unification design review (due 12/23)
Posted:
Dec 20, 2005 9:27 AM
in response to: yun
|
|
On Thu, 2005-12-08 at 18:21, Cathy Zhou wrote:
...
> The final document, covering Vanity Naming and Nemo Unification, is
> now available at:
>
> http://opensolaris.org/os/community/networking/uv-design.pdf
>
> This work aims to allow:
...
> * _All_ network devices to be given administratively-chosen names.
> This not only provides administrative convenience, but also allows
> the networking configuration of the machine to be decoupled from
> its underlying hardware.
Some comments on vanity naming:
It's not immediately obvious to me that vanity naming, particularly
of physical devices, is necessarily a good thing. I think you need
to explain more clearly why this is a good thing.
In particular, allowing physical interfaces to have their names
altered could potentially lead to significant confusion. Normally,
when looking at a machine, I instinctively associate the device
name with a physical socket (which is where the cables go); the
network is abstracted at the IP address level.
What is to stop someone renaming bge0 to bge1, and bge1 to bge0?
And how do you make it obvious that bge0 and bge1 are now the
wrong way round?
(Why does the name of the underlying device need to be changed?
Why not allow the definition of an administrative alias for an
interface, and allow for the target of that alias to be changed?)
Presumably, if bge0 is renamed to net0, /dev/bge0 still exists
(and points to the same location as /dev/net/net0)?
I'm unclear as to what happens to the kstats. In particular, what are
the names? Currently, I can access the statistics for bge0 through
bge:0:bge0 - is this unchanged? Or does the name of this change
to bge:0:net/bge0 (which is how I read the document). And if I
rename it, how do I then access it - as bge:0:net/net0, or using
some other name? Or are their now two kstats - one for the physical
link and one for the vanity name?
What do tools such as netstat and ifconfig show for the interface name?
Currently, they show bge0 or similar. Will they follow the net/net0
scheme, or just show net0?
Would it be possible for (an extra flag may be needed) for ifconfig
and similar tools to show the physical device names?
As I understand it, the way to connect the vanity names to physical
names is using dladm show-dev. However, at present this requires
privilege - so a normal user, or root in a zone, would not be able
to do this. This could be a problem - when trying to work out
networking problems on a system you may not have all privileges.
Thanks,
--
-Peter Tribble
L.I.S., University of Hertfordshire - http://www.herts.ac.uk/
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo
Unification design review (due 12/23
Posted:
Dec 21, 2005 1:22 AM
in response to: ptribble
|
|
The real problem with network interfaces tied to the actual device is if you replace one type of NIC with another type of NIC then your interface name changes and you have to reconfigure everything that has had this information stored in it.
Now if you can rename bge0 to lan0 and you replace bge0 with bgx0 and rename that to lan0, there should be vastly fewer administration problems.
What should happen here is role-based interface names. I agree that doing bge0<->bge1 could be extremely confusing, so maybe there should be a ban on renaming an interface to a name that matches an existing driver?
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
re: Re: Clearview Vanity Naming and
Nemo Unification design review (due 12/23
Posted:
Dec 21, 2005 1:43 AM
in response to: darrenr
|
|
> What should happen here is role-based interface names. I agree that
> doing bge0<->bge1 could be extremely confusing, so maybe there should
> be a ban on renaming an interface to a name that matches an existing
> driver?
I would rather not introduce rules like that -- instead, common sense
should apply. Further, I can envision specialized cases where you want to
temporarily do a rename like that to work around a problem or test out a
configuration.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Shantnu Sharma
Shantnu.Sharma@Sun.COM
|
|
|
|
Re: Re: Clearview Vanity Naming and Nemo
Unification design review (due 12/23
Posted:
Dec 28, 2005 2:18 PM
in response to: meem
|
|
Agreed with what Meem is saying.
Nothing frustrates a user more than a software that is "intelligent
enough" to prevent the user from doing something "harmful". Lets not get
into the business of enforcing common sense..
Peter Memishian wrote:
> > What should happen here is role-based interface names. I agree that
> > doing bge0<->bge1 could be extremely confusing, so maybe there should
> > be a ban on renaming an interface to a name that matches an existing
> > driver?
>
>I would rather not introduce rules like that -- instead, common sense
>should apply. Further, I can envision specialized cases where you want to
>temporarily do a rename like that to work around a problem or test out a
>configuration.
>
>
>
--
--------------------------
Shantnu Sharma
Development Manager, Operating Platforms Group
Burlington, MA
Shantnu dot Sharma at SUN dot com
978.239.8154 Cell
781.442.2370 Work
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
766
From:
US
Registered:
6/14/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 21, 2005 2:11 AM
in response to: ptribble
|
|
>It's not immediately obvious to me that vanity naming, particularly
>of physical devices, is necessarily a good thing. I think you need
>to explain more clearly why this is a good thing.
>
>
This is discussed in the document: "vanity naming will prove especially
useful for machine migration, Zones migration and Dynamic Reconfiguration."
There is also an example specifically for DR, see section 3.1.4 on page
5. Simply put: today, because the link name is tightly tied to the
underlying hardware, there is no way that you can remove bge0 and insert
ce0 then the system will just work. You have to replumbing the ce0 link,
update all related configuration to the new name... That's tedious and
it is very possible that you will leave out one or two configuration
with the old bge0 name by mistake.
>In particular, allowing physical interfaces to have their names
>altered could potentially lead to significant confusion. Normally,
>when looking at a machine, I instinctively associate the device
>name with a physical socket (which is where the cables go); the
>network is abstracted at the IP address level.
>
>
I would expect that there are only very few times that the administrator
needs to care about the physical attachment of a link. If they do need
to know about the device name, it can be displayed by the "dladm
show-phys" subcommand.
>What is to stop someone renaming bge0 to bge1, and bge1 to bge0?
>And how do you make it obvious that bge0 and bge1 are now the
>wrong way round?
>
>
... except *nobody* would reasonably configure like that. Note that
vanity naming doesn't mean that administrators should rename links
randomly and frequently.
>(Why does the name of the underlying device need to be changed?
>
>
You mean the link name, right? The name of the underlying device will
not be able to be changed. If administrators doesn't want any vanity
link name, no extra configuration will be needed and the physical link
will be assigned the default name, which will be the same as the device
name. Nothing will be changed.
>Why not allow the definition of an administrative alias for an
>interface, and allow for the target of that alias to be changed?)
>
>
>
>Presumably, if bge0 is renamed to net0, /dev/bge0 still exists
>(and points to the same location as /dev/net/net0)?
>
>
Yes.
>I'm unclear as to what happens to the kstats. In particular, what are
>the names? Currently, I can access the statistics for bge0 through
>bge:0:bge0 - is this unchanged? Or does the name of this change
>to bge:0:net/bge0 (which is how I read the document).
>
Yes.
>And if I
>rename it, how do I then access it - as bge:0:net/net0, or using
>some other name?
>
Yes, net/net0.
>Or are their now two kstats - one for the physical
>link and one for the vanity name?
>
Yes, one with the device name, and another with the link name. The
former will be kept to preserve the backward compatibility.
>
>What do tools such as netstat and ifconfig show for the interface name?
>Currently, they show bge0 or similar. Will they follow the net/net0
>scheme, or just show net0?
>
They will just show "net0".
>
>Would it be possible for (an extra flag may be needed) for ifconfig
>and similar tools to show the physical device names?
>
Why? The big point of vanity naming is to make the high level
configuration independent from the underlying hardware.
>
>As I understand it, the way to connect the vanity names to physical
>names is using dladm show-dev. However, at present this requires
>privilege - so a normal user, or root in a zone, would not be able
>to do this. This could be a problem - when trying to work out
>networking problems on a system you may not have all privileges.
>
>
The device name will be able to be displayed by "dladm show-phys"
subcommand, which can be issued by any user, as long as he/she has the
sys_net_config priviledge.
Thanks for your comments.
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,575
From:
GB
Registered:
4/27/05
|
|
|
|
Re: Clearview Vanity Naming and
Nemo Unification design review (due 12/23)
Posted:
Dec 22, 2005 8:54 AM
in response to: yun
|
|
On Wed, 2005-12-21 at 10:11, Cathy Zhou wrote:
> >It's not immediately obvious to me that vanity naming, particularly
> >of physical devices, is necessarily a good thing. I think you need
> >to explain more clearly why this is a good thing.
> >
> This is discussed in the document: "vanity naming will prove especially
> useful for machine migration, Zones migration and Dynamic Reconfiguration."
But those are relatively rarified cases - what benefits are there to the
majority
of users?
> There is also an example specifically for DR, see section 3.1.4 on page
> 5. Simply put: today, because the link name is tightly tied to the
> underlying hardware, there is no way that you can remove bge0 and insert
> ce0 then the system will just work. You have to replumbing the ce0 link,
> update all related configuration to the new name... That's tedious and
> it is very possible that you will leave out one or two configuration
> with the old bge0 name by mistake.
Well yes, but is vanity naming the way to do this? Why isn't it possible
to have a utility that saves all the configuration associated with an
interface,
and then be able to apply that to the new interface? (Actually, that
would
be a handy tool to have in any event.)
> >In particular, allowing physical interfaces to have their names
> >altered could potentially lead to significant confusion. Normally,
> >when looking at a machine, I instinctively associate the device
> >name with a physical socket (which is where the cables go); the
> >network is abstracted at the IP address level.
> >
> >
> I would expect that there are only very few times that the administrator
> needs to care about the physical attachment of a link. If they do need
> to know about the device name, it can be displayed by the "dladm
> show-phys" subcommand.
This is absolutely key information for an administrator. It is
*absolutely
essential* that I be able to understand the physical connectivity, and
to
be able to get this information easily. And, currently, the dladm
invocation
is insufficient.
> >What is to stop someone renaming bge0 to bge1, and bge1 to bge0?
> >And how do you make it obvious that bge0 and bge1 are now the
> >wrong way round?
> >
> >
> ... except *nobody* would reasonably configure like that.
Unfortunately, the world isn't an ideal place, and not all
administrators share the same values.
> Note that
> vanity naming doesn't mean that administrators should rename links
> randomly and frequently.
Provide the capability, and it will be abused.
> >(Why does the name of the underlying device need to be changed?
> >
> You mean the link name, right? The name of the underlying device will
> not be able to be changed. If administrators doesn't want any vanity
> link name, no extra configuration will be needed and the physical link
> will be assigned the default name, which will be the same as the device
> name. Nothing will be changed.
OK, I'll try to ask the question somewhat differently.
Why change the link name at all? Why not provide the ability to define
a logical alias to which all configuration can be applied? Then the
link names never change at all, which saves a lot of work and confusion.
But, by associating configuration with the alias rather than the
physical
device you get the abstraction required.
> >I'm unclear as to what happens to the kstats. In particular, what are
> >the names? Currently, I can access the statistics for bge0 through
> >bge:0:bge0 - is this unchanged? Or does the name of this change
> >to bge:0:net/bge0 (which is how I read the document).
> >
> Yes.
Yes to which?
> >Or are their now two kstats - one for the physical
> >link and one for the vanity name?
> >
> Yes, one with the device name, and another with the link name. The
> former will be kept to preserve the backward compatibility.
This introduces a couple of problems (and a further question):
- is there a performance impact of keeping duplicate kstats? It seems
to me that there is an unnecessary cost here.
- there is a risk of confusion here, as tools see the data twice and
can end up counting traffic twice.
And the question: what happens to the data associated with the vanity
kstat if it gets moved to another physical interface? Is it just
forgotten
about? Or can the historical data embedded in the kstat be transferred
across?
> >What do tools such as netstat and ifconfig show for the interface name?
> >Currently, they show bge0 or similar. Will they follow the net/net0
> >scheme, or just show net0?
> >
> They will just show "net0".
Ah. So there will be no indication whatsoever whether this is the
default
(ie. physical) link-name or a vanity name?
> >Would it be possible for (an extra flag may be needed) for ifconfig
> >and similar tools to show the physical device names?
> >
> Why? The big point of vanity naming is to make the high level
> configuration independent from the underlying hardware.
However, an understanding of this maps onto the underlying hardware
is essential.
> >As I understand it, the way to connect the vanity names to physical
> >names is using dladm show-dev. However, at present this requires
> >privilege - so a normal user, or root in a zone, would not be able
> >to do this. This could be a problem - when trying to work out
> >networking problems on a system you may not have all privileges.
> >
> The device name will be able to be displayed by "dladm show-phys"
> subcommand, which can be issued by any user, as long as he/she has the
> sys_net_config priviledge.
Unfortunately, that privilege also includes the rights to completely
reconfigure any aspect of networking, so that isn't something that would
be given to just any user. And certainly wouldn't be given out to a
zone.
Why is this information restricted? Why can't anybody see the physical
layout? I would very much like to get this output without requiring any
special privileges.
Thanks for the responses!
--
-Peter Tribble
L.I.S., University of Hertfordshire - http://www.herts.ac.uk/
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
766
From:
US
Registered:
6/14/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 22, 2005 8:51 PM
in response to: ptribble
|
|
>>This is discussed in the document: "vanity naming will prove especially
>>useful for machine migration, Zones migration and Dynamic Reconfiguration."
>>
>>
>
>But those are relatively rarified cases - what benefits are there to the
>majority of users?
>
>
Administrators will be able to give the network links meaningful names
if they like. Again, if they don't want vanity naming at all, no
configuration will be needed and the system will behave exactly the same
as today.
>Well yes, but is vanity naming the way to do this? Why isn't it possible
>to have a utility that saves all the configuration associated with an
>interface, and then be able to apply that to the new interface? (Actually, that
>would be a handy tool to have in any event.)
>
>
Right, assuming we had such tools, it might solve the problem. But keep
in mind that network configuration could be anywhere: configuration
files, the SMF repository, or even just embedded in the file name (for
example, hostname.*). Also, how to migrate the configuration of some
third party applications? This is not a easy effort.
>>I would expect that there are only very few times that the administrator
>>needs to care about the physical attachment of a link. If they do need
>>to know about the device name, it can be displayed by the "dladm
>>show-phys" subcommand.
>>
>>
>
>This is absolutely key information for an administrator. It is
>*absolutely
>essential* that I be able to understand the physical connectivity, and
>to
>be able to get this information easily. And, currently, the dladm
>invocation is insufficient.
>
>
I agree that the physical connectivity is important. But with vanity
naming in place, it doesn't prohibit you from knowing that information.
Actually dladm could help you to figure out the connection of each link
by displaying the link state of each link.
>>... except *nobody* would reasonably configure like that.
>>
>>
>
>Unfortunately, the world isn't an ideal place, and not all
>administrators share the same values.
>
>>ote that
>>vanity naming doesn't mean that administrators should rename links
>>randomly and frequently.
>>
>>
>
>Provide the capability, and it will be abused.
>
>
Well, I don't know what we can do if privileged users do such things
only to confuse themselves.
>OK, I'll try to ask the question somewhat differently.
>
>Why change the link name at all? Why not provide the ability to define
>a logical alias to which all configuration can be applied? Then the
>link names never change at all, which saves a lot of work and confusion.
>But, by associating configuration with the alias rather than the
>physical
>device you get the abstraction required.
>
>
How to associate configuration with the alias? Does that mean
appliations will then access the link by opening the alias instead of
the link name? I guess the alias should be in the different namespace
from the link name. So that the open() API needs to indicate somehow
that it is openning an alias, not a link name? I might miss something
but I don't see how it going to work.
>>>I'm unclear as to what happens to the kstats. In particular, what are
>>>the names? Currently, I can access the statistics for bge0 through
>>>bge:0:bge0 - is this unchanged? Or does the name of this change
>>>to bge:0:net/bge0 (which is how I read the document).
>>>
>>>
>>>
>>Yes.
>>
>>
>
>Yes to which?
>
>
Sorry that I wasn't clear. Yes, there will be a kstat named "net/bge0".
>>>Or are their now two kstats - one for the physical
>>>link and one for the vanity name?
>>>
>>>
>>>
>>Yes, one with the device name, and another with the link name. The
>>former will be kept to preserve the backward compatibility.
>>
>>
>
>This introduces a couple of problems (and a further question):
>
> - is there a performance impact of keeping duplicate kstats? It seems
>to me that there is an unnecessary cost here.
>
>
No, there is no extra cost. It actually involves the implementation of
kstat: simply speaking, the kernel will only track the statistics once,
but both kstats will query the same set of statistics data in the kernel.
> - there is a risk of confusion here, as tools see the data twice and
>can end up counting traffic twice.
>
>
See above. And what do you mean that the tools will see the data twice?
>And the question: what happens to the data associated with the vanity
>kstat if it gets moved to another physical interface? Is it just
>forgotten
>about?
>
Assume that at first net0 is associated with ce0. If then net0 is
asssoicated with bge0, its kstat will only indiate the statistics value
of bge0. There is no history issue.
> Or can the historical data embedded in the kstat be transferred
>across?
>
>>They will just show "net0".
>>
>>
>
>Ah. So there will be no indication whatsoever whether this is the
>default (ie. physical) link-name or a vanity name?
>
>
No. I don't see obvious reason why applications like ifconfig care about
whether it is default name or not. If administators need to know the
mapping, they can compare the link name with the device name displayed
in "dladm show-phys".
>>Why? The big point of vanity naming is to make the high level
>>configuration independent from the underlying hardware.
>>
>>
>
>However, an understanding of this maps onto the underlying hardware
>is essential.
>
>
Okay. Again, one can figure out the mapping using "dladm show-phys".
>>The device name will be able to be displayed by "dladm show-phys"
>>subcommand, which can be issued by any user, as long as he/she has the
>>sys_net_config priviledge.
>>
>>
>
>Unfortunately, that privilege also includes the rights to completely
>reconfigure any aspect of networking, so that isn't something that would
>be given to just any user. And certainly wouldn't be given out to a
>zone.
>
>Why is this information restricted? Why can't anybody see the physical
>layout? I would very much like to get this output without requiring any
>special privileges.
>
>
Thanks to point it out. It appears that this is a bug, see
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6219893.
Thank you very much for your input!
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 23, 2005 6:56 AM
in response to: yun
|
|
Cathy Zhou writes:
> >Provide the capability, and it will be abused.
> >
> >
> Well, I don't know what we can do if privileged users do such things
> only to confuse themselves.
I don't think it'd be a bad idea at all to have a document that
describes some suggested usages and some things that ought to be
avoided. Perhaps it could focused on particular tasks: "using vanity
naming with Zones," "vanity naming with DR," "vanity naming in
clusters," and so on. This should probably go into a blueprint or the
administrator's guide.
I agree that we're potentially handing people a lot of new rope.
If we know or find out any hazards, write them down.
> How to associate configuration with the alias? Does that mean
> appliations will then access the link by opening the alias instead of
> the link name? I guess the alias should be in the different namespace
> from the link name. So that the open() API needs to indicate somehow
> that it is openning an alias, not a link name? I might miss something
> but I don't see how it going to work.
There are at least two ways to do this. The one you're doing now
effectively _is_ that sort of alias -- yet another device node in the
tree somewhere that's named by the user.
Another way to do it is to provide a new feature that's analogous to
the ifAlias property in RFC 2863 (Interfaces MIB). This doesn't
involve new device nodes or even potentially any kernel code.
Instead, you just provide a way for the administrator to assign and
retrieve an arbitrary string (e.g., "third wire from left" or "uplink
to transit") on a per-interface basis.
This allows administrators to assign meaningful notes on interfaces --
more so than can be jammed into the rather restrictive IP interface
naming conventions -- and gets out of the way of low-level
applications. Applications that need to look up or use these new
strings will themselves need to iterate over the system's interfaces
in the usual way.
This is extremely useful for GUIs and the like. It's a requirement if
you want to support the Standards-Track MIBs. It's a common feature
and requirement for telecommunications gear.
The downside is that "simple" operations, such as netstat, snoop, and
ifconfig, see no obvious benefit. They're most likely still stuck in
the world of e1000g0 and hme5. And thus DR and Zones probably become
no easier to use.
I talked at some length with meem about this a long time ago. The
short answer is that if you have a requirement to make the command
line tools easier and friendlier to use, then a high-level ifAlias
feature won't really get you there. It'd still be nice to have, but
it's not the same thing.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
766
From:
US
Registered:
6/14/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Dec 24, 2005 12:08 AM
in response to: carlsonj
|
|
>I don't think it'd be a bad idea at all to have a document that
>describes some suggested usages and some things that ought to be
>avoided. Perhaps it could focused on particular tasks: "using vanity
>naming with Zones," "vanity naming with DR," "vanity naming in
>clusters," and so on. This should probably go into a blueprint or the
>administrator's guide.
>
>
Agreed. Proper documentation definitely will help.
>Another way to do it is to provide a new feature that's analogous to
>the ifAlias property in RFC 2863 (Interfaces MIB). This doesn't
>involve new device nodes or even potentially any kernel code.
>Instead, you just provide a way for the administrator to assign and
>retrieve an arbitrary string (e.g., "third wire from left" or "uplink
>to transit") on a per-interface basis.
>
>This allows administrators to assign meaningful notes on interfaces --
>more so than can be jammed into the rather restrictive IP interface
>naming conventions -- and gets out of the way of low-level
>applications. Applications that need to look up or use these new
>strings will themselves need to iterate over the system's interfaces
>in the usual way.
>
>This is extremely useful for GUIs and the like. It's a requirement if
>you want to support the Standards-Track MIBs. It's a common feature
>and requirement for telecommunications gear.
>
>The downside is that "simple" operations, such as netstat, snoop, and
>ifconfig, see no obvious benefit. They're most likely still stuck in
>the world of e1000g0 and hme5. And thus DR and Zones probably become
>no easier to use.
>
>I talked at some length with meem about this a long time ago. The
>short answer is that if you have a requirement to make the command
>line tools easier and friendlier to use, then a high-level ifAlias
>feature won't really get you there. It'd still be nice to have, but
>it's not the same thing.
>
>
As always, it is very informative. Thank you!
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 4, 2006 1:05 PM
in response to: yun
|
|
Cathy Zhou writes:
> http://opensolaris.org/os/community/networking/uv-design.pdf
I'm not sure what the reference to PPPoE "devices" in section 3.1.1
means. Does this mean the 'device' names that sppptun uses to plumb
PPPoE streams? The 'interface' names used to name those streams (and
used by pppd to refer to them)? Or the "sppp" interfaces created by
pppd itself?
If it refers to the sppptun interface names, then I don't think that
vanity naming needs to do anything here. The existing mechanism ought
to do the job fine because sppptun renames the interface as part of
setting it up. (That whole "default name" guff could be ripped out.)
If it refers to the sppptun device name, then I don't understand why
this wouldn't be supported. I think it should be. If it's not, then
it sounds to me like vanity naming is just incomplete. Why would this
one standard part of Solaris not be supported? Shouldn't it just try
"/dev/net/%s" first and then "/dev/%s"?
I continue to believe that the MAC naming conventions from Nemo are a
bit weird. It just doesn't strike me as correct to have a naming
structure where one element is always exactly zero -- either bgeX/0 or
aggr0/X, but never fooX/Y. I realize that it corresponds to something
obscure buried in the implementation and that there are rumors that
some physical interface someday may possibly have multiple "ports"
(though what those might represent has never been adequately
explained), but, despite the extended hallway discussions I've had
with meem about this, it still doesn't feel right. (Perhaps nothing
you can fix here, but it makes me queasy anyway.)
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
notion that this feature takes *link* names rather than *device*
names, but the fact that one letter or another was chosen is, I
believe, moot. At best, you could introduce "-l" as an alias for
"-d," but I can see no good case to be made for obsoleting and
removing "-d." If it were my project, though, I would not bother to
do even that. I'd just note in the man page that the argument for
"-d" is a link name, and move on. There's no reason that the letter
"d" must mean "device" here and that "device" must mean "no vanity
naming allowed." Users just don't think that way and are unlikely to
care much about the distinction.
Why is the subcommand named "discard-phys"? It looks to me like this
discards the configuration of a _link_, not a physical device, 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.)
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
device names and interface names are unrelated and that applications
that were relying on this can be broken with impunity. Not only does
ifconfig obviously do this with "-a plumb", but others may well have
relied on it as we provide no other usable interface to find the
network interfaces.
http://search.cpan.org/src/DAGOBERT/Solaris-DeviceTree-0.02/lib/Solaris/DeviceTree/Libdevinfo.pm
5.1: while you're there, could you just move libmacadm into libdladm?
Do we really need a separate library to house one function?
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?
What about wificonfig updates to support vanity link names? Any
changes required here?
When does SunTrunking get EOF'd and replaced with the softmac support?
Why does this new project introduce a feature that overlaps an
existing product but does *not* explicitly announce a transition for
the older product?
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
766
From:
US
Registered:
6/14/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 5, 2006 9:27 PM
in response to: carlsonj
|
|
>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)?
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.
>I continue to believe that the MAC naming conventions from Nemo are a
>bit weird. It just doesn't strike me as correct to have a naming
>structure where one element is always exactly zero -- either bgeX/0 or
>aggr0/X, but never fooX/Y. I realize that it corresponds to something
>obscure buried in the implementation and that there are rumors that
>some physical interface someday may possibly have multiple "ports"
>(though what those might represent has never been adequately
>explained), but, despite the extended hallway discussions I've had
>with meem about this, it still doesn't feel right. (Perhaps nothing
>you can fix here, but it makes me queasy anyway.)
>
>
>
Seb already has this change in his binary compatibility mac_t wad. The
format for MAC names will be <drvname>N.
>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
>notion that this feature takes *link* names rather than *device*
>names, but the fact that one letter or another was chosen is, I
>believe, moot. At best, you could introduce "-l" as an alias for
>"-d," but I can see no good case to be made for obsoleting and
>removing "-d." If it were my project, though, I would not bother to
>do even that. I'd just note in the man page that the argument for
>"-d" is a link name, and move on. There's no reason that the letter
>"d" must mean "device" here and that "device" must mean "no vanity
>naming allowed." Users just don't think that way and are unlikely to
>care much about the distinction.
>
>
>
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.
>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".
>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). 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.
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.
>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
>device names and interface names are unrelated and that applications
>that were relying on this can be broken with impunity. Not only does
>ifconfig obviously do this with "-a plumb", but others may well have
>relied on it as we provide no other usable interface to find the
>network interfaces.
>
>http://search.cpan.org/src/DAGOBERT/Solaris-DeviceTree-0.02/lib/Solaris/DeviceTree/Libdevinfo.pm
>
>
>
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.
>5.1: while you're there, could you just move libmacadm into libdladm?
>Do we really need a separate library to house one function?
>
>
Sure.
>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? If what you are suggesting is to evaluate the
performance impact first, sure we will do that.
>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 SunTrunking get EOF'd and replaced with the softmac support?
>Why does this new project introduce a feature that overlaps an
>existing product but does *not* explicitly announce a transition for
>the older product?
>
>
Sure, I will talk to the SunTrunking owner about this.
Thank you very much for all your comments.
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 6, 2006 7:43 AM
in response to: yun
|
|
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 <james dot d dot carlson at sun dot com>
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
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 6, 2006 7:58 AM
in response to: carlsonj
|
|
> 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.
Agreed. Right now, it looks like dladm/wifi will be done long before
vanity naming (I cannot post dates here) -- however, if not, we will
update wificonfig to work with vanity names.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
766
From:
US
Registered:
6/14/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 7, 2006 1:01 AM
in response to: carlsonj
|
|
>
>OK, then it sounds like vanity naming *IS* supported for PPPoE, and
>this text can just be removed.
>
>
>
Okay, will do.
>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.
>
>
>
Agreed.
>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.
>
>Just for usability (if nothing else), I think it'd be nice to have
>"delete-<X>" be the pattern everywhere.
>
>
>
The "delete-phys -f" approach seems nice. I will talk to the team about it.
>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 fully agree all of the above.
>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.
>
>
... and a single "create" to create each type of link by specifying
different options? I will think about it.
>
>I think this needs a big readme entry, blogs, comp.unix.solaris
>postings, and any other advertisements we can think of.
>
>
>
Agreed.
>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.
>
>
>
Okay. Thank you very much for reminding.
>>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.
>
>
>
Okay.
>When does the wificonfig->dladm transition occur?
>
Meem already answered this, and yes, if this component goes in before
the wificonfig/dladm transition, we willl have to update wificonfig.
Thanks
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 7, 2006 4:35 PM
in response to: yun
|
|
> The "delete-phys -f" approach seems nice. I will talk to the team about it.
As I recall, delete-phys was considered, but there were two concerns:
* All of the other "delete" subcommands actually delete the
corresponding type of link. In this case, the link has already
been deleted (via DR), and only its persistent configuration
remains.
* All of the other "delete" subcommands have a corresponding
"create" subcommand.
> ... and a single "create" to create each type of link by specifying
> different options? I will think about it.
I think that would lead to quite a mess of options.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
766
From:
US
Registered:
6/14/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 7, 2006 7:26 PM
in response to: meem
|
|
Peter Memishian wrote:
> > The "delete-phys -f" approach seems nice. I will talk to the team about it.
>
>As I recall, delete-phys was considered, but there were two concerns:
>
> * All of the other "delete" subcommands actually delete the
> corresponding type of link. In this case, the link has already
> been deleted (via DR), and only its persistent configuration
> remains.
>
>
To be consistent, we can also have "delete-vlan -f" and "delete-aggr -f"
to not only delete the specified link, but also all links reference it.
Although I am not sure how complicate the implementation would be.
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 9, 2006 8:11 AM
in response to: meem
|
|
Peter Memishian writes:
> As I recall, delete-phys was considered, but there were two concerns:
>
> * All of the other "delete" subcommands actually delete the
> corresponding type of link. In this case, the link has already
> been deleted (via DR), and only its persistent configuration
> remains.
Given that DR isn't quite in bed with Clearview (e.g., the multiple
commands required to remove an interface and then put in a
replacement), it seems a little strange to me to say that the link has
"already been deleted" when all that's happened is that the hardware
has disappeared.
As long as the user can talk about links that are divorced from
hardware, why not allow those things to be deleted? How are those
link configuration bits any more or less "real" than the ones used for
any virtualized concept, such as VLANs or aggregations?
I don't see enough of a semantic gap to suggest that a new word is
really needed here. And I *do* think that having a new word for
essentially the same operation is confusing.
> * All of the other "delete" subcommands have a corresponding
> "create" subcommand.
Sure, but the confusion here is caused in part by the fact that device
enumeration automatically creates default links for hardware, and that
DR is not completely integrated with Clearview. If it were, then
"create" would have meaning here.
It's not delete's fault that create is strange. If it did anything,
I'd expect "create-phys" to say, "yep, it's already there."
> > ... and a single "create" to create each type of link by specifying
> > different options? I will think about it.
>
> I think that would lead to quite a mess of options.
It can't possibly lead to a mess that's any larger or smaller than the
existing one.
Just run the command line syntax through s/delete-\(.*\) /delete -t \1/
and you end up with equivalent bits. In other words, instead of:
delete-foo [-abc] [-d opt] [-e opt...]
delete-bar [-fgh] [-i opt] [-j opt...]
you end up with:
delete -t foo [-abc] [-d opt] [-e opt...]
delete -t bar [-fgh] [-i opt] [-j opt...]
I don't see much in the way of distinction there.
There's no requirement that I know of that all the usage cases of a
given suboption must be glommed together in the man page description,
particularly if a given suboption works on multiple objects. Perhaps
that's the point of disagreement.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 9, 2006 5:33 PM
in response to: carlsonj
|
|
> Given that DR isn't quite in bed with Clearview (e.g., the multiple
> commands required to remove an interface and then put in a
> replacement), it seems a little strange to me to say that the link has
> "already been deleted" when all that's happened is that the hardware
> has disappeared.
As far as removing a card is concerned, things are well-integrated -- the
admin issues the cfgadm command, and the current links associated with the
card are deleted.
> As long as the user can talk about links that are divorced from
> hardware, why not allow those things to be deleted?
We do -- but doing it with "delete" may be confusing, because you're not
really deleting the same thing you would with something like delete-vlan.
With discard-phys, you're removing persistent but *dormant* configuration.
There is no way with discard-phys to delete the current configuration --
but that's the default mode for all of the other delete-* commands.
> Sure, but the confusion here is caused in part by the fact that device
> enumeration automatically creates default links for hardware, and that
> DR is not completely integrated with Clearview. If it were, then
> "create" would have meaning here.
The need for discard-phys falls out of the fact that we have no idea what
the administrator's intent is when they remove a given card -- i.e.,
whether they will plug it back in. Even if we did not automatically
create default links for hardware, you would want to have a way to discard
a configuration associated with removed hardware that will never be
re-inserted (e.g., so that the link names can be reused).
> delete-foo [-abc] [-d opt] [-e opt...]
> delete-bar [-fgh] [-i opt] [-j opt...]
>
> you end up with:
>
> delete -t foo [-abc] [-d opt] [-e opt...]
> delete -t bar [-fgh] [-i opt] [-j opt...]
>
> I don't see much in the way of distinction there.
The difference is that, per UI guidelines, you are not allowed to have the
same option leeter mean something different for two different -t values.
For instance, if -t foo wanted to have an "-a" option that took a value,
and if -t bar wanted to have a semantically distinct "-a" option that did
not take a value, there would be no way to do this. So you quickly end up
with truss syndrome.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 10, 2006 9:04 AM
in response to: meem
|
|
Peter Memishian writes:
> > Given that DR isn't quite in bed with Clearview (e.g., the multiple
> > commands required to remove an interface and then put in a
> > replacement), it seems a little strange to me to say that the link has
> > "already been deleted" when all that's happened is that the hardware
> > has disappeared.
>
> As far as removing a card is concerned, things are well-integrated -- the
> admin issues the cfgadm command, and the current links associated with the
> card are deleted.
It doesn't seem so. It seems more like the links are "deactivated" or
"detached" or some such. "Deleted" to me implies that the links are
just plain gone. They're not completely gone and they can come back
when a new card is inserted and associated with the old configuration.
> > As long as the user can talk about links that are divorced from
> > hardware, why not allow those things to be deleted?
>
> We do -- but doing it with "delete" may be confusing, because you're not
> really deleting the same thing you would with something like delete-vlan.
> With discard-phys, you're removing persistent but *dormant* configuration.
> There is no way with discard-phys to delete the current configuration --
> but that's the default mode for all of the other delete-* commands.
I don't find the idea that "delete" can fail under some special
circumstances all that confusing. For example, I say "delete bge0"
and it says, "I can't do that; you'll have to ask cfgadm to remove the
hardware first." It has to say that because the two systems are
intentionally not integrated very tightly, and I have to use a
different tool to accomplish the entire task.
> > Sure, but the confusion here is caused in part by the fact that device
> > enumeration automatically creates default links for hardware, and that
> > DR is not completely integrated with Clearview. If it were, then
> > "create" would have meaning here.
>
> The need for discard-phys falls out of the fact that we have no idea what
> the administrator's intent is when they remove a given card -- i.e.,
> whether they will plug it back in. Even if we did not automatically
> create default links for hardware, you would want to have a way to discard
> a configuration associated with removed hardware that will never be
> re-inserted (e.g., so that the link names can be reused).
Yep; that's all understood.
> > I don't see much in the way of distinction there.
>
> The difference is that, per UI guidelines, you are not allowed to have the
> same option leeter mean something different for two different -t values.
> For instance, if -t foo wanted to have an "-a" option that took a value,
> and if -t bar wanted to have a semantically distinct "-a" option that did
> not take a value, there would be no way to do this. So you quickly end up
> with truss syndrome.
Assuming the issue is merely the consumption of available letters,
that's perhaps[1] true. However, the real complexity here is that
there are different kinds of interfaces with different kinds of
options, not the letters chosen to represent those options.
I feel this solution (keying off of subcommand rather than a separate
type) really just skirts the issue: having lots of different options
is complicated, no matter what you do, and the root of those UI rules
is that if you have too many options, nobody'll understand your
command. :-/
Getting back to the original issue: while I think it's great that we
have a single "link" concept that spans multiple different but highly
related and understandable usages, I think it's really unfortunate
that we have different commands for creating and destroying[2] them
based on a subtype. I know how you got there, and I don't see a good
way out now, but that makes the command set harder to understand.
It's harder still to understand when extra verbs are introduced
("destroy" versus "delete") for operations that are, at least to me,
nearly identical in practical administrative impact. Why doesn't
"destroy-vlan" work? It's confusing.
[1] I say "perhaps" because if someone can come up with a good way to
use a feature and a sound argument for it, an exception or a new
rule could certainly be made. Those CUI rules aren't written in
stone.
[2] Er ... "deleting."
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 10, 2006 11:15 PM
in response to: carlsonj
|
|
> It doesn't seem so. It seems more like the links are "deactivated" or
> "detached" or some such. "Deleted" to me implies that the links are
> just plain gone. They're not completely gone and they can come back
> when a new card is inserted and associated with the old configuration.
Of course, this is really up to Cathy -- and I don't have a strong opinion
on it anyway. My point was that there are three "levels" of deletion:
1. Will come back on reboot.
2. Won't come back on reboot, but might come back if the right
hardware is plugged in.
3. Won't come back.
In the case of a normal "delete" command, only (1) and (3) are possible.
If you DR out a card, then all associated links may end up being "deleted"
as per (2), but not explicitly. In the case of something like
delete-phys, only (3) would be possible, and it would only work when the
link itself is already at level (2). So delete-phys seems like a bit of
an odd bird. But maybe it can be reconciled.
> Assuming the issue is merely the consumption of available letters,
> that's perhaps[1] true.
That's a clear-cut part of it, and was enough for me to give up on the
approach fairly early. Well, that and the fact that create-aggr (and
delete-aggr) are already cast in (semi-permanent?) stone.
A single "delete-link" command does seem feasible, though something we
could add at any point in the future.
> It's harder still to understand when extra verbs are introduced
> ("destroy" versus "delete") for operations that are, at least to me,
> nearly identical in practical administrative impact. Why doesn't
> "destroy-vlan" work? It's confusing.
I'm not sure I understand this one. Are you talking about "discard"?
There are no "destroy" commands. The create/delete schism is as per the
UI guidelines -- and you know I find it as grotesque as you do :-)
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 11, 2006 4:06 AM
in response to: meem
|
|
Peter Memishian writes:
> > It's harder still to understand when extra verbs are introduced
> > ("destroy" versus "delete") for operations that are, at least to me,
> > nearly identical in practical administrative impact. Why doesn't
> > "destroy-vlan" work? It's confusing.
>
> I'm not sure I understand this one. Are you talking about "discard"?
> There are no "destroy" commands. The create/delete schism is as per the
> UI guidelines -- and you know I find it as grotesque as you do :-)
Sorry ... yes, I meant "discard." But that sort of illustrates the
point. I can't remember it, either.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
215
From:
Scotland
Registered:
9/15/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 11, 2006 4:31 PM
in response to: meem
|
|
On Wed, 11 Jan 2006, Peter Memishian wrote:
<apologies if i'm off here, I've lost the context a bit. I'm presuming
we're taking about 'delete' wrt interfaces>
> Of course, this is really up to Cathy -- and I don't have a strong opinion
> on it anyway. My point was that there are three "levels" of deletion:
>
> 1. Will come back on reboot.
Ie it's not deleted really, it's 'administratively down'? Indeed, it
could 'come back' before reboot, if the 'admin shutdown' condition is
removed/undone.
> 2. Won't come back on reboot, but might come back if the right
> hardware is plugged in.
Weird.
> 3. Won't come back.
*That* sounds like 'delete' to me.
> In the case of a normal "delete" command, only (1) and (3) are possible.
> If you DR out a card, then all associated links may end up being "deleted"
> as per (2), but not explicitly. In the case of something like
> delete-phys, only (3) would be possible, and it would only work when the
> link itself is already at level (2). So delete-phys seems like a bit of
> an odd bird. But maybe it can be reconciled.
I'd really hate case 1 to be referred to as 'delete' in commands.
--paulj
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 11, 2006 9:35 PM
in response to: paulj
|
|
> > Of course, this is really up to Cathy -- and I don't have a strong opinion
> > on it anyway. My point was that there are three "levels" of deletion:
> >
> > 1. Will come back on reboot.
>
> Ie it's not deleted really, it's 'administratively down'? Indeed, it
> could 'come back' before reboot, if the 'admin shutdown' condition is
> removed/undone.
This is called "temporary delete" -- e.g., it is how "delete-aggr -t"
currently behaves in Nevada.
> > 2. Won't come back on reboot, but might come back if the right
> > hardware is plugged in.
>
> Weird.
Weird but necessary in order to make replacement of failed networking
hardware a simple operation.
> > 3. Won't come back.
>
> *That* sounds like 'delete' to me.
Indeed, that is the "normal" delete.
> I'd really hate case 1 to be referred to as 'delete' in commands.
It already is (again, "delete-aggr -t").
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
215
From:
Scotland
Registered:
9/15/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 13, 2006 12:59 PM
in response to: meem
|
|
On Thu, 12 Jan 2006, Peter Memishian wrote:
> This is called "temporary delete" -- e.g., it is how "delete-aggr -t"
> currently behaves in Nevada.
> > > 2. Won't come back on reboot, but might come back if the right
> > > hardware is plugged in.
> Weird but necessary in order to make replacement of failed networking
> hardware a simple operation.
Hmm, ok. And this can happen because someone typed a 'delete' type
command? If you feel like humouring me, I wouldn't mind being educated.
:) (See below, I'm finding it hard following this thread).
> > I'd really hate case 1 to be referred to as 'delete' in commands.
>
> It already is (again, "delete-aggr -t").
Hmm, ok. I have to say that sounds like it really should be called
'disable' or 'shutdown' rather than 'delete' to me. The configuration is
there, it's just disabled for now (not deleted), until such time as its
enabled again (which might happen if the box is rebooted and the
'disabled' state is lost?).
Also have to say I've found it very hard to follow this thread and the
discussion of the various different nuances of the word 'delete'. I
wonder if administrators won't also have a hard time trying to
understand... dladm is new, is its interface still open to change or is
it already set in stone?
--paulj
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview Vanity Naming and Nemo Unification
design review (due 12/23)
Posted:
Jan 13, 2006 7:42 PM
in response to: paulj
|
|
> Hmm, ok. And this can happen because someone typed a 'delete' type
> command? If you feel like humouring me, I wouldn't mind being educated.
It happens as a result of a DR operation, which could be triggered by
cfgadm, by a command on a service processor, through a "remove" button
on the machine itself, or by a few other methods.
> > It already is (again, "delete-aggr -t").
>
> Hmm, ok. I have to say that sounds like it really should be called
> 'disable' or 'shutdown' rather than 'delete' to me. The configuration is
> there, it's just disabled for now (not deleted), until such time as its
> enabled again (which might happen if the box is rebooted and the
> 'disabled' state is lost?).
So you would propose separate subcommand to delete a link's persistent and
current configuration? That seems worse to me. In any case ...
> dladm is new, is its interface still open to change or is
> it already set in stone?
The *-aggr dladm commands are already in S10U1.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
