ss: display pacing_rate/max_pacing_rate

Since linux-3.15, kernel exports tcpi_pacing_rate and
tcpi_max_pacing_rate in tcp_info

Add TCP pacing_rate information on ss -i output :

lpaa23:~# ./ss -ti dst 10.246.7.151
State      Recv-Q Send-Q   Local Address:Port       Peer Address:Port
ESTAB      0      325800    10.246.7.151:57614
10.246.7.152:46811
	 cubic wscale:7,7 rto:201 rtt:0.081/0.006 mss:1448 cwnd:90 ssthresh:63
send 12871.1Mbps pacing_rate 15397.8Mbps unacked:90 retrans:0/305
rcv_space:29200

If SO_MAX_PACING_RATE is set on the socket, we add /max_pacing_rate as
in :

... pacing_rate 1570.5Mbps/2.0Gbps ...

Signed-off-by: Eric Dumazet <edumazet@google.com>
do not exit silently when link is not found

When we create a tunnel on top of a link and the link specified
in cmdline doesn't exist, an error message should be shown.

Cc: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
bridge: Make filter_index match in signedness

Michael Tautschnig wrote:

During a rebuild [...]. Please note that we use our research
compiler tool-chain (using tools from the cbmc package), which permits extended
reporting on type inconsistencies at link time.

[...]
gcc   bridge.o fdb.o monitor.o link.o mdb.o vlan.o ../lib/libnetlink.a ../lib/libutil.a  ../lib/libnetlink.a ../lib/libutil.a -o bridge
file link.c line 18: error: conflicting types for variable "filter_index"
old definition in module fdb file fdb.c line 29
signed int
new definition in module link file link.c line 18
unsigned int
<builtin>: recipe for target 'bridge' failed
make[3]: *** [bridge] Error 64
make[3]: Leaving directory '/srv/jenkins-slave/workspace/sid-goto-cc-iproute2/iproute2-3.14.0/bridge'
Makefile:45: recipe for target 'all' failed

While practical constraints may limit the value of filter_index to remain within
the bounds of a positive signed int, there is certainly no such guarantee here.
Also, a plain majority vote suggests that this really just a wrong declaration
in link.c as several declarations of filter_index as signed int exist.

[...]

My followup on this was:

I think the majority is wrong.

filter_index is assigned exclusively from if_nametoindex or ll_name_to_index
which both return unsigned int.

Changing it to unsigned everywhere seems better.

This has been minimally tested by using the bridge tool
to add vids and showing available vids on different devices.

Reported-by: Michael Tautschnig <mt@debian.org>
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
fq: allow options of fair queue set to ~0U

Some options of fair queue cannot be (~0U). It leads to maxrate
cannot be reset to unlimited because it cannot be (~0U). Allow
the options being ~0U.

Tested by the following command:
 # tc qdisc add dev eth4 root handle 1: fq limit 2000 flow_limit 200 maxrate 100mbit quantum 2000 initial_quantum 1600
 # tc -s -d qdisc show
qdisc fq 1: dev eth4 root refcnt 2 limit 2000p flow_limit 200p buckets 1024 quantum 2000 initial_quantum 1600 maxrate 100Mbit
 Sent 1492 bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  1 flows (0 inactive, 0 throttled)
  0 gc, 0 highprio, 0 throttled

 # tc qdisc change dev eth4 root handle 1: fq limit 4294967295 flow_limit 4294967295 maxrate 34359738360 quantum 4294967295 initial_quantum 4294967295
 # tc -s -d qdisc show
qdisc fq 1: dev eth4 root refcnt 2 limit 4294967295p flow_limit 4294967295p buckets 1024 quantum 4294967295 initial_quantum 4294967295
 Sent 38372 bytes 216 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  2 flows (1 inactive, 0 throttled)
  0 gc, 2 highprio, 7 throttled

Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
iproute2: arpd: use ll_addr_a2n and ll_addr_n2a

Signed-off-by: Jiri Pirko <jiri@resnulli.us>
iproute2: utils: change hexstring_n2a and hexstring_a2n to do not work with ":"

Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Update to current net-next kernel headers

Update sanitized headers
Add support to configure SR-IOV VF minimum and maximum Tx rate through ip tool

o "min_tx_rate" option has been added for minimum Tx rate. Hence, for
  consistent naming, "max_tx_rate" option has been introduced for maximum
  Tx rate.

o Change in v2: "rate" can be used along with "max_tx_rate".
  When both are specified, "max_tx_rate" should override.

o Change in v3:
  * IFLA_VF_RATE: When IFLA_VF_RATE is used, and user has given only one of
    min_tx_rate or max_tx_rate, reading of previous rate limits is done in
    userspace instead of in kernel space before ndo_set_vf_rate.

  * IFLA_VF_TX_RATE: When IFLA_VF_TX_RATE is used, min_tx_rate is always read
    in kernel space. This takes care of below scenarios:
    (1) when old tool sends "rate" but kernel is new (expects min and max)
    (2) when new tool sends only "rate" but kernel is old (expects only "rate")

o Change in v4 as suggested by Stephen Hemminger:
  * As per iproute policy, input and output formats should match. Changing display
    of max_tx_rate and min_tx_rate options accordingly.
	./ip/ip link show p3p1
	8: p3p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
        link/ether 00:0e:1e:16:ce:40 brd ff:ff:ff:ff:ff:ff
        vf 0 MAC 2a:18:8f:4d:3d:d4, tx rate 700 (Mbps), max_tx_rate 700Mbps, min_tx_rate 200Mbps
        vf 1 MAC 72:dc:ba:f9:df:fd

Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
bridge: Add master device name to bridge fdb show

