* Re: [PATCH] switchdev: documentation: fix whitespace issues
From: David Miller @ 2017-05-01 17:53 UTC (permalink / raw)
To: slemieux.tyco; +Cc: jiri, ivecera, netdev
In-Reply-To: <20170501150201.18959-1-slemieux.tyco@gmail.com>
From: Sylvain Lemieux <slemieux.tyco@gmail.com>
Date: Mon, 1 May 2017 11:02:01 -0400
> From: Liam Beguin <lbeguin@tycoint.com>
>
> Figure 1 is full of whitespaces; fix it
>
> Signed-off-by: Liam Beguin <lbeguin@tycoint.com>
> Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
Applied.
^ permalink raw reply
* Re: [PATCH v4 binutils] Add BPF support to binutils...
From: David Miller @ 2017-05-01 17:52 UTC (permalink / raw)
To: aconole; +Cc: ast, daniel, netdev, xdp-newbies
In-Reply-To: <f7ttw541ohz.fsf@redhat.com>
From: Aaron Conole <aconole@bytheb.org>
Date: Mon, 01 May 2017 13:22:00 -0400
> x86-64:
> Running /home/aconole/git/binutils-gdb/gas/testsuite/gas/bpf/bpf.exp ...
> FAIL: jump
> FAIL: call
> FAIL: imm64a
> Running /home/aconole/git/binutils-gdb/gas/testsuite/gas/cfi/cfi.exp ...
I cannot reproduce this, can you show what it says in the:
/home/aconole/git/binutils-gdb/gas/testsuite/gas.log
file near the "FAIL" cases?
^ permalink raw reply
* Re: [PATCH] switchdev: documentation: fix whitespace issues
From: Ivan Vecera @ 2017-05-01 17:50 UTC (permalink / raw)
To: Sylvain Lemieux, jiri; +Cc: netdev
In-Reply-To: <20170501150201.18959-1-slemieux.tyco@gmail.com>
On 1.5.2017 17:02, Sylvain Lemieux wrote:
> From: Liam Beguin <lbeguin@tycoint.com>
>
> Figure 1 is full of whitespaces; fix it
>
> Signed-off-by: Liam Beguin <lbeguin@tycoint.com>
> Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
> ---
> Documentation/networking/switchdev.txt | 70 +++++++++++++++++-----------------
> 1 file changed, 35 insertions(+), 35 deletions(-)
>
> diff --git a/Documentation/networking/switchdev.txt b/Documentation/networking/switchdev.txt
> index 2bbac05ab9e2..3e7b946dea27 100644
> --- a/Documentation/networking/switchdev.txt
> +++ b/Documentation/networking/switchdev.txt
> @@ -13,43 +13,43 @@ an example setup using a data-center-class switch ASIC chip. Other setups
> with SR-IOV or soft switches, such as OVS, are possible.
>
>
> - User-space tools
> -
> - user space |
> - +-------------------------------------------------------------------+
> - kernel | Netlink
> - |
> - +--------------+-------------------------------+
> - | Network stack |
> - | (Linux) |
> - | |
> - +----------------------------------------------+
> -
> + User-space tools
> +
> + user space |
> + +-------------------------------------------------------------------+
> + kernel | Netlink
> + |
> + +--------------+-------------------------------+
> + | Network stack |
> + | (Linux) |
> + | |
> + +----------------------------------------------+
> +
> sw1p2 sw1p4 sw1p6
> - sw1p1 + sw1p3 + sw1p5 + eth1
> - + | + | + | +
> - | | | | | | |
> - +--+----+----+----+-+--+----+---+ +-----+-----+
> - | Switch driver | | mgmt |
> - | (this document) | | driver |
> - | | | |
> - +--------------+----------------+ +-----------+
> - |
> - kernel | HW bus (eg PCI)
> - +-------------------------------------------------------------------+
> - hardware |
> - +--------------+---+------------+
> - | Switch device (sw1) |
> - | +----+ +--------+
> - | | v offloaded data path | mgmt port
> - | | | |
> - +--|----|----+----+----+----+---+
> - | | | | | |
> - + + + + + +
> + sw1p1 + sw1p3 + sw1p5 + eth1
> + + | + | + | +
> + | | | | | | |
> + +--+----+----+----+-+--+----+---+ +-----+-----+
> + | Switch driver | | mgmt |
> + | (this document) | | driver |
> + | | | |
> + +--------------+----------------+ +-----------+
> + |
> + kernel | HW bus (eg PCI)
> + +-------------------------------------------------------------------+
> + hardware |
> + +--------------+---+------------+
> + | Switch device (sw1) |
> + | +----+ +--------+
> + | | v offloaded data path | mgmt port
> + | | | |
> + +--|----|----+----+----+----+---+
> + | | | | | |
> + + + + + + +
> p1 p2 p3 p4 p5 p6
> -
> - front-panel ports
> -
> +
> + front-panel ports
> +
>
> Fig 1.
>
>
Acked-by: Ivan Vecera <ivecera@redhat.com>
^ permalink raw reply
* Re: [PATCH v4 binutils] Add BPF support to binutils...
From: David Miller @ 2017-05-01 17:42 UTC (permalink / raw)
To: aconole; +Cc: ast, daniel, netdev, xdp-newbies
In-Reply-To: <f7ttw541ohz.fsf@redhat.com>
From: Aaron Conole <aconole@bytheb.org>
Date: Mon, 01 May 2017 13:22:00 -0400
> Latest results from x86-64 and aarch64:
I'll see if I can reproduce here...
> I've also got a small incremental to fix some trailing whitespace, and
> s/SPARC/BPF/ in one file, attached.
Applied, thanks!
^ permalink raw reply
* Re: [PATCH iproute2 net-next v2] bpf: add support for generic xdp
From: Daniel Borkmann @ 2017-05-01 17:33 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: alexei.starovoitov, davem, netdev, quentin.monnet
In-Reply-To: <20170501092915.5c19395c@xeon-e3>
[ +Quentin ]
On 05/01/2017 06:29 PM, Stephen Hemminger wrote:
> On Fri, 28 Apr 2017 15:44:29 +0200
> Daniel Borkmann <daniel@iogearbox.net> wrote:
>
>> Follow-up to commit c7272ca72009 ("bpf: add initial support for
>> attaching xdp progs") to also support generic XDP. This adds an
>> indicator for loaded generic XDP programs when programs are loaded
>> as shown in c7272ca72009, but the driver still lacks native XDP
>> support.
>>
>> # ip link
>> [...]
>> 3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 xdpgeneric qdisc [...]
>> link/ether 0c:c4:7a:03:f9:25 brd ff:ff:ff:ff:ff:ff
>> [...]
>>
>> In case the driver does support native XDP, but the user wants
>> to load the program as generic XDP (e.g. for testing purposes),
>> then this can be done with the same semantics as in c7272ca72009,
>> but with 'xdpgeneric' instead of 'xdp' command for loading:
>>
>> # ip -force link set dev eno1 xdpgeneric obj xdp.o
>>
>> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
>
> Applied, thanks for remembering to update man page.
No problem, thanks!
> Does bash-completion need update?
Yeah, so far there's only a bash completion for the tc tool
in the tree, but nothing else. Is there anything in the works
for covering other tools, Quentin?
Thanks again,
Daniel
^ permalink raw reply
* [ANNOUNCE] iproute2 4.11
From: Stephen Hemminger @ 2017-05-01 17:32 UTC (permalink / raw)
To: netdev, linux-kernel
Update to iproute2 utility to support new features in Linux 4.11.
Most of the changes are related to recent work for hardware offload
and flow classification in tc.
Also the usual array of small manual and documentaton updates.
Source:
https://www.kernel.org/pub/linux/utils/net/iproute2/iproute2-4.11.0.tar.gz
Repository:
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
Report problems (or enhancements) to the netdev@vger.kernel.org mailing list.
---
Alexander Alemayhu (2):
man: add examples to ip.8
man: fix man page warnings
Amir Vadai (7):
tc/pedit: Fix a typo in pedit usage message
tc/pedit: Extend pedit to specify offset relative to mac/transport headers
tc/pedit: Introduce 'add' operation
tc/pedit: p_ip: introduce editing ttl header
tc/pedit: Support fields bigger than 32 bits
tc/pedit: p_eth: ETH header editor
tc/pedit: p_tcp: introduce pedit tcp support
Craig Gallek (1):
gre6: fix copy/paste bugs in GREv6 attribute manipulation
Daniel Borkmann (2):
{f,m}_bpf: dump tag over insns
bpf: test for valid type in bpf_get_work_dir
David Ahern (3):
ip: Add support for MPLS netconf
ip route: Add missing space between nexthop and via for mpls multipath routes
ip vrf: Add command name next to pid
Davide Caratti (1):
tc: m_csum: add support for SCTP checksum
Hangbin Liu (7):
iplink: bridge: add support for IFLA_BR_FDB_FLUSH
iplink: bridge: add support for IFLA_BR_VLAN_STATS_ENABLED
iplink: bridge: add support for IFLA_BR_MCAST_STATS_ENABLED
iplink: bridge: add support for IFLA_BR_MCAST_IGMP_VERSION
iplink: bridge: add support for IFLA_BR_MCAST_MLD_VERSION
iplink: bridge_slave: add support for IFLA_BRPORT_FLUSH
man: ip-link.8: Document bridge_slave fdb_flush option
Jamal Hadi Salim (1):
actions: Add support for user cookies
Jiri Kosina (1):
iproute2: tc: introduce build dependency on libnetlink
Jiri Pirko (1):
devlink: use DEVLINK_CMD_ESWITCH_* instead of DEVLINK_CMD_ESWITCH_MODE_*
Michal Kubeček (1):
routel: fix infinite loop in line parser
Nikolay Aleksandrov (4):
ipmroute: add support for RTNH_F_UNRESOLVED
iplink: add support for xstats subcommand
iplink: bridge: add support for displaying xstats
iplink: bridge_slave: add support for displaying xstats
Or Gerlitz (1):
tc/pedit: p_udp: introduce pedit udp support
Paul Blakey (2):
tc: flower: support matching flags
tc: flower: Refactor matching flags to be more user friendly
Petr Vorel (1):
color: use "light" colors for dark background
Phil Sutter (7):
man: ss.8: Add missing protocols to description of -A
ip: link: bond: Fix whitespace in help text
ip: link: macvlan: Add newline to help output
ip: link: Unify link type help functions a bit
ip: link: Add missing link type help texts
man: ip-link: Specify min/max values for bridge slave priority and cost
man: ip-rule.8: Further clarify how to interpret priority value
Robert Shearman (2):
iplink: add support for afstats subcommand
man: Fix formatting of vrf parameter of ip-link show command
Roi Dayan (2):
tc: flower: Fix parsing ip address
devlink: Add json and pretty options to help and man
Roman Mashak (1):
tc: print skbedit action when dumping actions.
Sabrina Dubroca (1):
man: ip-link.8: document bridge options
Simon Horman (9):
tc: flower: document that *_ip parameters take a PREFIX as an argument.
tc: flower: Allow *_mac options to accept a mask
tc: flower: Update dest UDP port documentation
tc: flower: Support matching ARP
tc: flower: use correct type when calling flower_icmp_attr_type
tc: flower: Update documentation to indicate ARP takes IPv4 prefixes
tc: flower: provide generic masked u8 parser helper
tc: flower: provide generic masked u8 print helper
tc: flower: support masked ICMP code and type match
Stephen Hemminger (24):
minor kernel header update
kernel headers update
add more uapi header files
include: remove unused header
update kernel headers from 4.10 net-next
update kernel headers from net-next
tcp: header file update
update headers from bridge tunnel metadata
tc: add missing sample file
update headers from net-next
add missing iplink_xstats.c
update headers from net-next
Update headers based on 4.11 merge window
netlink route attribute cleanup
xfrm: remove unnecessary casts
tc: use rta_getattr_u32
bpf: remove unnecessary cast
pie: remove always false condition
update headers from 4.11-rc2
update headers from 4.11-rc3
netem: fix out of bounds access in maketable
iplink: whitespace cleanup
pedit: fix whitespace
v4.11.0
Timothy Redaelli (1):
ip-route: Prevent some other double spaces in output
Vincent Bernat (1):
vxlan: use preferred address family when neither group or remote is specified
Yotam Gigi (8):
tc: Add support for the sample tc action
tc: man: Add man entry for the tc-sample action
tc: man: matchall: Update examples to include sample
tc: bash-completion: Add the _from variant to _tc_one* funcs
tc: bash-completion: Prepare action autocomplete to support several actions
tc: bash-completion: Make the *_KIND variables global
tc: bash-completion: Add support for filter actions
tc: bash-completion: Add support for matchall
Zhang Shengju (1):
iplink: add support for IFLA_CARRIER attribute
^ permalink raw reply
* Re: net/smc and the RDMA core
From: Bart Van Assche @ 2017-05-01 17:29 UTC (permalink / raw)
To: hch@lst.de, davem@davemloft.net, ubraun@linux.vnet.ibm.com
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org
In-Reply-To: <20170501163311.GA22209@lst.de>
On Mon, 2017-05-01 at 18:33 +0200, Christoph Hellwig wrote:
> Hi Ursual, hi netdev reviewers,
>
> how did the smc protocol manage to get merged without any review
> on linux-rdma at all? As the results it seems it's very substandard
> in terms of RDMA API usage, e.g. it neither uses the proper CQ API
> nor the RDMA R/W API, and other will probably find additional issues
> as well.
Hello Dave and Ursula,
It seems very rude to me to have merged the SMC protocol driver without
having involved the linux-rdma community. Anyway, I have the following
questions for Dave and Ursula:
* Since the Linux kernel is standards based: where can we find the standard
that defines the SMC wire protocol? If this protocol has not been
standardized yet: in what file (other than *.[ch]) in the Linux kernel
tree has this protocol been documented?
* What are the differences between the SMC protocol, the SDP protocol and
the rsockets protocol? How do existing implementations for these protocols
compare to each other from a performance point of view? If no performance
comparison between these protocols is available, shouldn't the performance
of these protocols have been compared with each other before a review of
the SMC driver even started?
* What are the reasons why the SDP driver was never accepted upstream? Do
the arguments why SDP was not accepted upstream also apply to the SMC
driver (SDP = Sockets Direct Protocol)?
* Since SMC has to be selected by specifying AF_SMC, how are users expected
to specify whether AF_INET, AF_INET6 or yet another address family should
be used to set up a connection between SMC
endpoints?
* Is the SMC driver limited to RoCE? Are you aware that the rsockets library
supports multiple transport layers (RoCE, IB and iWARP)?
* Since functionality that is similar what the SMC driver provides already
exists in user space (rsockets), why has this functionality been
reimplemented as a kernel driver (SMC)?
Bart.
^ permalink raw reply
* Re: [PATCH v4 binutils] Add BPF support to binutils...
From: Aaron Conole @ 2017-05-01 17:22 UTC (permalink / raw)
To: David Miller; +Cc: ast, daniel, netdev, xdp-newbies
In-Reply-To: <20170430.120750.651845251226226775.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 871 bytes --]
David Miller <davem@davemloft.net> writes:
> This is mainly a synchronization point, I still need to look
> more deeply into Alexei's -g issue.
>
> New in this version from v3:
> - Remove tailcall from opcode table
> - Rearrange relocations so that numbers match with LLVM ones
> - Emit relocs properly so that dwarf2 debug info tests pass
> - Handle negative load/store offsets properly, add tests
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
Latest results from x86-64 and aarch64:
Both are little endian. The only difference is for x86-64, I'm off of
commit 750eaa47f10f ("x86: Check plt_got before using .plt.got") and
for aarch64 I'm off of ee7e95efb981 ("merge_gnu_build_notes reloc
deletion"). I don't think that should matter.
I've also got a small incremental to fix some trailing whitespace, and
s/SPARC/BPF/ in one file, attached.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: incremental patch for git apply --]
[-- Type: text/x-patch, Size: 3060 bytes --]
diff --git a/bfd/elf64-bpf.c b/bfd/elf64-bpf.c
index a42f768..b04fdfb 100644
--- a/bfd/elf64-bpf.c
+++ b/bfd/elf64-bpf.c
@@ -39,7 +39,7 @@ _bfd_bpf_elf_reloc_type_lookup (bfd *abfd ATTRIBUTE_UNUSED,
{
case BFD_RELOC_NONE:
return &_bfd_bpf_elf_howto_table[R_BPF_NONE];
-
+
case BFD_RELOC_BPF_WDISP16:
return &_bfd_bpf_elf_howto_table[R_BPF_WDISP16];
diff --git a/gas/config/tc-bpf.c b/gas/config/tc-bpf.c
index 36393b7..d78f06f 100644
--- a/gas/config/tc-bpf.c
+++ b/gas/config/tc-bpf.c
@@ -1,4 +1,4 @@
-/* tc-bpf.c -- Assemble for the SPARC
+/* tc-bpf.c -- Assemble for BPF
Copyright (C) 2017 Free Software Foundation, Inc.
This file is part of GAS, the GNU Assembler.
@@ -153,7 +153,7 @@ output_insn (struct bpf_it *theinsn)
valueT opc = theinsn->opcode;
char *toP = frag_more (theinsn->imm64 ? 16 : 8);
char code, regs;
-
+
code = opc >> (64 - 8);
regs = opc >> (64 - (8 + 8));
@@ -317,7 +317,7 @@ md_assemble (char *str ATTRIBUTE_UNUSED)
if (c != '0' || mask != 1)
goto error;
mask = 10;
- }
+ }
the_insn.opcode |= (mask << 52);
continue;
}
@@ -337,7 +337,7 @@ md_assemble (char *str ATTRIBUTE_UNUSED)
if (c != '0' || mask != 1)
goto error;
mask = 10;
- }
+ }
the_insn.opcode |= (mask << 48);
continue;
}
diff --git a/gas/testsuite/gas/bpf/bpf.exp b/gas/testsuite/gas/bpf/bpf.exp
index 363fd2c..5a8d54c 100644
--- a/gas/testsuite/gas/bpf/bpf.exp
+++ b/gas/testsuite/gas/bpf/bpf.exp
@@ -4,15 +4,15 @@
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
-#
+#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
-#
+#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
-# Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA 02110-1301, USA.
+# Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA 02110-1301, USA.
# BPF assembler testsuite
diff --git a/gdb/bpf-tdep.c b/gdb/bpf-tdep.c
index 6629f73..9cca3bc 100644
--- a/gdb/bpf-tdep.c
+++ b/gdb/bpf-tdep.c
@@ -192,7 +192,7 @@ bpf_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
tdep = XNEW (struct gdbarch_tdep);
gdbarch = gdbarch_alloc (&info, tdep);
-
+
tdep->xxx = 0;
set_gdbarch_num_regs (gdbarch, BPF_NUM_REGS);
diff --git a/opcodes/bpf-dis.c b/opcodes/bpf-dis.c
index 39656bf..e15acc1 100644
--- a/opcodes/bpf-dis.c
+++ b/opcodes/bpf-dis.c
@@ -79,7 +79,7 @@ print_insn_bpf (bfd_vma memaddr, disassemble_info *info)
{
getword = bfd_getl32;
gethalf = bfd_getl16;
- }
+ }
code = buffer[0];
dest = (buffer[1] & 0xf0) >> 4;
--
2.9.3
[-- Attachment #3: Type: text/plain, Size: 376 bytes --]
x86-64:
Running /home/aconole/git/binutils-gdb/gas/testsuite/gas/bpf/bpf.exp ...
FAIL: jump
FAIL: call
FAIL: imm64a
Running /home/aconole/git/binutils-gdb/gas/testsuite/gas/cfi/cfi.exp ...
aarch64 (pine64 board):
Running /root/aarch64/git/binutils-gdb/gas/testsuite/gas/bpf/bpf.exp ...
Running /root/aarch64/git/binutils-gdb/gas/testsuite/gas/cfi/cfi.exp ...
^ permalink raw reply related
* Re: [PATCH net-next 00/18] net: dsa: mv88e6xxx: 802.1s and 88E6390 VTU
From: Vivien Didelot @ 2017-05-01 17:16 UTC (permalink / raw)
To: Andrew Lunn; +Cc: David Miller, netdev, linux-kernel, kernel, f.fainelli
In-Reply-To: <20170501162552.GH1285@lunn.ch>
Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
> I actually pointed out a typo in one of the change log message. And i
> requested some additional comments.
I can respin this patch series to correct the nitpicks on 8/18 but, what
I want most is a Tested-by tag. As you have this hardware, can you give
it a try?
Note that 17/18 is missing your Reviewed-by as agreed.
Vivien
^ permalink raw reply
* Re: [PATCH net-next 00/18] net: dsa: mv88e6xxx: 802.1s and 88E6390 VTU
From: Vivien Didelot @ 2017-05-01 16:36 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, kernel, f.fainelli, andrew
In-Reply-To: <20170501.122618.1787371573631638101.davem@davemloft.net>
Hi David,
David Miller <davem@davemloft.net> writes:
> Once I set the state to "changes requested", that's basically permanent.
>
> Please simply resubmit your patch series, ACKs added if necessary.
OK good to know, I respin this series in a few minutes.
Thanks,
Vivien
^ permalink raw reply
* [PATCH 1/1] IB/mlx5: Add port_xmit_wait to counter registers read
From: Tim Wright @ 2017-05-01 16:30 UTC (permalink / raw)
To: matanb, leonro, dledford, sean.hefty, hal.rosenstock, saeedm
Cc: Tim Wright, linux-rdma, netdev
Add port_xmit_wait to the error counters read by mlx5_ib_process_mad to
ensure sysfs port counter provides correct value for PortXmitWait.
Otherwise the sysfs port_xmit_wait file always contains zero.
The previous MAD_IFC implementation populated this counter, but it was
removed during the migration to PPCNT for error counters (32-bit only).
Signed-off-by: Tim Wright <tim@binbash.co.uk>
---
drivers/infiniband/hw/mlx5/mad.c | 2 ++
include/linux/mlx5/mlx5_ifc.h | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mlx5/mad.c b/drivers/infiniband/hw/mlx5/mad.c
index 8dacb49..f1b56de6 100644
--- a/drivers/infiniband/hw/mlx5/mad.c
+++ b/drivers/infiniband/hw/mlx5/mad.c
@@ -187,6 +187,8 @@ static void pma_cnt_assign(struct ib_pma_portcounters *pma_cnt,
port_xmit_discards);
MLX5_ASSIGN_PMA_CNTR(pma_cnt->port_xmit_constraint_errors,
port_xmit_constraint_errors);
+ MLX5_ASSIGN_PMA_CNTR(pma_cnt->port_xmit_wait,
+ port_xmit_wait);
MLX5_ASSIGN_PMA_CNTR(pma_cnt->port_rcv_constraint_errors,
port_rcv_constraint_errors);
MLX5_ASSIGN_PMA_CNTR(pma_cnt->link_overrun_errors,
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index 8382426..e641bc3 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -1452,7 +1452,9 @@ struct mlx5_ifc_ib_port_cntrs_grp_data_layout_bits {
u8 vl_15_dropped[0x10];
- u8 reserved_at_a0[0xa0];
+ u8 reserved_at_a0[0x80];
+
+ u8 port_xmit_wait[0x20];
};
struct mlx5_ifc_eth_per_traffic_grp_data_layout_bits {
--
1.8.3.1
^ permalink raw reply related
* 13067 netdev
From: kelley @ 2017-05-01 16:37 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 26336675947658.zip --]
[-- Type: application/zip, Size: 4203 bytes --]
^ permalink raw reply
* net/smc and the RDMA core
From: Christoph Hellwig @ 2017-05-01 16:33 UTC (permalink / raw)
To: Ursula Braun, David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Hi Ursual, hi netdev reviewers,
how did the smc protocol manage to get merged without any review
on linux-rdma at all? As the results it seems it's very substandard
in terms of RDMA API usage, e.g. it neither uses the proper CQ API
nor the RDMA R/W API, and other will probably find additional issues
as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH iproute2 net-next] ip xfrm: Add xfrm state crypto offload
From: Stephen Hemminger @ 2017-05-01 16:31 UTC (permalink / raw)
To: ilant; +Cc: Steffen Klassert, netdev, Boris Pismenny
In-Reply-To: <20170430141602.30995-1-ilant@mellanox.com>
On Sun, 30 Apr 2017 17:16:02 +0300
<ilant@mellanox.com> wrote:
> From: Boris Pismenny <borisp@mellanox.com>
>
> syntax:
> ip xfrm state .... offload dev <if-name> dir <in or out>
>
> Example to add inbound offload:
> ip xfrm state .... offload dev mlx0 dir in
> Example to add outbound offload:
> ip xfrm state .... offload dev mlx0 dir out
>
> Signed-off-by: Boris Pismenny <borisp@mellanox.com>
> Signed-off-by: Ilan Tayari <ilant@mellanox.com>
Applied to net-next
^ permalink raw reply
* Re: [PATCH iproute2 net-next v2] bpf: add support for generic xdp
From: Stephen Hemminger @ 2017-05-01 16:29 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: alexei.starovoitov, davem, netdev
In-Reply-To: <e2ca217f7b95b4dd0b5fa8650e8fcf783de73967.1493386943.git.daniel@iogearbox.net>
On Fri, 28 Apr 2017 15:44:29 +0200
Daniel Borkmann <daniel@iogearbox.net> wrote:
> Follow-up to commit c7272ca72009 ("bpf: add initial support for
> attaching xdp progs") to also support generic XDP. This adds an
> indicator for loaded generic XDP programs when programs are loaded
> as shown in c7272ca72009, but the driver still lacks native XDP
> support.
>
> # ip link
> [...]
> 3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 xdpgeneric qdisc [...]
> link/ether 0c:c4:7a:03:f9:25 brd ff:ff:ff:ff:ff:ff
> [...]
>
> In case the driver does support native XDP, but the user wants
> to load the program as generic XDP (e.g. for testing purposes),
> then this can be done with the same semantics as in c7272ca72009,
> but with 'xdpgeneric' instead of 'xdp' command for loading:
>
> # ip -force link set dev eno1 xdpgeneric obj xdp.o
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Applied, thanks for remembering to update man page.
Does bash-completion need update?
^ permalink raw reply
* Re: [PATCH iproute2 net 0/8] tc/act_pedit: Support offset relative to conventional header
From: Stephen Hemminger @ 2017-05-01 16:26 UTC (permalink / raw)
To: Amir Vadai; +Cc: netdev, Or Gerlitz, Jamal Hadi Salim
In-Reply-To: <20170423125356.1298-1-amir@vadai.me>
On Sun, 23 Apr 2017 15:53:48 +0300
Amir Vadai <amir@vadai.me> wrote:
> Hi Stephen,
>
> This patchset extends pedit to support modifying a field in an offset relative
> to the conventional network headers (kenrel support was added [1] in 4.11 rc1).
> Without the extended pedit, user could specify fields in TCP and ICMP headers,
> but the kernel code was using an offset relative to the begining of the IP
> header. This will break if IP header length is greater than the minimal value
> of 20, or if L3 is not IPv4.
>
> It also introduces support in manipulating ETH, TCP, UDP and IP.ttl fields and
> a new command to increase/decrease the value of a field (current use case is IP.ttl).
>
> Since there might be deployments already using pedit, special consideration was
> taken, not to break those scripts - only by specifying the special keyword
> 'ex', the extended capabilities are available, thus there should be no impact
> on existing scripts.
> Also, the new code can live together with rules added by the old code. It
> supports both the old netlink and the new one.
>
> This patchset is against the master and not net-next as the functionality was
> added in 4.11
>
> Thanks,
> Amir
>
> [1] - 71d0ed7079df ("net/act_pedit: Support using offset relative to the
> conventional network headers")
>
> Amir Vadai (7):
> tc/pedit: Fix a typo in pedit usage message
> tc/pedit: Extend pedit to specify offset relative to mac/transport
> headers
> tc/pedit: Introduce 'add' operation
> tc/pedit: p_ip: introduce editing ttl header
> tc/pedit: Support fields bigger than 32 bits
> tc/pedit: p_eth: ETH header editor
> tc/pedit: p_tcp: introduce pedit tcp support
>
> Or Gerlitz (1):
> tc/pedit: p_udp: introduce pedit udp support
>
> man/man8/tc-pedit.8 | 126 +++++++++++++++++++++--
> tc/Makefile | 1 +
> tc/m_pedit.c | 290 ++++++++++++++++++++++++++++++++++++++++++++++------
> tc/m_pedit.h | 44 ++++++--
> tc/p_eth.c | 72 +++++++++++++
> tc/p_icmp.c | 3 +-
> tc/p_ip.c | 21 +++-
> tc/p_tcp.c | 40 +++++++-
> tc/p_udp.c | 30 +++++-
> 9 files changed, 572 insertions(+), 55 deletions(-)
> create mode 100644 tc/p_eth.c
>
Applied. Then I cleaned up long lines
^ permalink raw reply
* Re: [PATCH net-next 00/18] net: dsa: mv88e6xxx: 802.1s and 88E6390 VTU
From: David Miller @ 2017-05-01 16:26 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, linux-kernel, kernel, f.fainelli, andrew
In-Reply-To: <87shko7dkk.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Mon, 01 May 2017 12:21:31 -0400
> Hi David,
>
> David Miller <davem@davemloft.net> writes:
>
>> From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
>> Date: Mon, 01 May 2017 11:51:05 -0400
>>
>>> Hi David,
>>>
>>> Vivien Didelot <vivien.didelot@savoirfairelinux.com> writes:
>>>
>>>> Vivien Didelot (18):
>>>> net: dsa: mv88e6xxx: add max VID to info
>>>> net: dsa: mv88e6xxx: split VTU entry data member
>>>> net: dsa: mv88e6xxx: move VTU Operation accessors
>>>> net: dsa: mv88e6xxx: move VTU flush
>>>> net: dsa: mv88e6xxx: move VTU FID accessors
>>>> net: dsa: mv88e6xxx: move VTU SID accessors
>>>> net: dsa: mv88e6xxx: move VTU VID accessors
>>>> net: dsa: mv88e6xxx: move generic VTU GetNext
>>>> net: dsa: mv88e6xxx: move VTU Data accessors
>>>> net: dsa: mv88e6xxx: move STU GetNext operation
>>>> net: dsa: mv88e6xxx: get STU entry on VTU GetNext
>>>> net: dsa: mv88e6xxx: load STU entry with VTU entry
>>>> net: dsa: mv88e6xxx: add VTU GetNext operation
>>>> net: dsa: mv88e6xxx: add VTU Load/Purge operation
>>>> net: dsa: mv88e6xxx: make VTU helpers static
>>>> net: dsa: mv88e6xxx: simplify VTU entry getter
>>>> net: dsa: mv88e6xxx: support the VTU Page bit
>>>> net: dsa: mv88e6xxx: add VTU support for 88E6390
>>>>
>>>> drivers/net/dsa/mv88e6xxx/Makefile | 1 +
>>>> drivers/net/dsa/mv88e6xxx/chip.c | 568 +++++++++-----------------------
>>>> drivers/net/dsa/mv88e6xxx/global1.h | 14 +
>>>> drivers/net/dsa/mv88e6xxx/global1_vtu.c | 505 ++++++++++++++++++++++++++++
>>>> drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 31 +-
>>>> 5 files changed, 684 insertions(+), 435 deletions(-)
>>>> create mode 100644 drivers/net/dsa/mv88e6xxx/global1_vtu.c
>>>
>>> I don't see the patchset in net-next. Can you pick it?
>>
>> This had feedback which you must address, therefore the state in
>> patchwork is "changes requested" which you could have checked before
>> asking me this.
>>
>> If the patch set is fine and you got ACKs for all of your patches
>> then please resubmit.
>>
>> Otherwise, make the changes you were asked to make or explain to
>> the person who asked for them why they are not appropriate.
>
> We did discuss the patchset and everything is good as is. Can someone
> change the state in patchwork afterwards? It feels weird to resend the
> patch with no changes.
Once I set the state to "changes requested", that's basically permanent.
Please simply resubmit your patch series, ACKs added if necessary.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 00/18] net: dsa: mv88e6xxx: 802.1s and 88E6390 VTU
From: Andrew Lunn @ 2017-05-01 16:25 UTC (permalink / raw)
To: Vivien Didelot; +Cc: David Miller, netdev, linux-kernel, kernel, f.fainelli
In-Reply-To: <87shko7dkk.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
> We did discuss the patchset and everything is good as is. Can someone
> change the state in patchwork afterwards? It feels weird to resend the
> patch with no changes.
Hi Vivien
I actually pointed out a typo in one of the change log message. And i
requested some additional comments.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 00/18] net: dsa: mv88e6xxx: 802.1s and 88E6390 VTU
From: Vivien Didelot @ 2017-05-01 16:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, kernel, f.fainelli, andrew
In-Reply-To: <20170501.120800.1973590139715167836.davem@davemloft.net>
Hi David,
David Miller <davem@davemloft.net> writes:
> From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> Date: Mon, 01 May 2017 11:51:05 -0400
>
>> Hi David,
>>
>> Vivien Didelot <vivien.didelot@savoirfairelinux.com> writes:
>>
>>> Vivien Didelot (18):
>>> net: dsa: mv88e6xxx: add max VID to info
>>> net: dsa: mv88e6xxx: split VTU entry data member
>>> net: dsa: mv88e6xxx: move VTU Operation accessors
>>> net: dsa: mv88e6xxx: move VTU flush
>>> net: dsa: mv88e6xxx: move VTU FID accessors
>>> net: dsa: mv88e6xxx: move VTU SID accessors
>>> net: dsa: mv88e6xxx: move VTU VID accessors
>>> net: dsa: mv88e6xxx: move generic VTU GetNext
>>> net: dsa: mv88e6xxx: move VTU Data accessors
>>> net: dsa: mv88e6xxx: move STU GetNext operation
>>> net: dsa: mv88e6xxx: get STU entry on VTU GetNext
>>> net: dsa: mv88e6xxx: load STU entry with VTU entry
>>> net: dsa: mv88e6xxx: add VTU GetNext operation
>>> net: dsa: mv88e6xxx: add VTU Load/Purge operation
>>> net: dsa: mv88e6xxx: make VTU helpers static
>>> net: dsa: mv88e6xxx: simplify VTU entry getter
>>> net: dsa: mv88e6xxx: support the VTU Page bit
>>> net: dsa: mv88e6xxx: add VTU support for 88E6390
>>>
>>> drivers/net/dsa/mv88e6xxx/Makefile | 1 +
>>> drivers/net/dsa/mv88e6xxx/chip.c | 568 +++++++++-----------------------
>>> drivers/net/dsa/mv88e6xxx/global1.h | 14 +
>>> drivers/net/dsa/mv88e6xxx/global1_vtu.c | 505 ++++++++++++++++++++++++++++
>>> drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 31 +-
>>> 5 files changed, 684 insertions(+), 435 deletions(-)
>>> create mode 100644 drivers/net/dsa/mv88e6xxx/global1_vtu.c
>>
>> I don't see the patchset in net-next. Can you pick it?
>
> This had feedback which you must address, therefore the state in
> patchwork is "changes requested" which you could have checked before
> asking me this.
>
> If the patch set is fine and you got ACKs for all of your patches
> then please resubmit.
>
> Otherwise, make the changes you were asked to make or explain to
> the person who asked for them why they are not appropriate.
We did discuss the patchset and everything is good as is. Can someone
change the state in patchwork afterwards? It feels weird to resend the
patch with no changes.
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH iproute2 net 2/8] tc/pedit: Extend pedit to specify offset relative to mac/transport headers
From: Stephen Hemminger @ 2017-05-01 16:21 UTC (permalink / raw)
To: Amir Vadai; +Cc: netdev, Or Gerlitz, Jamal Hadi Salim
In-Reply-To: <20170423125356.1298-3-amir@vadai.me>
On Sun, 23 Apr 2017 15:53:50 +0300
Amir Vadai <amir@vadai.me> wrote:
> -extern int parse_cmd(int *argc_p, char ***argv_p, __u32 len, int type,__u32 retain,struct tc_pedit_sel *sel,struct tc_pedit_key *tkey);
> -extern int pack_key(struct tc_pedit_sel *sel,struct tc_pedit_key *tkey);
> -extern int pack_key32(__u32 retain,struct tc_pedit_sel *sel,struct tc_pedit_key *tkey);
> -extern int pack_key16(__u32 retain,struct tc_pedit_sel *sel,struct tc_pedit_key *tkey);
> -extern int pack_key8(__u32 retain,struct tc_pedit_sel *sel,struct tc_pedit_key *tkey);
> +extern int pack_key(struct m_pedit_sel *sel, struct m_pedit_key *tkey);
> +extern int pack_key32(__u32 retain, struct m_pedit_sel *sel, struct m_pedit_key *tkey);
> +extern int pack_key16(__u32 retain, struct m_pedit_sel *sel, struct m_pedit_key *tkey);
> +extern int pack_key8(__u32 retain, struct m_pedit_sel *sel, struct m_pedit_key *tkey);
> extern int parse_val(int *argc_p, char ***argv_p, __u32 * val, int type);
> -extern int parse_cmd(int *argc_p, char ***argv_p, __u32 len, int type,__u32 retain,struct tc_pedit_sel *sel,struct tc_pedit_key *tkey);
> -extern int parse_offset(int *argc_p, char ***argv_p,struct tc_pedit_sel *sel,struct tc_pedit_key *tkey);
> +extern int parse_cmd(int *argc_p, char ***argv_p, __u32 len, int type, __u32 retain,
> + struct m_pedit_sel *sel, struct m_pedit_key *tkey);
> +extern int parse_offset(int *argc_p, char ***argv_p,
> + struct m_pedit_sel *sel, struct m_pedit_key *tkey);
> int parse_pedit(struct action_util *a, int *argc_p, char ***argv_p, int tc
Please add newline to break the overly long lines here.
Try and keep with in the 80 column convention.
^ permalink raw reply
* RE: [PATCH v5 net-next]smsc911x: Adding support for Micochip LAN9250 Ethernet controller
From: David.Cai @ 2017-05-01 16:21 UTC (permalink / raw)
To: andrew; +Cc: netdev, davem, UNGLinuxDriver, steve.glendinning
In-Reply-To: <20170501161545.GG1285@lunn.ch>
Hi Andrew:
Thanks for your help!
David Cai
-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch]
Sent: Monday, May 01, 2017 9:16 AM
To: David Cai - C24226
Cc: netdev@vger.kernel.org; davem@davemloft.net; UNGLinuxDriver; steve.glendinning@shawell.net
Subject: Re: [PATCH v5 net-next]smsc911x: Adding support for Micochip LAN9250 Ethernet controller
On Mon, May 01, 2017 at 03:46:56PM +0000, David.Cai@microchip.com wrote:
> From: David Cai <david.cai@microchip.com>
>
> Adding support for Microchip LAN9250 Ethernet controller.
>
> Signed-off-by: David Cai <david.cai@microchip.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [iproute2] iplink: add support for IFLA_CARRIER attribute
From: Stephen Hemminger @ 2017-05-01 16:16 UTC (permalink / raw)
To: 张胜举; +Cc: netdev
In-Reply-To: <002301d2bf20$6647b5c0$32d72140$@cmss.chinamobile.com>
On Thu, 27 Apr 2017 14:35:01 +0800
张胜举 <zhangshengju@cmss.chinamobile.com> wrote:
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Wednesday, April 26, 2017 11:08 PM
> > To: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
> > Cc: netdev@vger.kernel.org
> > Subject: Re: [iproute2] iplink: add support for IFLA_CARRIER attribute
> >
> > On Wed, 26 Apr 2017 15:08:39 +0800
> > Zhang Shengju <zhangshengju@cmss.chinamobile.com> wrote:
> >
> > > Add support to set IFLA_CARRIER attribute.
> > >
> > > Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
> > > ---
> > > ip/iplink.c | 12 ++++++++++++
> > > 1 file changed, 12 insertions(+)
> > >
> > > diff --git a/ip/iplink.c b/ip/iplink.c index 866ad72..263bfdd 100644
> > > --- a/ip/iplink.c
> > > +++ b/ip/iplink.c
> > > @@ -72,6 +72,7 @@ void iplink_usage(void)
> > > " [ allmulticast { on | off } ]\n"
> > > " [ promisc { on | off } ]\n"
> > > " [ trailers { on | off } ]\n"
> > > + " [ carrier { on | off } ]\n"
> > > " [ txqueuelen PACKETS ]\n"
> > > " [ name NEWNAME ]\n"
> > > " [ address LLADDR ]\n"
> > > @@ -673,6 +674,17 @@ int iplink_parse(int argc, char **argv, struct
> > iplink_req *req,
> > > req->i.ifi_flags |= IFF_NOARP;
> > > else
> > > return on_off("arp", *argv);
> > > + } else if (strcmp(*argv, "carrier") == 0) {
> > > + int carrier;
> > > + NEXT_ARG();
> > > + if (strcmp(*argv, "on") == 0)
> > > + carrier = 1;
> > > + else if (strcmp(*argv, "off") == 0)
> > > + carrier = 0;
> > > + else
> > > + return on_off("carrier", *argv);
> > > +
> > > + addattr8(&req->n, sizeof(*req), IFLA_CARRIER,
> > carrier);
> > > } else if (strcmp(*argv, "vf") == 0) {
> > > struct rtattr *vflist;
> > >
> >
> > The general policy of ip link command is all options should be invertable.
> Yes, so I add 'on' and 'off' subcommand to make sure that it can be
> invertable.
>
> > There are some VPN's that use this to save and restore state. So if you
> add
> > an option to set something there should be similar output under the
> detailed
> > show command.
> Currently, "show command" already can display 'carrier' status. Such as:
> dummy0: <NO-CARRIER...>
>
Applied.
^ permalink raw reply
* Re: iproute2: tc action jump
From: Stephen Hemminger @ 2017-05-01 16:16 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: Jiri Pirko, netdev@vger.kernel.org
In-Reply-To: <3a59ecb3-3bdd-60d1-ffa0-5df284f4ccb5@mojatatu.com>
On Thu, 27 Apr 2017 21:54:13 -0400
Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> Attached.
> Needs some cleanup and more testing (I only tested a few of these
> actions - should work, just need to vet before official submission).
>
> cheers,
> jamal
Marked as RFC. When ready please resubmit
^ permalink raw reply
* Re: [PATCH v5 net-next]smsc911x: Adding support for Micochip LAN9250 Ethernet controller
From: Andrew Lunn @ 2017-05-01 16:15 UTC (permalink / raw)
To: David.Cai; +Cc: netdev, davem, UNGLinuxDriver, steve.glendinning
In-Reply-To: <C3C28FB10418274EB7FD7C2B85C796A4412480F1@CHN-SV-EXMX02.mchp-main.com>
On Mon, May 01, 2017 at 03:46:56PM +0000, David.Cai@microchip.com wrote:
> From: David Cai <david.cai@microchip.com>
>
> Adding support for Microchip LAN9250 Ethernet controller.
>
> Signed-off-by: David Cai <david.cai@microchip.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next iproute2] ip: increase number of MPLS labels
From: Stephen Hemminger @ 2017-05-01 16:15 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, Eric W. Biederman, roopa
In-Reply-To: <ddb54ca8-d7df-3446-3929-5f0116286c80@cumulusnetworks.com>
On Sun, 30 Apr 2017 17:42:15 -0600
David Ahern <dsa@cumulusnetworks.com> wrote:
> On 4/30/17 12:04 AM, Stephen Hemminger wrote:
> > On Sat, 29 Apr 2017 20:48:50 -0700
> > David Ahern <dsa@cumulusnetworks.com> wrote:
> >
> >> Kernel now supports more than 2 labels. Increase ip to
> >> handle up to 16 labels.
> >>
> >> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
> >> ---
> >> include/utils.h | 8 ++++----
> >> lib/utils.c | 2 +-
> >> 2 files changed, 5 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/include/utils.h b/include/utils.h
> >> index 8c12e1e2a60c..a69e176c260d 100644
> >> --- a/include/utils.h
> >> +++ b/include/utils.h
> >> @@ -54,6 +54,9 @@ void incomplete_command(void) __attribute__((noreturn));
> >> #define NEXT_ARG_FWD() do { argv++; argc--; } while(0)
> >> #define PREV_ARG() do { argv--; argc++; } while(0)
> >>
> >> +/* Maximum number of labels the mpls helpers support */
> >> +#define MPLS_MAX_LABELS 16
> >> +
> >
> > Why is the kernel limit not in include/uapi/ header file?
> >
>
> I believe Eric had reasons, but not sure why.
I just don't want iproute2 utilities chasing kernel values.
Would prefer either make utilities take any size, or inherit maximum from kernel headers.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox