IAM ====== Name: dlstat and flowsat Submitter: Shrikrishna Khare Owner: Kais Belgaied Interest: shrikrishna.khare@sun.com Status: submitted Exposure: open SUMMARY ======= We propose to provide new commands to monitor dynamic network traffic statistics viz. dlstat(1M) and flowstat(1M). This is part of the effort to gain better visibility into network traffic in the light of crossbow features like virtual NICs, interrupt vs. polling modes etc. This would greatly assist network performance analysis. It is also aimed at segregating link/flow configuration interface from the interface for querying for dynamic network statistics. ISSUES ============ seb-1 I don't see an obvious benefit of splitting up dlstat and flowstat. Why would dlstat instead not have a mode whereby it prints flow statistics given that flows can't accumulate statistics unless they're associated with a datalink. IMO, introducing two closely-interrelated commands with almost identical command-lines and overall operation is not necessary. I don't feel religious about it, but would like to hear the opinions on this. seb-2 There is seemingly nothing differentiating the first two dlstat usages in the man page. Is it simply the case that -t, -r, and -o are each mutually exclusive? If so, there's probably a way to represent that explicitly in the usage line. seb-3 The use of "-o [+|-]field,..." is confusing to me, and is unlike dladm and flowadm's use of -o to select output fields. A simpler model would be to have a default set of fields, and if -o is used, the caller must specify the complete set of fields needed. This is much less ambiguous. The other advantage to this is that the user's output, when -o is used, will be constant from release to release even if default fields change. seb-4 The "show" subcommand is contrary to the existing convention of using - for subcommands. On a related note, it's unclear that you need any subcommands for these commands given that the whole purpose of the commands is to show statistics. seb-5 What is the intended purpose of the "reset" subcommands? I know _what_ they do, but can't think of a case where this would be useful and not harmful (e.g. by confusing management monitoring tools that expect counters to generally flow uphill). If this has benefitial use, it should probably be surounded by appropriate warnings in documentation. THE NEXT STEP ============= Project team to work on issues.