mirror of
				https://git.proxmox.com/git/mirror_iproute2
				synced 2025-10-31 04:54:30 +00:00 
			
		
		
		
	|  9a25abde3a This commit allows printing the statistics of a broadcast-receiver link
using the same tipc command, but with additional 'link' options:
$ tipc link stat show --help
Usage: tipc link stat show [ link { LINK | SUBSTRING | all } ]
With:
+ 'LINK'      : print the stats of the specific link 'LINK';
+ 'SUBSTRING' : print the stats of all the links having the 'SUBSTRING'
                in name;
+ 'all'       : print all the links' stats incl. the broadcast-receiver
                ones;
Also, a link stats can be reset in the usual way by specifying the link
name in command.
For example:
$ tipc l st sh l br
Link <broadcast-link>
  Window:50 packets
  RX packets:0 fragments:0/0 bundles:0/0
  TX packets:5011125 fragments:4968774/149643 bundles:38402/307061
  RX naks:781484 defs:0 dups:0
  TX naks:0 acks:0 retrans:330259
  Congestion link:50657  Send queue max:0 avg:0
Link <broadcast-link:1001001>
  Window:50 packets
  RX packets:95146 fragments:95040/1980 bundles:1/2
  TX packets:0 fragments:0/0 bundles:0/0
  RX naks:380938 defs:83962 dups:403
  TX naks:8362 acks:0 retrans:170662
  Congestion link:0  Send queue max:0 avg:0
Link <broadcast-link:1001002>
  Window:50 packets
  RX packets:0 fragments:0/0 bundles:0/0
  TX packets:0 fragments:0/0 bundles:0/0
  RX naks:400546 defs:0 dups:0
  TX naks:0 acks:0 retrans:159597
  Congestion link:0  Send queue max:0 avg:0
$ tipc l st sh l 1001002
Link <1001003:data0-1001002:data0>
  ACTIVE  MTU:1500  Priority:10  Tolerance:1500 ms  Window:50 packets
  RX packets:99546 fragments:0/0 bundles:33/877
  TX packets:629 fragments:0/0 bundles:35/828
  TX profile sample:8 packets average:390 octets
  0-64:75% -256:0% -1024:0% -4096:25% -16384:0% -32768:0% -66000:0%
  RX states:488714 probes:7397 naks:0 defs:4 dups:5
  TX states:27734 probes:18016 naks:5 acks:2305 retrans:0
  Congestion link:0  Send queue max:0 avg:0
Link <broadcast-link:1001002>
  Window:50 packets
  RX packets:0 fragments:0/0 bundles:0/0
  TX packets:0 fragments:0/0 bundles:0/0
  RX naks:400546 defs:0 dups:0
  TX naks:0 acks:0 retrans:159597
  Congestion link:0  Send queue max:0 avg:0
$ tipc l st re l broadcast-link:1001002
$ tipc l st sh l broadcast-link:1001002
Link <broadcast-link:1001002>
  Window:50 packets
  RX packets:0 fragments:0/0 bundles:0/0
  TX packets:0 fragments:0/0 bundles:0/0
  RX naks:0 defs:0 dups:0
  TX naks:0 acks:0 retrans:0
  Congestion link:0  Send queue max:0 avg:0
Acked-by: Ying Xue <ying.xue@windriver.com>
Acked-by: Jon Maloy <jmaloy@redhat.com>
Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au>
Signed-off-by: David Ahern <dsahern@gmail.com> | ||
|---|---|---|
| .. | ||
| .gitignore | ||
| bearer.c | ||
| bearer.h | ||
| cmdl.c | ||
| cmdl.h | ||
| link.c | ||
| link.h | ||
| Makefile | ||
| media.c | ||
| media.h | ||
| misc.c | ||
| misc.h | ||
| msg.c | ||
| msg.h | ||
| nametable.c | ||
| nametable.h | ||
| node.c | ||
| node.h | ||
| peer.c | ||
| peer.h | ||
| README | ||
| socket.c | ||
| socket.h | ||
| tipc.c | ||
DESIGN DECISIONS ---------------- HELP ~~~~ --help or -h is used for help. We do not reserve the bare word "help", which for example the ip command does. Reserving a bare word like help quickly becomes cumbersome to handle in the code. It might be simple to handle when it's passed early in the command chain like "ip addr help". But when the user tries to pass "help" further down this requires manual checks and special treatment. For example, at the time of writing this tool, it's possible to create a vlan named "help" with the ip tool, but it's impossible to remove it, the command just shows help. This is an effect of treating bare words specially. Help texts are not dynamically generated. That is, we do not pass datastructures like command list or option lists and print them dynamically. This is intentional. There is always that exception and when it comes to help texts these exceptions are normally neglected at the expence of usability. KEY-VALUE ~~~~~~~~~ All options are key-values. There are both drawbacks and benefits to this. The main drawback is that it becomes more to write for the user and information might seem redundant. The main benefits is scalability and code simplification. Consistency is important. Consider this. 1. tipc link set priority PRIO link LINK 2. tipc link set LINK priority PRIO Link might seem redundant in (1). However, if the command should live for many years and be able to evolve example (2) limits the set command to only work on a single link with no ability to extend. As an example, lets say we introduce grouping on the kernel side. 1. tipc link set priority PRIO group GROUP 2. tipc link set ??? priority PRIO group GROUP 2. breaks, we can't extend the command to cover a group. PARSING ~~~~~~~ Commands are single words. As an example, all words in "tipc link list" are commands. Options are key-values that can be given in any order. In "tipc link set priority PRIO link LINK" "tipc link set" are commands while priority and link are options. Meaning that they can be given like "tipc link set link LINK priority PRIO". Abbreviation matching works for both command and options. Meaning that "tipc link set priority PRIO link LINK" could be given as "tipc l s p PRIO l LINK" and "tipc link list" as "tipc l l". MEMORY ~~~~~~ The tool strives to avoid allocating memory on the heap. Most (if not all) memory allocations are on the stack. RETURNING ~~~~~~~~~ The tool could throw exit() deep down in functions but doing so always seems to limit the program in the long run. So we output the error and return an appropriate error code upon failure.