crossbow discuss - Mar 2009 - dlstat for data link statistics

(Bcc''ed to networking discuss).

Hi All,

    Have enclosed man page draft for dlstat(1M) herewith.

    This is part of the effort to gain better visibility into network traffic in
light of crossbow features like virtual NICs, interrupt vs. polling modes etc.
This in turn would greatly assist network performance analysis. It is also aimed
at segregating link/flow configuration from dynamic network statistics.

In particular,

- dladm/flowadm would retain configuration specific commands for links/flows
while dlstat/flowstat would provide interfaces for displaying dynamic network
statistics.

- show-usage would be removed from dladm/flowadm and would become part of
dlstat/flowstat. It would be renamed show-history.

- Rich set of counters would be available for performance analysis e.g. poll vs.
interrupt count, chain sizes, distribution of load across lanes etc.

- In the man page, ''dlstat show'' synopsis is deliberately
spread across multiple lines. First line, dlstat show [-r | -t]...  provides an
easy template for printing most commonly queried statistics. Comprehensive and
flexible approaches follow.

Note: Numbers in examples section of enclosed man page are used to illustrate
output formatting only.


~ Shri
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dlstat.1m.txt
URL:
<http://mail.opensolaris.org/pipermail/crossbow-discuss/attachments/20090309/23ba66ec/attachment.txt>

Shrikrishna Khare writes:
> - dladm/flowadm would retain configuration specific commands for
links/flows while dlstat/flowstat would provide interfaces for displaying
dynamic network statistics.
> 
> - show-usage would be removed from dladm/flowadm and would become part of
dlstat/flowstat. It would be renamed show-history.
What becomes of the existing "-s" flags on various dladm show-*
subcommands (show-link, show-aggr, show-vnic)?

Do those move over to dlstat as well, or do we end up with some
statistics being shown in dladm while others are accessible through
dlstat?

-- 
James Carlson, Solaris Networking              <james.d.carlson at
sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

On 03/10/09 08:32, James Carlson wrote:
> Shrikrishna Khare writes:
>   
>> - dladm/flowadm would retain configuration specific commands for
links/flows while dlstat/flowstat would provide interfaces for displaying
dynamic network statistics.
>>
>> - show-usage would be removed from dladm/flowadm and would become part
of dlstat/flowstat. It would be renamed show-history.
>>     
>
> What becomes of the existing "-s" flags on various dladm show-*
> subcommands (show-link, show-aggr, show-vnic)?
>   
they should move to dlstat
> Do those move over to dlstat as well, or do we end up with some
> statistics being shown in dladm while others are accessible through
> dlstat?
>
>   
that would be inconsistent.

    Kais,

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/crossbow-discuss/attachments/20090310/1efab9fb/attachment.html>

Kais Belgaied writes:
> On 03/10/09 08:32, James Carlson wrote:
> > Shrikrishna Khare writes:
> >   
> >> - dladm/flowadm would retain configuration specific commands for
links/flows while dlstat/flowstat would provide interfaces for displaying
dynamic network statistics.
> >>
> >> - show-usage would be removed from dladm/flowadm and would become
part of dlstat/flowstat. It would be renamed show-history.
> >>     
> >
> > What becomes of the existing "-s" flags on various dladm
show-*
> > subcommands (show-link, show-aggr, show-vnic)?
> >   
> 
> they should move to dlstat
OK.  Is that change part of this project or another one?  What happens
for compatibility?

Given the on-going activity in dladm, I _strongly_ recommend getting
ARC exposure for this change before going too far with it.  The
effects of this change will likely be felt by several other projects.
> > Do those move over to dlstat as well, or do we end up with some
> > statistics being shown in dladm while others are accessible through
> > dlstat?
> >
> >   
> 
> that would be inconsistent.
Yep; agreed.

-- 
James Carlson, Solaris Networking              <james.d.carlson at
sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

On 03/10/09 09:57, James Carlson wrote:
> Kais Belgaied writes:
>   
>> On 03/10/09 08:32, James Carlson wrote:
>>     
>>> Shrikrishna Khare writes:
>>>   
>>>       
>>>> - dladm/flowadm would retain configuration specific commands
for links/flows while dlstat/flowstat would provide interfaces for displaying
dynamic network statistics.
>>>>
>>>> - show-usage would be removed from dladm/flowadm and would
become part of dlstat/flowstat. It would be renamed show-history.
>>>>     
>>>>         
>>> What becomes of the existing "-s" flags on various dladm
show-*
>>> subcommands (show-link, show-aggr, show-vnic)?
>>>   
>>>       
>> they should move to dlstat
>>     
>
> OK.  Is that change part of this project or another one?  What happens
> for compatibility?
>   
When this was discussed internally, the intention was to at least change
dladm(1m) man page and to announce the obsolescence of the
''-s'' and point to
dlastat(1m) instead.
The code implementing  show-* -s  can be removed from dladm as soon as
it is OK to make an incompatible change.
In our case it''ll the next release of OpenSolaris.
> Given the on-going activity in dladm, I _strongly_ recommend getting
> ARC exposure for this change before going too far with it.  The
> effects of this change will likely be felt by several other projects.
>   
yes, I agree.
BTW, flowstat(1m) is coming up shortly, and will be following dlstat''s 
model.
Once the design discussion starts to settle here, the plan is to ARC the 
two commands
together.

    Kais.
>   
>>> Do those move over to dlstat as well, or do we end up with some
>>> statistics being shown in dladm while others are accessible through
>>> dlstat?
>>>
>>>   
>>>       
>> that would be inconsistent.
>>     
>
> Yep; agreed.
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/crossbow-discuss/attachments/20090310/d5d1af44/attachment.html>

First, thanks for taking this work on, it''s very useful.

I haven''t gone through this in detail, but I have a few high-level
comments beyond what Jim has already covered:

   * The output engine here should use the ofmt API that Sowmini is
     currently wrapping up.  Similarly, the output should be the same form
     as currently shown by dladm, flowadm and ipmpstat.  Along those
     lines, this:

        # dlstat show                                                   
        LINK     IPKTS IBYTES OPKTS  OBYTES %UTIL
        -----------------------------------------
        e1000g0  21.2K  2.1M   0.5K  44.2M  00.0
        ixgbe0   24.5M 13.6G   3.5M   0.1G  00.0
        vnic1    00.0  00.0   00.0   00.0   00.0

     ... should be:

        # dlstat show                                                   
        LINK     IPKTS IBYTES OPKTS  OBYTES  UTIL
        e1000g0  21.2K   2.1M  0.5K   44.2M  0.0%
        ixgbe0   24.5M  13.6G  3.5M    0.1G  0.0%
        vnic1     0.0M   0.0M  0.0M    0.0M  0.0%

     Note in particular that every value should have a unit and the units
     or interpretation of the data should live with the data itself, not
     with the field header.  Again, the ofmt API will generally encourage
     the right thing here (though there''s addditional work that really
     should be done to simplify API consumers, such as 6800985).

   * If we want to support an additional output mode like
"full-screen"
     mode, that should also be handled by the ofmt facility rather than
     special-cased into dlstat.  Likewise for "kstat mode" (but see
     below).

   * It''s not clear to me why we need both "kstat mode" and