This patch adds master dev name from NDA_MASTER netlink attribute
 to bridge fdb show output

current iproute2 tries to print 'master' in the output if NTF_MASTER
is present. But, kernel today does not set NTF_MASTER during dump
requests. Which means I have not seen iproute2 bridge cmd print 'master' atall.
This patch overrides the NTF_MASTER flag if NDA_MASTER attribute is present.

Example output:

before this patch:
# bridge fdb show
44:38:39:00:27:ba dev bond2.2003 permanent
44:38:39:00:27:bb dev bond4.2003 permanent
44:38:39:00:27:bc dev bond2.2004 permanent

After this patch:
# bridge fdb show
44:38:39:00:27:ba dev bond2.2003 master br-2003 permanent
44:38:39:00:27:bb dev bond4.2003 master br-2003 permanent
44:38:39:00:27:bc dev bond2.2004 master br-2004 permanent

For comparision with the above, below is the output for NTF_SELF today,
# bridge fdb show
33:33:00:00:00:01 dev eth0 self permanent
01:00:5e:00:00:01 dev eth0 self permanent
33:33:ff:00:01:cc dev eth0 self permanent

If change in output is a concern, 'master' can be put at the end of the fdb
output line or made optional with -d[etails] option.

change from v1 to v2:
    use 'bridge' instead of 'master' in fdb show output

change from v2 to v3:
    use 'master' instead of 'bridge' in fdb show output
    (master could also be a vxlan device)

Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
v3.15.0
Merge branch 'net-next'
Update kernel headers to 3.16-rc5
ip: add paren to silence warning

Gcc doesn't like mixed || and && in same conditional.
ip: check for missing dev arg when doing VF rate

New VF rate code was not handling case where device not specified.
Caught by GCC warning about uninitialized variable.
ip: add nlmon as a device type to help message

Though nlmon device can be added, it was not listed
in the output of "ip link help".

Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Acked-by: Daniel Borkmann <dborkman@redhat.com>
ip: Added missing usage for netconf object
man: token: fix couple of typos

Not sure how these typos slipped in back then, I suspect
too much coffee. ;) So lets fix them up properly.

Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
ipnetns: fixed typo "seting" -> "setTing"

Signed-off-by: Vasily Averin <vvs@openvz.org>
fix ip tunnel for vti tunnels with ikey

Consider the following command:

ip tunnel add mode vti remote 12.0.0.1 local 12.0.0.3 ikey 15

i_flags will be GRE_KEY|VTI_ISVTI. So, in order to distinguish between ipip and
vti we have to check just VTI_ISVTI bit, not the equality of i_flags and
VTI_ISVTI.

* Note, that there also was a bug in ip_tunnel/ip_vti, see
commit 7c8e6b9c281(ip_vti: Fix 'ip tunnel add' with 'key' parameters),
https://lkml.org/lkml/2014/6/7/125.
Even patched iproute could be unable to create vti tunnels with non-zero keys.

1) Unpatched iproute2:
[root@vm ~]# ip tunnel show
[root@vm ~]# lsmod | egrep '(ipip|vti)'
[root@vm ~]# ip tunnel add mode vti ikey 1
[root@vm ~]# lsmod | egrep '(ipip|vti)'
ipip                    4197  0 
tunnel4                 1659  1 ipip
ip_tunnel               9295  1 ipip
[root@vm ~]# ip tunnel show
tunl0: ip/ip  remote any  local any  ttl inherit
[root@vm ~]# ip tunnel add mode vti remote 1.2.3.4 ikey 2
[root@vm ~]# ip tunnel show
ipip0: ip/ip  remote 1.2.3.4  local any  ttl inherit 
tunl0: ip/ip  remote any  local any  ttl inherit 
[root@vm ~]# lsmod | egrep '(ipip|vti)'
ipip                    4197  0 
tunnel4                 1659  1 ipip
ip_tunnel               9295  1 ipip

# ipip tunnels are created instead of vti

2) Patched iproute2:
[root@vm ~]# ip tunnel show
[root@vm ~]# lsmod | egrep '(ipip|vti)'
[root@vm ~]# ip tunnel add mode vti ikey 1
[root@vm ~]# lsmod | egrep '(ipip|vti)'
ip_vti                  5258  0 
ip_tunnel               9295  1 ip_vti
[root@vm ~]# ip tunnel show
vti0: ip/ip  remote any  local any  ttl inherit  ikey 1  okey 0 
ip_vti0: ip/ip  remote any  local any  ttl inherit  nopmtudisc key 0
[root@vm ~]# ip tunnel add mode vti remote 1.2.3.4 ikey 2
[root@vm ~]# ip tunnel show
vti0: ip/ip  remote any  local any  ttl inherit  ikey 1  okey 0
vti1: ip/ip  remote 1.2.3.4  local any  ttl inherit  ikey 2  okey 0 
ip_vti0: ip/ip  remote any  local any  ttl inherit  nopmtudisc key 0

# Vti tunnels are created as expected
# * If you have unpatched kernel your vti tunnels will have ikey == okey == 0

Same story exists with ip tunnel show/del with non-zero [io]key: requests are 
routed to tunl0 instead of ip_vti0.


Signed-off-by: Dmitry Popov <ixaphire@qrator.net>
iplink: macvtap: fix man page

This patch adds description about macvtap to ip-link.8 man page.

Signed-off-by: Rami Rosen <ramirose@gmail.com>