"full-screen"
     mode.  If we do need to keep both, I''d be inclined to use
"-k" for
     kstat mode rather than "-v".

   * The "+output" thing is clever but it''d be odd for this
command to
     support it and dladm/flowadm/ipmpstat to not support it.  It should
     also be not allowed in parsable output mode since the caller should
     never rely on the default output mode (since it can change).

--
meem

(Some of this discussion took over networking-discuss, Bcc''ing it
thus).

Hi All,

Updated dlstat man page, dladm man page and diff of dladm man page is 
enclosed.

To address Jim''s concern regarding how dladm would be transitioned: 
dladm man page is changed to declare that show-usage, 
show-{link,aggr,vnic} -s is obsolete. Those commands would continue to 
work for ''a while'' even after dlstat is integrated (would post
exact
timeline later).

As for meem''s comments, please find reply inline:


Peter Memishian wrote:
> First, thanks for taking this work on, it''s very useful.
>
> I haven''t gone through this in detail, but I have a few high-level
> comments beyond what Jim has already covered:
>
>    * The output engine here should use the ofmt API that Sowmini is
>      currently wrapping up.  Similarly, the output should be the same form
>      as currently shown by dladm, flowadm and ipmpstat.  Along those
>      lines, this:
>
>         # dlstat show                                                   
>         LINK     IPKTS IBYTES OPKTS  OBYTES %UTIL
>         -----------------------------------------
>         e1000g0  21.2K  2.1M   0.5K  44.2M  00.0
>         ixgbe0   24.5M 13.6G   3.5M   0.1G  00.0
>         vnic1    00.0  00.0   00.0   00.0   00.0
>
>      ... should be:
>
>         # dlstat show                                                   
>         LINK     IPKTS IBYTES OPKTS  OBYTES  UTIL
>         e1000g0  21.2K   2.1M  0.5K   44.2M  0.0%
>         ixgbe0   24.5M  13.6G  3.5M    0.1G  0.0%
>         vnic1     0.0M   0.0M  0.0M    0.0M  0.0%
>
>      Note in particular that every value should have a unit and the units
>      or interpretation of the data should live with the data itself, not
>      with the field header.  Again, the ofmt API will generally encourage
>      the right thing here (though there''s addditional work that
really
>      should be done to simplify API consumers, such as 6800985).
I have changed manpage examples to follow output formatting as suggested 
above.
>
>    * If we want to support an additional output mode like
"full-screen"
>      mode, that should also be handled by the ofmt facility rather than
>      special-cased into dlstat.  Likewise for "kstat mode" (but
see
>      below).
Will check how ofmt api could be extended to support full-screen and kstat
mode.
>    * It''s not clear to me why we need both "kstat mode"
and "full-screen"
>      mode.  If we do need to keep both, I''d be inclined to use
"-k" for
>      kstat mode rather than "-v".
Am fine with -k as well (Changed in the man page).

Full screen mode will update information live by overprinting (like prstat).
Number of fields would thus have 80 character constraint.

On the other hand, kstat mode would be one-stop shop for all dynamic 
data link stats
that are available.
>
>    * The "+output" thing is clever but it''d be odd for
this command to
>      support it and dladm/flowadm/ipmpstat to not support it.  It should
>      also be not allowed in parsable output mode since the caller should
>      never rely on the default output mode (since it can change).
I added a note in parseable mode description that it is not compatible 
with -o - or -o +.

If -o -/+ appears useful, how about implementing that in dlstat for now. 
We could think
of adding similar support to other commands in future?


~ Shri
>
> --
> meem
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dlstat.1m.txt
URL:
<http://mail.opensolaris.org/pipermail/crossbow-discuss/attachments/20090316/310d6eee/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dladm.1m.txt
URL:
<http://mail.opensolaris.org/pipermail/crossbow-discuss/attachments/20090316/310d6eee/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.dladm.1m.txt
URL:
<http://mail.opensolaris.org/pipermail/crossbow-discuss/attachments/20090316/310d6eee/attachment-0002.txt>

> >    * It''s not clear to me why we need both "kstat
mode" and "full-screen"
 > >      mode.  If we do need to keep both, I''d be inclined to
use "-k" for
 > >      kstat mode rather than "-v".
 > Am fine with -k as well (Changed in the man page).
 > 
 > Full screen mode will update information live by overprinting (like
prstat).
 > Number of fields would thus have 80 character constraint.
 > 
 > On the other hand, kstat mode would be one-stop shop for all dynamic 
 > data link stat that are available.

Who would use this kstat information?  Phrased differently, with a few
exceptions, kstats are not intended to be a stable interface, so I''m
wondering about the audience and intent.

 > >    * The "+output" thing is clever but it''d be odd
for this command to
 > >      support it and dladm/flowadm/ipmpstat to not support it.  It
should
 > >      also be not allowed in parsable output mode since the caller
should
 > >      never rely on the default output mode (since it can change).
 > I added a note in parseable mode description that it is not compatible 

I presume the (future) command itself will also produce an error.

 > with -o - or -o +.
 > 
 > If -o -/+ appears useful, how about implementing that in dlstat for
 > now.  We could think of adding similar support to other commands in
 > future?

With the ofmt API, I think it will end up being more work to support this
only in dlstat.  (Further to that, if you find the ofmt API does not meet
dlstat''s needs, then I''m sure Sowmini will be eager to enhance
it :-)

--
meem

Shrikrishna Khare writes:
> To address Jim''s concern regarding how dladm would be
transitioned:
> dladm man page is changed to declare that show-usage, 
> show-{link,aggr,vnic} -s is obsolete. Those commands would continue to 
> work for ''a while'' even after dlstat is integrated (would
post exact
> timeline later).
Can I have a ballpark?  Is it more like a month from now or a year?

The reason I ask is that I have my *own* "show-bridge" subcommand that
I have to look after.  If this is coming soon, then I''ll need to plan
for it.  If it''s only in a "Crossbow Phase 2" (or some such)
ON
integration much further down the road, then I''ll need to plan around
it.

Thanks for adding the details on dladm; this helps.
> >    * It''s not clear to me why we need both "kstat
mode" and "full-screen"
> >      mode.  If we do need to keep both, I''d be inclined to
use "-k" for
> >      kstat mode rather than "-v".
> Am fine with -k as well (Changed in the man page).
I''m a little confused by kstat mode.  What''s the usage of it? 
(Don''t
we already have a usable kstat(1M) command ... ?)
>      The following subcommands are supported:
I assume the majority of these require no special privileges
... right?  If they do require privileges, then that should be noted.
>      dlstat reset [link[,...]]
> 
> 	 Resets the link statistic counters for the specified link(s).
> 	 If invoked without specifying any link, it resets statistics
> 	 for all the links.
I''m nervous about this one.

In general, I think that resetting statistics is a Bad Thing.  It''s in
violation of the Counter semantics for SNMP, which means that we''d at
least have to compute deltas in the kernel for use by this command (so
that we can continue to export non-resetting statistics for things
that require them).  It also makes a fundamental assumption that
there''s only one system administrator, and while that''s
probably true
of a laptop, it''s certainly not true of a large system.  Allowing
statistics to be reset results in surprise for other administrators.

What happens if I do "dlstat reset" while someone else is running one
of the "-i" interval variants of the command?  Does that other user
see a large negative delta or something else?

Part of the point of those "interval" options is to avoid the need for
ever resetting the statistics.  Why is reset necessary?
>      dladm scan-wifi [[-p] -o field[,...]] [wifi-link]
I think this one might need a little more examination, or at least
some explanation.

The "scan-wifi" subcommand actually has two distinct components that
are (a bit unfortunately) rolled into one command.

One part is clearly an administrative command -- telling the driver to
perform a scan right now to interrogate and refresh its list of APs in
range.  The other part is displaying the current scan results.

That latter bit doesn''t seem at all like administration or
configuration to me.  It''s "status" information, which I
think ought
to belong in a status-reporting command like "dlstat."

There are probably also a fair number of read-only linkprop values
that are actually "status" information and not
"configuration," making
this split even less obvious.  "Some" status is still in dladm, but
"other" status information is moving to dlstat.

In any event, I think the line between what goes into dladm and dlstat
isn''t too clear because of the history.  It''d be good to have
a clear
model so that users don''t end up confused.  (As they often do when we
split commands apart -- for example, zoneadm and zonecfg or svcadm and
svccfg.  Even with a fairly clear technical model, users can be
baffled.)

-- 
James Carlson, Solaris Networking              <james.d.carlson at
sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

On (03/16/09 21:34), Peter Memishian wrote:
>  > >    * It''s not clear to me why we need both "kstat
mode" and "full-screen"
>  > >      mode.  If we do need to keep both, I''d be inclined
to use "-k" for
>  > >      kstat mode rather than "-v".
>  > Am fine with -k as well (Changed in the man page).
>  > 
>  > Full screen mode will update information live by overprinting (like
prstat).
>  > Number of fields would thus have 80 character constraint.
>  > 
>  > On the other hand, kstat mode would be one-stop shop for all dynamic 
>  > data link stat that are available.
I am not seeing the purpose of the -k option at all. Some clarification
would be useful to me.
>  > >    * The "+output" thing is clever but it''d
be odd for this command to
>  > >      support it and dladm/flowadm/ipmpstat to not support it. 
It should
>  > >      also be not allowed in parsable output mode since the
caller should
>  > >      never rely on the default output mode (since it can
change).
>  > I added a note in parseable mode description that it is not
compatible
> 
> I presume the (future) command itself will also produce an error.
> 
>  > with -o - or -o +.
>  > 
>  > If -o -/+ appears useful, how about implementing that in dlstat for
>  > now.  We could think of adding similar support to other commands in
>  > future?
> 
> With the ofmt API, I think it will end up being more work to support this
> only in dlstat.  (Further to that, if you find the ofmt API does not meet
> dlstat''s needs, then I''m sure Sowmini will be eager to
enhance it :-)
While it may be clever, I''m not sure the -/+ fields is a good idea for
just
networking commands, unless we do it across the board for all Solaris
commands like ps.

One thing that''s not clear to me from reading the man page:
how is this supposed to work? Lets say that I have dlstat running in one
window with some set of -o flags, how do I signal that process to update
its print-handle state to add/remove fields in the output?

--Sowmini

Sowmini.Varadhan at Sun.COM writes:
> One thing that''s not clear to me from reading the man page:
> how is this supposed to work? Lets say that I have dlstat running in one
> window with some set of -o flags, how do I signal that process to update
> its print-handle state to add/remove fields in the output?
I don''t think that''s how it''s supposed to work.

The +/- thing is just supposed to add or remove columns from the
default.  For example, if the default output of "show-widget" has two
columns labeled "FOO" and "BAR," then "show-widget -o
+baz" will add a
"BAZ" column (presumably to the end of the line), while
"show-widget
-o -foo" will cause it to display only the "BAR" column.

It doesn''t affect any other process that''s running.  (Unlike
the
"reset" subcommand ...)

-- 
James Carlson, Solaris Networking              <james.d.carlson at
sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

James Carlson wrote:
> Sowmini.Varadhan at Sun.COM writes:
> > One thing that''s not clear to me from reading the man page:
> > how is this supposed to work? Lets say that I have dlstat running in
> one
> > window with some set of -o flags, how do I signal that process to
> update
> > its print-handle state to add/remove fields in the output?
> 
> I don''t think that''s how it''s supposed to work.
> 
> The +/- thing is just supposed to add or remove columns from the
> default.  For example, if the default output of "show-widget" has
two
> columns labeled "FOO" and "BAR," then "show-widget
-o +baz" will add a
> "BAZ" column (presumably to the end of the line), while
"show-widget
> -o -foo" will cause it to display only the "BAR" column.
If I might make a suggestion of an alternative to this:

Put in the man page for the command the -o string that can be used to reproduce
the default output (and when options change that default output, give an
equivalent -o string).  That way anyone who wants to make a minor change to the
output can do so based on the man page.

For example:
For /bin/ps the default output is (almost) equivalent to -o pid,tty,time,commm
/bin/ps -Z prints the near equivalent of -o zonename,pid,tty,time,comm

So in show-widget(1M) you''d have:
-o format
	The -o option allows the output format to be specified under 
	user control.  The default output is equivalent to the format
	string "foo,bar".
-l
	The -l option increases the detail given in the output.  It is
	equivalent to specifying the format string 
	"instanceid,name,foo,bar,baz"

--Joe

> >      dlstat reset [link[,...]]
 > > 
 > > 	 Resets the link statistic counters for the specified link(s).
 > > 	 If invoked without specifying any link, it resets statistics
 > > 	 for all the links.
 > 
 > I''m nervous about this one.
 > 
 > In general, I think that resetting statistics is a Bad Thing. 
It''s in
 > violation of the Counter semantics for SNMP, which means that
we''d at
 > least have to compute deltas in the kernel for use by this command (so
 > that we can continue to export non-resetting statistics for things
 > that require them).  It also makes a fundamental assumption that
 > there''s only one system administrator, and while that''s
probably true
 > of a laptop, it''s certainly not true of a large system.  Allowing
 > statistics to be reset results in surprise for other administrators.

But the stats already get zeroed when the datalink is destroyed, which
could easily happen with dueling admins.

 > >      dladm scan-wifi [[-p] -o field[,...]] [wifi-link]
 > 
 > I think this one might need a little more examination, or at least
 > some explanation.
 > 
 > The "scan-wifi" subcommand actually has two distinct components
that
 > are (a bit unfortunately) rolled into one command.
 > 
 > One part is clearly an administrative command -- telling the driver to
 > perform a scan right now to interrogate and refresh its list of APs in
 > range.  The other part is displaying the current scan results.
 > 
 > That latter bit doesn''t seem at all like administration or
 > configuration to me.  It''s "status" information, which
I think ought
 > to belong in a status-reporting command like "dlstat."

As per the provided manpages, the "stat" in dlstat means
"statistics", not
"status".  I don''t think it makes much sense to have
scan-wifi stuff in
dlstat.

 > There are probably also a fair number of read-only linkprop values
 > that are actually "status" information and not
"configuration," making
 > this split even less obvious.  "Some" status is still in dladm,
but
 > "other" status information is moving to dlstat.

Status vs. statistics seems reasonably clear-cut to me.  There may be
cases where we want to include some statistics in the dladm status output
as a convenience, and there are other cases where statistics mechanisms
have been abused to report status (e.g., the link_up kstat), but I doubt
the overlap is widespread enough to cause confusion.

--
meem

> If I might make a suggestion of an alternative to this:
 > 
 > Put in the man page for the command the -o string that can be used to
 > reproduce the default output (and when options change that default
 > output, give an equivalent -o string).  That way anyone who wants to
 > make a minor change to the output can do so based on the man page.

... or we could just introduce a new special `default'' field (similar
to
the existing `all'' field) that expands the current list of default
fields.

--
meem

Peter Memishian writes:
>  > >      dlstat reset [link[,...]]
>  > > 
>  > > 	 Resets the link statistic counters for the specified link(s).
>  > > 	 If invoked without specifying any link, it resets statistics
>  > > 	 for all the links.
>  > 
>  > I''m nervous about this one.
>  > 
>  > In general, I think that resetting statistics is a Bad Thing. 
It''s in
>  > violation of the Counter semantics for SNMP, which means that
we''d at
>  > least have to compute deltas in the kernel for use by this command
(so
>  > that we can continue to export non-resetting statistics for things
>  > that require them).  It also makes a fundamental assumption that
>  > there''s only one system administrator, and while
that''s probably true
>  > of a laptop, it''s certainly not true of a large system. 
Allowing
>  > statistics to be reset results in surprise for other administrators.
> 
> But the stats already get zeroed when the datalink is destroyed, which
> could easily happen with dueling admins.
That''s different.

When an object is destroyed and a new one created, the new one isn''t
the same as the previous one.  The destroy/create events are unique,
at least for network management.

That''s quite different from seeing a counter roll backwards without
the underlying object having changed.

(It seems that we''re missing anything that would be usable as an
ifIndex at this level, which means that representing this dl* stuff in
SNMP is going to take some work.)

(In case you''re wondering, ifIndex numbers can''t be the same
as
datalink_id_t values, because we [unfortunately] reuse those.  And
ifIndex numbers can''t be reused across a delete/create without having
an "engine reset" event.  It''s a key part of the data model.)
>  > That latter bit doesn''t seem at all like administration or
>  > configuration to me.  It''s "status" information,
which I think ought
>  > to belong in a status-reporting command like "dlstat."
> 
> As per the provided manpages, the "stat" in dlstat means
"statistics", not
> "status".  I don''t think it makes much sense to have
scan-wifi stuff in
> dlstat.
So "netstat" means "network status" but "dlstat"
means "datalink
statistics only"?
>  > There are probably also a fair number of read-only linkprop values
>  > that are actually "status" information and not
"configuration," making
>  > this split even less obvious.  "Some" status is still in
dladm, but
>  > "other" status information is moving to dlstat.
> 
> Status vs. statistics seems reasonably clear-cut to me.  There may be
> cases where we want to include some statistics in the dladm status output
> as a convenience, and there are other cases where statistics mechanisms
> have been abused to report status (e.g., the link_up kstat), but I doubt
> the overlap is widespread enough to cause confusion.
Color me confused.  I really don''t know where to look for information
about data links, and don''t understand why a user would want to draw
this distinction between "status" and "statistics."

-- 
James Carlson, Solaris Networking              <james.d.carlson at
sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

On (03/17/09 11:21), Peter Memishian wrote:
> 
>  > If I might make a suggestion of an alternative to this:
>  > 
>  > Put in the man page for the command the -o string that can be used to
>  > reproduce the default output (and when options change that default
>  > output, give an equivalent -o string).  That way anyone who wants to
>  > make a minor change to the output can do so based on the man page.
> 
> ... or we could just introduce a new special `default'' field
(similar to
> the existing `all'' field) that expands the current list of default
fields.
So far, "-o all" is usually equal to the default output (except for
some
corner cases like show-secobj) and the man page (afaik) does list the
fields emitted for default output. 

--Sowmini

> >  > If I might make a suggestion of an alternative to this:
 > >  > 
 > >  > Put in the man page for the command the -o string that can be
used to
 > >  > reproduce the default output (and when options change that
default
 > >  > output, give an equivalent -o string).  That way anyone who
wants to
 > >  > make a minor change to the output can do so based on the man
page.
 > > 
 > > ... or we could just introduce a new special `default'' field
(similar to
 > > the existing `all'' field) that expands the current list of
default fields.
 > 
 > So far, "-o all" is usually equal to the default output (except
for some
 > corner cases like show-secobj) and the man page (afaik) does list the
 > fields emitted for default output. 

Except that it''s cumbersome to type all that and over time "-o
all" will
be less and less like the default output (since we will invariably add
more fields).

-- 
meem

> That''s quite different from seeing a counter roll backwards
without
 > the underlying object having changed.

Considering that the applications are quite likely unaware that the
underlying object changed (what current mechanism would they use to
track this?), I don''t see much practical difference.

 > (In case you''re wondering, ifIndex numbers can''t be the
same as
 > datalink_id_t values, because we [unfortunately] reuse those.  And
 > ifIndex numbers can''t be reused across a delete/create without
having
 > an "engine reset" event.  It''s a key part of the data
model.)

Don''t forget about SIOCSLIFINDEX :-)

 > > As per the provided manpages, the "stat" in dlstat means
"statistics", not
 > > "status".  I don''t think it makes much sense to
have scan-wifi stuff in
 > > dlstat.
 > 
 > So "netstat" means "network status" but
"dlstat" means "datalink
 > statistics only"?

The duality with "stat" is already widespread; I don''t think
it''s fair
to saddle this proposal with resolving it.

 > >  > There are probably also a fair number of read-only linkprop
values
 > >  > that are actually "status" information and not
"configuration," making
 > >  > this split even less obvious.  "Some" status is still
in dladm, but
 > >  > "other" status information is moving to dlstat.
 > > 
 > > Status vs. statistics seems reasonably clear-cut to me.  There may be
 > > cases where we want to include some statistics in the dladm status
output
 > > as a convenience, and there are other cases where statistics
mechanisms
 > > have been abused to report status (e.g., the link_up kstat), but I
doubt
 > > the overlap is widespread enough to cause confusion.
 > 
 > Color me confused.  I really don''t know where to look for
information
 > about data links, and don''t understand why a user would want to
draw
 > this distinction between "status" and "statistics."

This distinction isn''t new with dlstat; we already had
"show-link" vs.
"show-link -s".  For what it''s worth, I can''t say
I''ve ever found this
confusing, but I trip over zoneadm vs. zonecfg on a regular basis ;-)

--
meem

Peter Memishian writes:
> 
>  > That''s quite different from seeing a counter roll backwards
without
>  > the underlying object having changed.
> 
> Considering that the applications are quite likely unaware that the
> underlying object changed (what current mechanism would they use to
> track this?), I don''t see much practical difference.
Network management applications use an ifIndex to track interfaces.
That we lack one here is a bug, but I don''t think we ought to compound
that problem by adding in Counters that can be reset arbitrarily.

We made that mistake with "netstat -c"; I don''t think we need
to do it
again.
>  > (In case you''re wondering, ifIndex numbers can''t be
the same as
>  > datalink_id_t values, because we [unfortunately] reuse those.  And
>  > ifIndex numbers can''t be reused across a delete/create
without having
>  > an "engine reset" event.  It''s a key part of the
data model.)
> 
> Don''t forget about SIOCSLIFINDEX :-)
Yeah, I know, and as we''ve discussed, that''s totally broken.
>  > > As per the provided manpages, the "stat" in dlstat
means "statistics", not
>  > > "status".  I don''t think it makes much sense
to have scan-wifi stuff in
>  > > dlstat.
>  > 
>  > So "netstat" means "network status" but
"dlstat" means "datalink
>  > statistics only"?
> 
> The duality with "stat" is already widespread; I don''t
think it''s fair
> to saddle this proposal with resolving it.
I think saying "widespread" is unfair.

These two commands are both networking-related, and are about a hair''s
breadth apart.  That they''re substantially different is only going to
add confusion.

Moreover, I *do* think it''s the responsibility of someone proposing a
brand new command to explain how it fits with the others of its ilk.
If it doesn''t fit in with the existing networking commands,
isn''t that
a problem?
>  > Color me confused.  I really don''t know where to look for
information
>  > about data links, and don''t understand why a user would want
to draw
>  > this distinction between "status" and
"statistics."
> 
> This distinction isn''t new with dlstat; we already had
"show-link" vs.
> "show-link -s".  For what it''s worth, I can''t
say I''ve ever found this
> confusing, but I trip over zoneadm vs. zonecfg on a regular basis ;-)
You''re an expert with networking as implemented in Solaris, so I would
expect that you''re not confused about the difference between the
status information proposed to be exposed by dlstat versus dladm, or
the differences between read-only linkprops and kstats, or the other
arcane cruft we''ve accumulated.

I think your confusion over zoneadm versus zonecfg is a good point.
The distinction made perfect sense to the folks on the Kevlar team who
implemented it.  It was perfectly obvious where one feature versus
another would go, and we added features while observing the
distinction.  And yet it *is* confusing to users because to them,
Zones is all one thing, and the idea that "creating" a zone is a
configuration action while "installing" one is administrative is just
baffling.

In our area, we''ve already asked users to make a pretty difficult
distinction between "network layer" (controlled by ifconfig) and
"datalink layer" (controlled by dladm).  I''m a little
concerned that
this one is just a bridge too far.

Maybe the simpler question to ask is this: now that we''ve driven
pretty far down the road in putting statistics and status information
into dladm, and we''ve backported at least some of those things to S10,
what benefit do we get out of taking _some_ of them out and putting
them into a new command?

-- 
James Carlson, Solaris Networking              <james.d.carlson at
sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Peter Memishian wrote:
>  > If I might make a suggestion of an alternative to this:
>  >
>  > Put in the man page for the command the -o string that can be used
> to
>  > reproduce the default output (and when options change that default
>  > output, give an equivalent -o string).  That way anyone who wants to
>  > make a minor change to the output can do so based on the man page.
> 
> ... or we could just introduce a new special `default'' field
(similar
> to
> the existing `all'' field) that expands the current list of default
> fields.
"-o default" is useful if you don''t want to replace any of
the inner columns, only to add columns to the front or back of the existing
output.

Why would a new magic output format token be preferable to simply documenting
the current output format in the man page?  Whether you''re talking
about the -o {+,-}Field or the -o default or the -o all option

--Joe

> > The duality with "stat" is already widespread; I
don''t think it''s fair
 > > to saddle this proposal with resolving it.
 > 
 > I think saying "widespread" is unfair.

Looking at snv_107, I see 35 that end in "stat".  Of those, 21 use it
to
mean "statistics" and 11 use it to mean "status" (3 others
are outliers
that use it to mean neither).  I''d consider that a widespread split.

-- 
meem

> "-o default" is useful if you don''t want to replace any
of the inner
 > columns, only to add columns to the front or back of the existing
 > output.
 > 
 > Why would a new magic output format token be preferable to simply
 > documenting the current output format in the man page?

We generally do document it, but it''s tedious to use it that way.

-- 
meem

Peter Memishian writes:
> 
>  > > The duality with "stat" is already widespread; I
don''t think it''s fair
>  > > to saddle this proposal with resolving it.
>  > 
>  > I think saying "widespread" is unfair.
> 
> Looking at snv_107, I see 35 that end in "stat".  Of those, 21
use it to
> mean "statistics" and 11 use it to mean "status" (3
others are outliers
> that use it to mean neither).  I''d consider that a widespread
split.
Many of those are things like "cpustat" and "auditstat" --
things that
have nothing to do with networking.

"netstat" refers to the TCP/IP network layer, and "dlstat"
seems to
refer to the TCP/IP datalink layer.

How much more related could they get?

How about "ipmpstat" ... which displays IPMP _status_?

I realize a word means what the project team says it means, no more
and no less, but varying the meaning within a given domain (such as
"networking") seems to me like an unwise thing to do.

Popping back up to the original issue, which I certainly do *not* see
as the correct transliteration of "stat," I think the split proposed
for some status variables (those called "statistics," but perhaps not
all of what a user might call "statistics") to be put into one command
and the rest in another is confusing.

I believe that most users will just inevitably end up invoking both of
them to try to figure out what the system is doing, and will curse us
for splitting things along lines that appear to refer to
implementation specifics (kstat versus linkprop) and have essentially
nothing at all to do with the way the commands are actually *used*.

Thus, I''ve asked what it buys us.  That''s what''s
unclear.

-- 
James Carlson, Solaris Networking              <james.d.carlson at
sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

> How about "ipmpstat" ... which displays IPMP _status_?
No way ;-)

 > Popping back up to the original issue, which I certainly do *not* see
 > as the correct transliteration of "stat," I think the split
proposed
 > for some status variables (those called "statistics," but
perhaps not
 > all of what a user might call "statistics") to be put into one
command
 > and the rest in another is confusing.

I''d also prefer this functionality to remain in dladm, though I do
worry
about its growing bloat (e.g., folding the proposed dlstat manpage into
dladm would produce quite a beast).  However, I think if we decide to fork
it off, dlstat is the correct name based on decades of precedence, though
I suppose "dlstats" would also be viable.

-- 
meem

Peter Memishian writes:
> 
>  > How about "ipmpstat" ... which displays IPMP _status_?
> 
> No way ;-)
My point being that existing practice in networking is contrary to
what is being proposed here.
>  > Popping back up to the original issue, which I certainly do *not* see
>  > as the correct transliteration of "stat," I think the split
proposed
>  > for some status variables (those called "statistics," but
perhaps not
>  > all of what a user might call "statistics") to be put into
one command
>  > and the rest in another is confusing.
> 
> I''d also prefer this functionality to remain in dladm, though I do
worry
> about its growing bloat (e.g., folding the proposed dlstat manpage into
> dladm would produce quite a beast).  However, I think if we decide to fork
> it off, dlstat is the correct name based on decades of precedence, though
> I suppose "dlstats" would also be viable.
Maybe the perception of "bloat" could be handled more effectively by
applying some old-fashioned software engineering to the task, and not
having everything crammed cheek-by-jowl into a single "dladm.c" file.

The data link layer is complicated and getting more so with time.  I
don''t think it''s surprising that having a unified tool to
manage it (a
path we''ve _explicitly_ chosen over having per-technology tools)
results in a tool that is itself complex.  Or at least "feature rich."

-- 
James Carlson, Solaris Networking              <james.d.carlson at
sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

> Maybe the perception of "bloat" could be handled more effectively
by
 > applying some old-fashioned software engineering to the task, and not
 > having everything crammed cheek-by-jowl into a single "dladm.c"
file.

While the implementation is also bloated, my concern was really more
around the documentation and user interface.  (That said, regarding the
implementation: dladm.c *should* be a simple marshalling layer, leaving
all the heavy lifting to libdladm and the like.  The fact that it''s not
points to poor code factoring.)  For instance, if the administrative model
for statistics is fundamentally different than for other datalink-layer
tasks, (e.g. growing to be as fully-featured as lockstat''s option set),
then I think there''s merit to moving it out to its own command.

--
meem

On 03/18/09 14:54, Peter Memishian wrote:
>  > Maybe the perception of "bloat" could be handled more
effectively by
>  > applying some old-fashioned software engineering to the task, and not
>  > having everything crammed cheek-by-jowl into a single
"dladm.c" file.
> 
> While the implementation is also bloated, my concern was really more
> around the documentation and user interface.  (That said, regarding the
> implementation: dladm.c *should* be a simple marshalling layer, leaving
> all the heavy lifting to libdladm and the like.  The fact that
it''s not
> points to poor code factoring.)  For instance, if the administrative model
> for statistics is fundamentally different than for other datalink-layer
> tasks, (e.g. growing to be as fully-featured as lockstat''s option
set),
> then I think there''s merit to moving it out to its own command.
Yes & Yes. libdladm should do the heavy lifting and the synopsis for
dlstat is just a start so makes sense to keep it separate. The dladm
man page is already getting pretty big and there is more to come
there as well.

Cheers,
Sunay

Peter Memishian writes:
> 
>  > Maybe the perception of "bloat" could be handled more
effectively by
>  > applying some old-fashioned software engineering to the task, and not
>  > having everything crammed cheek-by-jowl into a single
"dladm.c" file.
> 
> While the implementation is also bloated, my concern was really more
> around the documentation and user interface.
So, as a user, which would you rather see?

 (a) a single command that does everything related to datalinks.

 (b) one command that sets and displays datalink configuration as well
     as some datalink status, plus a separate command that displays
     other parts of the datalink status information.

or:

 (c) one command for each type of datalink (one for standard
     Ethernets, another for wireless Ethernet, another for
     aggregations, another for stubs, and so on), but where each
     per-type command has all admin and status options.

If we need to break up option (a) because we now consider it a bad
idea (even though it hasn''t been that long that it was all merged that
way), it''s unclear to me whether users would be happier with (b) as
proposed with this project or (c).  In fact, I think they might like
(c) better, just because it''s more similar to other operating systems.
>  (That said, regarding the
> implementation: dladm.c *should* be a simple marshalling layer, leaving
> all the heavy lifting to libdladm and the like.  The fact that
it''s not
> points to poor code factoring.)  For instance, if the administrative model
> for statistics is fundamentally different than for other datalink-layer
> tasks, (e.g. growing to be as fully-featured as lockstat''s option
set),
> then I think there''s merit to moving it out to its own command.
I still don''t follow.  Is the concern just the size of the man page?
The number of subcommands?  Or something else?

If it''s the number of subcommands, those aren''t growing too
fast, at
least due to anything because of statistics.  They''re growing because
we have a blossoming number of datalink objects that need to be
administered.  This architectural change won''t address the underlying
problem.

If it''s the size of the man page, then let''s find a way to
factor out
the documentation nicely.  Perhaps there should be a top-level man
page that talks about the families of datalinks, the subcommands
peculiar to each, and then points to different pages
("dladm_wifi(1M)") for the details on those subcommands -- just as is
done with file systems.

It still seems to me that this new "dlstat" command is being driven
mostly from the internal design of the system, and not from anything
about how users actually interact with the system.

-- 
James Carlson, Solaris Networking              <james.d.carlson at
sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

On 18/03/09 07:19 PM, James Carlson wrote:
> Peter Memishian writes:
>   
>>  > Maybe the perception of "bloat" could be handled more
effectively by
>>  > applying some old-fashioned software engineering to the task, and
not
>>  > having everything crammed cheek-by-jowl into a single
"dladm.c" file.
>>
>> While the implementation is also bloated, my concern was really more
>> around the documentation and user interface.
>>     
>
> So, as a user, which would you rather see?
>
>  (a) a single command that does everything related to datalinks.
>
>  (b) one command that sets and displays datalink configuration as well
>      as some datalink status, plus a separate command that displays
>      other parts of the datalink status information.
>
> or:
>
>  (c) one command for each type of datalink (one for standard
>      Ethernets, another for wireless Ethernet, another for
>      aggregations, another for stubs, and so on), but where each
>      per-type command has all admin and status options.
>
> If we need to break up option (a) because we now consider it a bad
> idea (even though it hasn''t been that long that it was all merged
that
> way), it''s unclear to me whether users would be happier with (b)
as
> proposed with this project or (c).  In fact, I think they might like
> (c) better, just because it''s more similar to other operating
systems.
>   
As an input to the design for dladm/dlstat, I''d like to see us
eventually
have the ability to deliver new link protocols through a collection of
lib*.so''s and kernel modules. At that point, the list of built in
commands
and the length of the man page we ship becomes not so interesting as
a design choice. But maybe a new library for a new link protocol isn''t
the right idea if...

It seems the layering here at the link layer needs further thought when
compared with the relative simplicity of adding a new filesystem type
to our existing architecture. Bits get delivered into /usr/lib/fs, new man
pages specific to that filesystem and a kernel module or two. The man
page for mount isn''t cluttered with documentation of ZFS, UFS, PCFS.

Maybe this argues for a similar directory structure for the specific
commands (think dladm_vnic, dladm_wifi, etc) if the goal is to split
up the documentation to make that not such a burden.

Similarly, I think there''s a strong argument for splitting up the
commands
into at least a "show me statistics" and "something-adm",
although it
might mean that we need to deliver dlstat_vnic as well as dladm_vnic.

The existing architecture for filesystems scales well, we could do worse
than implement the equivalent for networking...

Darren

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/crossbow-discuss/attachments/20090318/46ba4911/attachment.html>

> >  > Maybe the perception of "bloat" could be handled more
effectively by
 > >  > applying some old-fashioned software engineering to the task,
and not
 > >  > having everything crammed cheek-by-jowl into a single
"dladm.c" file.
 > > 
 > > While the implementation is also bloated, my concern was really more
 > > around the documentation and user interface.
 > 
 > So, as a user, which would you rather see?
 > 
 >  (a) a single command that does everything related to datalinks.
 > 
 >  (b) one command that sets and displays datalink configuration as well
 >      as some datalink status, plus a separate command that displays
 >      other parts of the datalink status information.
 > or:
 > 
 >  (c) one command for each type of datalink (one for standard
 >      Ethernets, another for wireless Ethernet, another for
 >      aggregations, another for stubs, and so on), but where each
 >      per-type command has all admin and status options.

I''d rather see discussion like this as interesting cases arise.  Having
core administrative functionality centralized under dladm makes sense for
a variety of reasons, e.g., since all datalinks share a common namespace,
it would be at best frustrating to try attempt to create new objects in
that namespace (as many dladm operations do) via commands that did not
have global visibility of that namespace.  Going further, having the
creation logic in one command other core administrative operations in
other commands in another would be similarly problematic.

To be clear, I think there is a reasonable case to have dlstat be part of
dladm (that is, we think that it''s core to administering a datalink). 
But
I also think that a case could be made (and I think it''s up to
Shrikrishna
to make it) that the feature set and intended audience for detailed
statistics is sufficiently divergent from that of dladm that it makes
sense to have a separate command.

--
meem

Peter Memishian wrote:
>  > >  > Maybe the perception of "bloat" could be handled
more effectively by
>  > >  > applying some old-fashioned software engineering to the
task, and not
>  > >  > having everything crammed cheek-by-jowl into a single
"dladm.c" file.
>  > > 
>  > > While the implementation is also bloated, my concern was really
more
>  > > around the documentation and user interface.
>  > 
>  > So, as a user, which would you rather see?
>  > 
>  >  (a) a single command that does everything related to datalinks.
>  > 
>  >  (b) one command that sets and displays datalink configuration as
well
>  >      as some datalink status, plus a separate command that displays
>  >      other parts of the datalink status information.
>  > or:
>  > 
>  >  (c) one command for each type of datalink (one for standard
>  >      Ethernets, another for wireless Ethernet, another for
>  >      aggregations, another for stubs, and so on), but where each
>  >      per-type command has all admin and status options.
> 
> I''d rather see discussion like this as interesting cases arise. 
Having
> core administrative functionality centralized under dladm makes sense for
> a variety of reasons, e.g., since all datalinks share a common namespace,
> it would be at best frustrating to try attempt to create new objects in
> that namespace (as many dladm operations do) via commands that did not
> have global visibility of that namespace.  Going further, having the
> creation logic in one command other core administrative operations in
> other commands in another would be similarly problematic.
> 
> To be clear, I think there is a reasonable case to have dlstat be part of
> dladm (that is, we think that it''s core to administering a
datalink).  But
> I also think that a case could be made (and I think it''s up to
Shrikrishna
> to make it) that the feature set and intended audience for detailed
> statistics is sufficiently divergent from that of dladm that it makes
> sense to have a separate command.
> 
Guys,

I think we are at the end of useful discussion on this particular topic.
Would appreciate if the discussion can continue around what more
functionality we can provide to help our users. I don''t think
Shrikrishna trying to make a case on whether we extend dladm or create
dlstat is going to be best use of anyones time. Subjective debates are
just that - subjective!

Would love to have one command to manage all Solaris so I don''t have to
remember anything else but that won''t be possible. I can repeat what I
said before i.e. dladm is already getting cumbersome and there is more
to come. And the current incarnation for dlstat is not the end of it.
There is more to come there as well. Again, dladm is to make config
changes while dlstat is to observe what the system is doing.

Jim, your opinion has been duly noted. Does anyone else have any opinion
on extending dladm with functionality mentioned in synopsis for dlstat
or keeping the functionality in new command (called dlstat for now)?

Cheers,
Sunay

Peter Memishian writes:
> To be clear, I think there is a reasonable case to have dlstat be part of
> dladm (that is, we think that it''s core to administering a
datalink).  But
> I also think that a case could be made (and I think it''s up to
Shrikrishna
> to make it) that the feature set and intended audience for detailed
> statistics is sufficiently divergent from that of dladm that it makes
> sense to have a separate command.
And I''m concerned that we''re doing this for reasons that are
apparent
only to us as developers, and not at all obvious to anyone else.
Things like that tend to cause confusion -- both for users and for
future developers who may not understand how to factor their feature
set into the unusual distinctions we''ve made.

-- 
James Carlson, Solaris Networking              <james.d.carlson at
sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Sowmini.Varadhan at Sun.COM wrote:
> On (03/16/09 21:34), Peter Memishian wrote:
>>  > >    * It''s not clear to me why we need both
"kstat mode" and "full-screen"
>>  > >      mode.  If we do need to keep both, I''d be
inclined to use "-k" for
>>  > >      kstat mode rather than "-v".
>>  > Am fine with -k as well (Changed in the man page).
>>  > 
>>  > Full screen mode will update information live by overprinting
(like prstat).
>>  > Number of fields would thus have 80 character constraint.
>>  > 
>>  > On the other hand, kstat mode would be one-stop shop for all
dynamic
>>  > data link stat that are available.
>
> I am not seeing the purpose of the -k option at all. Some clarification
> would be useful to me.
>
Think I did not explain it well.

There are too many fields to fit in 80 column width. E.g. there are 18 
rx specific
fields listed in this dlstat man page itself. Number of fields are 
further likely
to increase in future.

Thus, full screen mode would not be of much use for somebody interested 
in all
(or large number of fields). Hence the kstat style option.
>>  > >    * The "+output" thing is clever but
it''d be odd for this command to
>>  > >      support it and dladm/flowadm/ipmpstat to not support
it.  It should
>>  > >      also be not allowed in parsable output mode since the
caller should
>>  > >      never rely on the default output mode (since it can
change).
>>  > I added a note in parseable mode description that it is not
compatible
>>
>> I presume the (future) command itself will also produce an error.
>>
>>  > with -o - or -o +.
>>  > 
>>  > If -o -/+ appears useful, how about implementing that in dlstat
for
>>  > now.  We could think of adding similar support to other commands
in
>>  > future?
>>
>> With the ofmt API, I think it will end up being more work to support
this
>> only in dlstat.  (Further to that, if you find the ofmt API does not
meet
>> dlstat''s needs, then I''m sure Sowmini will be eager
to enhance it :-)
>
> While it may be clever, I''m not sure the -/+ fields is a good idea
for just
> networking commands, unless we do it across the board for all Solaris
> commands like ps.
>
> One thing that''s not clear to me from reading the man page:
> how is this supposed to work? Lets say that I have dlstat running in one
> window with some set of -o flags, how do I signal that process to update
> its print-handle state to add/remove fields in the output?
>
> --Sowmini
>
>

> There are too many fields to fit in 80 column width. E.g. there are 18
 > rx specific fields listed in this dlstat man page itself. Number of
 > fields are further likely to increase in future.
 > 
 > Thus, full screen mode would not be of much use for somebody interested
 > in all (or large number of fields). Hence the kstat style option.

OK, I think the confusion comes from using kstat as the example; this
seems to just be a row-per-field (as opposed to row-per-object) human-only
output mode.  I think this has merit though I''d hope for that for most
commands we can generally encourage row-per-object as it''s more compact
and provides a more obvious organization of the data.  That said, the ofmt
API that Sowmini recent integrated should be able to be extended to
support this with minimal effort.

-- 
meem

Peter Memishian writes:
> 
>  > There are too many fields to fit in 80 column width. E.g. there are
18
>  > rx specific fields listed in this dlstat man page itself. Number of
>  > fields are further likely to increase in future.
>  > 
>  > Thus, full screen mode would not be of much use for somebody
interested
>  > in all (or large number of fields). Hence the kstat style option.
> 
> OK, I think the confusion comes from using kstat as the example; this
> seems to just be a row-per-field (as opposed to row-per-object) human-only
> output mode.  I think this has merit though I''d hope for that for
most
> commands we can generally encourage row-per-object as it''s more
compact
> and provides a more obvious organization of the data.  That said, the ofmt
> API that Sowmini recent integrated should be able to be extended to
> support this with minimal effort.
That answers most of my questions about this mode as well, I think.

It''s not clear whether it really needs to be strictly kstat-
compatible (which is how I read it), or even row-per-field to be
useful in this way.  Having a human-readable page-oriented output
format that allows for the display of large numbers of values would
probably be a good thing.  The two-column style of "netstat -s" might
be viable.

-- 
James Carlson, Solaris Networking              <james.d.carlson at
sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

> 
 > That answers most of my questions about this mode as well, I think.
 > 
 > It''s not clear whether it really needs to be strictly kstat-
 > compatible (which is how I read it), or even row-per-field to be
 > useful in this way.  Having a human-readable page-oriented output
 > format that allows for the display of large numbers of values would
 > probably be a good thing.  The two-column style of "netstat -s"
might
 > be viable.

Agreed.  Ideally, ofmt would automatically determine how best to format
based on the available screen width (which it knows).

-- 
meem

On (03/23/09 14:25), Peter Memishian wrote:
> 
> Agreed.  Ideally, ofmt would automatically determine how best to format
> based on the available screen width (which it knows).
but this leads to a certain amount of unpredictability in the output.
As long as that constraint is acceptable ofmt has the information
to do this today.

--Sowmini

> > Agreed.  Ideally, ofmt would automatically determine how best to
format
 > > based on the available screen width (which it knows).
 > 
 > but this leads to a certain amount of unpredictability in the output.
 > As long as that constraint is acceptable ofmt has the information
 > to do this today.

The output is only for human use so I think it should be OK.

-- 
meem

Bcc''ed to networking discuss.


  Please find flowstat man page, modified flowadm and flowadm man page 
diff at:

http://cr.opensolaris.org/~shri.k/

  Flowstat manpage is heavily borrowed from dlstat manpage as flows 
would have dedicated hardware rings in future. Till that support is in 
place, fields like poll count could continue to print 0.

  Earlier, dlstat proposal used -l for s/w lanes and -L for h/w lanes. 
However, in order to be consistent with flowadm, flowstat should use -l 
for links. I have thus written flowstat synopsis to use -s for s/w lanes 
and -h for h/w lanes. For consistency, I have changed dlstat man page to 
use -s and -h as well.

  Moreover, to address concerns regarding resetting of stats:
    
  How about continuing to support dlstat/flowstat reset but provide a 
/clock_t lbolt/ that would denote ''time since last reset''.
Depending on
one''s requirement, one can then ascertain credibility of stats by 
looking at this value.


~ Shri


Shrikrishna Khare wrote:
> (Bcc''ed to networking discuss).
>
> Hi All,
>
>     Have enclosed man page draft for dlstat(1M) herewith.
>
>     This is part of the effort to gain better visibility into network
traffic in light of crossbow features like virtual NICs, interrupt vs. polling
modes etc. This in turn would greatly assist network performance analysis. It is
also aimed at segregating link/flow configuration from dynamic network
statistics.
>
> In particular,
>
> - dladm/flowadm would retain configuration specific commands for
links/flows while dlstat/flowstat would provide interfaces for displaying
dynamic network statistics.
>
> - show-usage would be removed from dladm/flowadm and would become part of
dlstat/flowstat. It would be renamed show-history.
>
> - Rich set of counters would be available for performance analysis e.g.
poll vs. interrupt count, chain sizes, distribution of load across lanes etc.
>
> - In the man page, ''dlstat show'' synopsis is deliberately
spread across multiple lines. First line, dlstat show [-r | -t]...  provides an
easy template for printing most commonly queried statistics. Comprehensive and
flexible approaches follow.
>
> Note: Numbers in examples section of enclosed man page are used to
illustrate output formatting only.
>
>
> ~ Shri
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/crossbow-discuss/attachments/20090330/d689a818/attachment.html>

Shrikrishna Khare writes:
>   Flowstat manpage is heavily borrowed from dlstat manpage as flows 
> would have dedicated hardware rings in future. Till that support is in 
> place, fields like poll count could continue to print 0.
Why not just yank the statistics parts out of flowadm?  Why provide
compatibility, when this command hasn''t been exposed outside of the
unreleased Nevada code?  (I guess part of the question buried here is
whether OpenSolaris builds are "releases," and if so, what kind they
are.  I don''t know the answer to that.)

For what it''s worth, I see fewer problems with breaking up this
command than with dladm.  The bits left behind in flowadm (apart from
the deprecated ones) are clearly not status information.
>   How about continuing to support dlstat/flowstat reset but provide a 
> /clock_t lbolt/ that would denote ''time since last
reset''. Depending on
> one''s requirement, one can then ascertain credibility of stats by 
> looking at this value.
That still doesn''t satisfy SNMP Counter rules.

Why are we providing destructive functions (like counter reset) at
all?  Interval output works fine everywhere else in the system, and
for those not using interval output, simple arithmetic works.

-- 
James Carlson, Solaris Networking              <james.d.carlson at
sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

James Carlson wrote:
> Shrikrishna Khare writes:
>>   Flowstat manpage is heavily borrowed from dlstat manpage as flows 
>> would have dedicated hardware rings in future. Till that support is in 
>> place, fields like poll count could continue to print 0.
> 
> Why not just yank the statistics parts out of flowadm?  Why provide
> compatibility, when this command hasn''t been exposed outside of
the
> unreleased Nevada code?  (I guess part of the question buried here is
> whether OpenSolaris builds are "releases," and if so, what kind
they
> are.  I don''t know the answer to that.)
I am kind of agreeing with this. We put back something in Nevada and
we want to change that now. I don''t think Solaris express is considered
a release so you can just yank out the stats from flowadm adn dladm
and make them available only via respective *stat commands.

Now it would be nice if the June OpenSolaris release can go out with
the correct behaviour. Perhaps swing by your friendly C-team and
Opensoalris release team and see if they can pull the changes necessary
in Opensolaris release train or if they can offer better suggestions.
Dave Comay and John Beck would be good starting points.

Cheers,
Sunay