* Re: [PATCH 00/20] Netfilter/IPVS updates for net-next
From: David Miller @ 2018-06-02 13:04 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20180602002259.4024-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Sat, 2 Jun 2018 02:22:39 +0200
> The following patchset contains Netfilter/IPVS updates for your net-next
> tree, the most relevant things in this batch are:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
Pulled, thanks.
^ permalink raw reply
* Re: [pull request][net-next 00/17] Mellanox, mlx5e updates 2018-06-01
From: David Miller @ 2018-06-02 12:55 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20180602000544.18717-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Fri, 1 Jun 2018 17:05:27 -0700
> Sorry for the extra 2 patches in this series, but mostly the series
> contains small patches and some fixes to previous patches in this
> submission window, with one main patch from Tariq to improve legacy
> RQ buffer management, for more information please refer to that tag
> log below.
>
> Please pull and let me know if there's any problem.
Pulled, thanks Saeed.
^ permalink raw reply
* Re: pull-request: bpf 2018-06-02
From: David Miller @ 2018-06-02 12:10 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <20180602050722.24694-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Sat, 2 Jun 2018 07:07:22 +0200
> The following pull-request contains BPF updates for your *net* tree.
>
> The main changes are:
>
> 1) BPF uapi fix in struct bpf_prog_info and struct bpf_map_info in
> order to fix offsets on 32 bit archs.
>
> Please consider pulling these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
>
> This will have a minor merge conflict with net-next which has the
> __u32 gpl_compatible:1 bitfield in struct bpf_prog_info at this
> location. Resolution is to use the gpl_compatible member.
Pulled, thanks Daniel.
^ permalink raw reply
* Lucrative Business Proposal
From: Adrien Saif @ 2018-06-02 8:51 UTC (permalink / raw)
--
Dear Friend,
I would like to discuss a very important issue with you. I am writing
to find out if this is your valid email. Please, let me know if this
email is valid
Kind regards
Adrien Saif
Attorney to Quatif Group of Companies
^ permalink raw reply
* Re: [PATCH 4/4] cpsw: add switchdev support
From: Ilias Apalodimas @ 2018-06-02 10:34 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, netdev, grygorii.strashko, ivan.khoronzhuk, nsekhar,
jiri, ivecera, francois.ozog, yogeshs, spatton
In-Reply-To: <aa95cdbd-1e89-0b8e-352e-4de80bf0f714@gmail.com>
Hi Florian,
Thanks for taking time to look into this
On Fri, Jun 01, 2018 at 02:48:48PM -0700, Florian Fainelli wrote:
>
>
> On 05/24/2018 09:56 PM, Ilias Apalodimas wrote:
> > On Thu, May 24, 2018 at 06:39:04PM +0200, Andrew Lunn wrote:
> >> On Thu, May 24, 2018 at 04:32:34PM +0300, Ilias Apalodimas wrote:
> >>> On Thu, May 24, 2018 at 03:12:29PM +0200, Andrew Lunn wrote:
> >>>> Device tree is supposed to describe the hardware. Using that hardware
> >>>> in different ways is not something you should describe in DT.
> >>>>
> >>> The new switchdev mode is applied with a .config option in the kernel. What you
> >>> see is pre-existing code, so i am not sure if i should change it in this
> >>> patchset.
> >>
> >> If you break the code up into a library and two drivers, it becomes a
> >> moot point.
> > Agree
> >
> >>
> >> But what i don't like here is that the device tree says to do dual
> >> mac. But you ignore that and do sometime else. I would prefer that if
> >> DT says dual mac, and switchdev is compiled in, the probe fails with
> >> EINVAL. Rather than ignore something, make it clear it is invalid.
> > The switch has 3 modes of operation as is.
> > 1. switch mode, to enable that you don't need to add anything on
> > the DTS and linux registers a single netdev interface.
> > 2. dual mac mode, this is when you need to add dual_emac; on the DTS.
> > 3. switchdev mode which is controlled by a .config option, since as you
> > pointed out DTS was not made for controlling config options.
> >
> > I agree that this is far from beautiful. If the driver remains as in though,
> > i'd prefer either keeping what's there or making "switchdev" a DTS option,
> > following the pre-existing erroneous usage rather than making the device
> > unusable. If we end up returning some error and refuse to initialize, users
> > that remote upgrade their equipment, without taking a good look at changelog,
> > will loose access to their devices with no means of remotely fixing that.
>
> It seems to me that the mistake here is seeing multiple modes of
> operations for the cpsw. There are not actually many, there is one
> usage, and then there is what you can and cannot offload.
CPSW has in fact 2 modes of operation, different FIFO usage/lookup entry(it's
called ALE in the current driver) by-pass(which is used in dual emac for
example) and other features. Again Grygorii is better suited to answer the
exact differences.
> The basic
> premise with switchdev and DSA (which uses switchdev) is that each
> user-facing port of your switch needs to work as if it were a normal
> Ethernet NIC, that is what you call dual-MAC I believe. Then, when you
> create a bridge and you enslave those ports into the bridge, you need to
> have forwarding done in hardware between these two ports when the
> SMAC/DMAC are not for the host/CPU/management interface and you must
> simultaneously still have the host have the ability to send/receive
> traffic through the bridge device.
Yes dual emac does that. But dual emac configures the port facing VLAN to the
CPU port as well. So dual emac splits and uses 2 interfaces. VLAN 1 is
configured on port1 + CPU port and VLAN 2 is confired on port 2 + CPU port
That's exactly what the current RFC does as well, with the addition of
registering a sw0p0 (i'll explain why later on this mail)
A little more detail on the issue we are having. On my description
sw0p0 -> CPU port, sw0p1 -> port 1 sw0p2 -> port 2. sw0p1/sw0p2 are the ports
that have PHYs attached.
When we start in the new switchdev mode all interfaces are added to VLAN 0
so CPU port + port1 + port2 are all in the same VLAN group. In that case sw0p1
and sw0p2 are working as you describe. So those 2 interfaces can send/receive
traffic normally which matches the switchdev case.
When we add them on a bridge(let's say br0), VLAN1(or any default bridge VLAN)
is now configured on sw0p1 and sw0p2 but *not* on the CPU port.
>From this point on the whole fuunctionality just collapses. The switch will
work and offload traffic between sw0p1/sw0p2 but the bridge won't be able to
get an ip address (since VLAN1 is not a member of the CPU port and the packet
gets dropped).
IGMPv2/V3 messages will never reach the br_multicast.c code to trigger
switchdev and configure the MDBs on the ports. i am prety sure there are other
fail scenarios which i haven't discovered already, but those 2 are the most
basic ones. If we add VLAN1 on the CPU port, everything works as intended of
course.
That's the reason we registered sw0p0 as the CPU port. It can't do any "real"
traffic, but you can configure the CPU port independantly and not be forced to
do an OR on every VLAN add/delete grouping the CPU port with your port command.
The TL;DR version of this is that the switch is working exactly as switchdev is
expecting offloading traffic to the hardware when possible as long as the CPU
port is member of the proper VLANs
Petr's patch solves this for us (9c86ce2c1ae337fc10568a12aea812ed03de8319).
We can now do "bridge vlan add dev br0 vid 100 pvid untagged self" and decide
when to add the CPU port or not.
There are still a couple of cases that are not covered though, if we don't
register the CPU port. We cant decide when to forward multicast
traffic on the CPU port if a join hasn't been sent from br0.
So let's say you got 2 hosts doing multicast and for whatever reason the host
wants to see that traffic.
With the CPU port present you can do a
"bridge mdb add dev br0 port sw0p0 grp 239.1.1.1 permanent" which will offload
the traffic to the CPU port and thus the host. If this goes away we are forced
to send a join.
> It seems to me like this is entirely doable given that the dual MAC use
> case is supported already.
>
> switchdev is just a stateless framework to get notified from the
> networking stack about what you can possibly offload in hardware, so
> having a DTS option gate that is unfortunately wrong because it is
> really implementing a SW policy in DTS which is not what it is meant for.
The DTS option for configuration pre-existed, i don't like that either switchdev
mode is activated by a .config option not DTS(it just overrides whatever config
you have on the DTS). Far from pretty though fair point, i am open to
suggestions.
> --
> Florian
Thanks!
Ilias
^ permalink raw reply
* Re: [net-next][PATCH] tcp: probe timer MUST not less than 5 minuter for tcp PMTU
From: Eric Dumazet @ 2018-06-02 10:19 UTC (permalink / raw)
To: Li RongQing, netdev
In-Reply-To: <1527851039-6626-1-git-send-email-lirongqing@baidu.com>
On 06/01/2018 07:03 AM, Li RongQing wrote:
> RFC4821 say: The value for this timer MUST NOT be less than
> 5 minutes and is recommended to be 10 minutes, per RFC 1981.
>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
> net/ipv4/sysctl_net_ipv4.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
> index d2eed3ddcb0a..ed8952bb6874 100644
> --- a/net/ipv4/sysctl_net_ipv4.c
> +++ b/net/ipv4/sysctl_net_ipv4.c
> @@ -47,6 +47,7 @@ static int tcp_syn_retries_max = MAX_TCP_SYNCNT;
> static int ip_ping_group_range_min[] = { 0, 0 };
> static int ip_ping_group_range_max[] = { GID_T_MAX, GID_T_MAX };
> static int comp_sack_nr_max = 255;
> +static int tcp_probe_interval_min = 300;
>
> /* obsolete */
> static int sysctl_tcp_low_latency __read_mostly;
> @@ -711,7 +712,8 @@ static struct ctl_table ipv4_net_table[] = {
> .data = &init_net.ipv4.sysctl_tcp_probe_interval,
> .maxlen = sizeof(int),
> .mode = 0644,
> - .proc_handler = proc_dointvec,
> + .proc_handler = proc_dointvec_minmax,
> + .extra1 = &tcp_probe_interval_min,
> },
> {
> .procname = "igmp_link_local_mcast_reports",
>
Note that this change would stop people from being able to have packetdrill
tests which would run in a reasonable amount of time.
I do not believe linux kernel must enforce such a limit.
It is up to the admin to set a value here really, depending on the environment
the host is running in.
^ permalink raw reply
* Re: [PATCH 15/18] rhashtable: use bit_spin_locks to protect hash bucket.
From: Eric Dumazet @ 2018-06-02 9:53 UTC (permalink / raw)
To: Herbert Xu, NeilBrown
Cc: Thomas Graf, netdev, linux-kernel, Eric Dumazet, David S. Miller
In-Reply-To: <20180602050322.liesw324q5kawcue@gondor.apana.org.au>
On 06/02/2018 01:03 AM, Herbert Xu wrote:
> Yes the concept looks good to me. But I would like to hear from
> Eric/Dave as to whether this would be acceptable for existing
> network hash tables such as the ones in inet.
What about lockdep support ?
^ permalink raw reply
* Re: [PATCH net v2] ipv6: omit traffic class when calculating flow hash
From: Ido Schimmel @ 2018-06-02 9:39 UTC (permalink / raw)
To: Michal Kubecek
Cc: David S. Miller, netdev, linux-kernel, Nicolas Dichtel,
Tom Herbert, David Ahern
In-Reply-To: <20180602080528.54B27A0C48@unicorn.suse.cz>
On Sat, Jun 02, 2018 at 09:40:34AM +0200, Michal Kubecek wrote:
> Some of the code paths calculating flow hash for IPv6 use flowlabel member
> of struct flowi6 which, despite its name, encodes both flow label and
> traffic class. If traffic class changes within a TCP connection (as e.g.
> ssh does), ECMP route can switch between path. It's also incosistent with
> other code paths where ip6_flowlabel() (returning only flow label) is used
> to feed the key.
>
> Use only flow label everywhere, including one place where hash key is set
> using ip6_flowinfo().
>
> Fixes: 51ebd3181572 ("ipv6: add support of equal cost multipath (ECMP)")
> Fixes: f70ea018da06 ("net: Add functions to get skb->hash based on flow structures")
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Tested-by: Ido Schimmel <idosch@mellanox.com>
^ permalink raw reply
* Lucrative Business Proposal
From: Adrien Saif @ 2018-06-02 9:04 UTC (permalink / raw)
--
Dear Friend,
I would like to discuss a very important issue with you. I am writing
to find out if this is your valid email. Please, let me know if this
email is valid
Kind regards
Adrien Saif
Attorney to Quatif Group of Companies
^ permalink raw reply
* Re: [PATCH net] ipv6: omit traffic class when calculating flow hash
From: Michal Kubecek @ 2018-06-02 7:54 UTC (permalink / raw)
To: Ido Schimmel
Cc: David S. Miller, netdev, linux-kernel, Nicolas Dichtel,
Tom Herbert, David Ahern
In-Reply-To: <20180601181929.GA16452@splinter>
On Fri, Jun 01, 2018 at 09:19:29PM +0300, Ido Schimmel wrote:
> On Fri, Jun 01, 2018 at 12:34:41PM +0200, Michal Kubecek wrote:
> > Some of the code paths calculating flow hash for IPv6 use flowlabel member
> > of struct flowi6 which, despite its name, encodes both flow label and
> > traffic class. If traffic class changes within a TCP connection (as e.g.
> > ssh does), ECMP route can switch between path. It's also incosistent with
> > other code paths where ip6_flowlabel() (returning only flow label) is used
> > to feed the key.
> >
> > Use only flow label everywhere, including one place where hash key is set
> > using ip6_flowinfo().
> >
> > Fixes: 51ebd3181572 ("ipv6: add support of equal cost multipath (ECMP)")
> > Fixes: f70ea018da06 ("net: Add functions to get skb->hash based on flow structures")
> > Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
>
> Please consider adding a test case to
> tools/testing/selftests/net/fib_tests.sh
>
> Personally, I tested the patch by looping over different values of 'tos'
> for 'ip route get' and confirmed that the same nexthop is selected.
Thanks for the tip, I'll look into it next week.
Michal Kubecek
^ permalink raw reply
* re
From: Ms. Ella Golan @ 2018-06-02 6:53 UTC (permalink / raw)
To: Recipients
I am Ms.Ella Golan, I am the Executive Vice President Banking Division with FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI). I am getting in touch with you regarding an extremely important and urgent matter. If you would oblige me the opportunity, I shall provide you with details upon your response.
Faithfully,
Ms.Ella Golan
^ permalink raw reply
* [PATCH net v2] ipv6: omit traffic class when calculating flow hash
From: Michal Kubecek @ 2018-06-02 7:40 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Nicolas Dichtel, Tom Herbert, David Ahern,
Ido Schimmel
Some of the code paths calculating flow hash for IPv6 use flowlabel member
of struct flowi6 which, despite its name, encodes both flow label and
traffic class. If traffic class changes within a TCP connection (as e.g.
ssh does), ECMP route can switch between path. It's also incosistent with
other code paths where ip6_flowlabel() (returning only flow label) is used
to feed the key.
Use only flow label everywhere, including one place where hash key is set
using ip6_flowinfo().
Fixes: 51ebd3181572 ("ipv6: add support of equal cost multipath (ECMP)")
Fixes: f70ea018da06 ("net: Add functions to get skb->hash based on flow structures")
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
---
v2: introduce and use an inline helper as suggested by David Ahern
include/net/ipv6.h | 5 +++++
net/core/flow_dissector.c | 2 +-
net/ipv6/route.c | 4 ++--
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 836f31af1369..7fbdc3e9e25d 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -906,6 +906,11 @@ static inline __be32 ip6_make_flowinfo(unsigned int tclass, __be32 flowlabel)
return htonl(tclass << IPV6_TCLASS_SHIFT) | flowlabel;
}
+static inline u32 flowi6_get_flowlabel(const struct flowi6 *fl6)
+{
+ return (__force u32)(fl6->flowlabel & IPV6_FLOWLABEL_MASK);
+}
+
/*
* Prototypes exported by ipv6
*/
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index d29f09bc5ff9..64e5cb8c0b3e 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -1334,7 +1334,7 @@ __u32 __get_hash_from_flowi6(const struct flowi6 *fl6, struct flow_keys *keys)
keys->ports.src = fl6->fl6_sport;
keys->ports.dst = fl6->fl6_dport;
keys->keyid.keyid = fl6->fl6_gre_key;
- keys->tags.flow_label = (__force u32)fl6->flowlabel;
+ keys->tags.flow_label = flowi6_get_flowlabel(fl6);
keys->basic.ip_proto = fl6->flowi6_proto;
return flow_hash_from_keys(keys);
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index f4d61736c41a..b208cd597510 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1868,7 +1868,7 @@ static void ip6_multipath_l3_keys(const struct sk_buff *skb,
} else {
keys->addrs.v6addrs.src = key_iph->saddr;
keys->addrs.v6addrs.dst = key_iph->daddr;
- keys->tags.flow_label = ip6_flowinfo(key_iph);
+ keys->tags.flow_label = ip6_flowlabel(key_iph);
keys->basic.ip_proto = key_iph->nexthdr;
}
}
@@ -1889,7 +1889,7 @@ u32 rt6_multipath_hash(const struct net *net, const struct flowi6 *fl6,
} else {
hash_keys.addrs.v6addrs.src = fl6->saddr;
hash_keys.addrs.v6addrs.dst = fl6->daddr;
- hash_keys.tags.flow_label = (__force u32)fl6->flowlabel;
+ hash_keys.tags.flow_label = flowi6_get_flowlabel(fl6);
hash_keys.basic.ip_proto = fl6->flowi6_proto;
}
break;
--
2.17.1
^ permalink raw reply related
* Re: ANNOUNCE: Enhanced IP v1.4
From: Willy Tarreau @ 2018-06-02 5:57 UTC (permalink / raw)
To: Sam Patton; +Cc: netdev
In-Reply-To: <d5377a99-da2d-583f-2a8c-72b58223c14a@enhancedip.org>
Hello Sam,
On Fri, Jun 01, 2018 at 09:48:28PM -0400, Sam Patton wrote:
> Hello!
>
> If you do not know what Enhanced IP is, read this post on netdev first:
>
> https://www.spinics.net/lists/netdev/msg327242.html
>
>
> The Enhanced IP project presents:
>
> Enhanced IP v1.4
>
> The Enhanced IP (EnIP) code has been updated. It now builds with OpenWRT barrier breaker (for 148 different devices). We've been testing with the Western Digital N600 and N750 wireless home routers.
(...) First note, please think about breaking your lines if you want your
mails to be read by the widest audience, as for some of us here, reading
lines wider than a terminal is really annoying, and often not considered
worth spending time on them considering there are so many easier ones
left to read.
> Interested in seeing Enhanced IP in the Linux kernel, read on. Not
> interested in seeing Enhanced IP in the Linux kernel read on.
(...)
So I personally find the concept quite interesting. It reminds me of the
previous IPv5/IPv7/IPv8 initiatives, which in my opinion were a bit hopeless.
Here the fact that you decide to consider the IPv4 address as a network opens
new perspectives. For containerized environments it could be considered that
each server, with one IPv4, can host 2^32 guests and that NAT is not needed
anymore for example. It could also open the possibility that enthousiasts
can more easily host some services at home behind their ADSL line without
having to run on strange ports.
However I think your approach is not the most efficient to encourage adoption.
It's important to understand that there will be little incentive for people
to patch their kernels to run some code if they don't have the applications
on top of it. The kernel is not the end goal for most users, the kernel is
just the lower layer needed to run applications on top. I looked at your site
and the github repo, and all I could find was a pre-patched openssh, no simple
explanation of what to change in an application.
What you need to do first is to *explain* how to modify userland applications
to support En-IP, provide an echo server and show the parts which have to be
changed. Write a simple client and do the same. Provide your changes to
existing programs as patches, not as pre-patched code. This way anyone can
use your patches on top of other versions, and can use these patches to
understand what has to be modified in their applications.
Once applications are easy to patch, the incentive to install patched kernels
everywhere will be higher. For many enthousiasts, knowing that they only have
to modify the ADSL router to automatically make their internal IoT stuff
accessible from outside indeed becomes appealing.
Then you'll need to provide patches for well known applications like curl,
wget, DNS servers (bind...), then browsers.
In my case I could be interested in adding support for En-ip into haproxy,
and only once I don't see any showstopped in doing this, I'd be willing to
patch my kernel to support it.
Last advice, provide links to your drafts in future e-mails, they are not
easy to find on your site, we have to navigate through various pages to
finally find them.
Regards,
Willy
^ permalink raw reply
* pull-request: bpf 2018-06-02
From: Daniel Borkmann @ 2018-06-02 5:07 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) BPF uapi fix in struct bpf_prog_info and struct bpf_map_info in
order to fix offsets on 32 bit archs.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
This will have a minor merge conflict with net-next which has the
__u32 gpl_compatible:1 bitfield in struct bpf_prog_info at this
location. Resolution is to use the gpl_compatible member.
Thanks a lot!
----------------------------------------------------------------
The following changes since commit 8005b09d99fac78e6f5fb9da30b5ae94840af03b:
net: ethernet: davinci_emac: fix error handling in probe() (2018-05-31 16:12:00 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
for you to fetch changes up to 36f9814a494a874d5a0f44843544b4b2539022db:
bpf: fix uapi hole for 32 bit compat applications (2018-06-01 20:41:35 -0700)
----------------------------------------------------------------
Daniel Borkmann (1):
bpf: fix uapi hole for 32 bit compat applications
include/uapi/linux/bpf.h | 2 ++
tools/include/uapi/linux/bpf.h | 2 ++
2 files changed, 4 insertions(+)
^ permalink raw reply
* Re: [PATCH rdma-next v3 05/14] IB/uverbs: Add create/destroy counters support
From: Leon Romanovsky @ 2018-06-02 5:05 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Boris Pismenny, Matan Barak,
Michael J . Ruhl, Or Gerlitz, Raed Salem, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180601205436.GA20377@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 2984 bytes --]
On Fri, Jun 01, 2018 at 02:54:36PM -0600, Jason Gunthorpe wrote:
> > diff --git a/drivers/infiniband/core/uverbs_std_types_counters.c b/drivers/infiniband/core/uverbs_std_types_counters.c
> > new file mode 100644
> > index 000000000000..a5bc50ceee13
> > +++ b/drivers/infiniband/core/uverbs_std_types_counters.c
> > @@ -0,0 +1,100 @@
> > +/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) */
>
> Check patch tells me this is malformed should be:
>
> // SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
>
> Apparently the WITH Linux-syscall-note is only used in uapi header
> files.
>
> > +/*
> > + * Copyright (c) 2018, Mellanox Technologies inc. All rights reserved.
> > + *
> > + * This software is available to you under a choice of one of two
> > + * licenses. You may choose to be licensed under the terms of the GNU
> > + * General Public License (GPL) Version 2, available from the file
> > + * COPYING in the main directory of this source tree, or the
> > + * OpenIB.org BSD license below:
> > + *
> > + * Redistribution and use in source and binary forms, with or
> > + * without modification, are permitted provided that the following
> > + * conditions are met:
> > + *
> > + * - Redistributions of source code must retain the above
> > + * copyright notice, this list of conditions and the following
> > + * disclaimer.
> > + *
> > + * - Redistributions in binary form must reproduce the above
> > + * copyright notice, this list of conditions and the following
> > + * disclaimer in the documentation and/or other materials
> > + * provided with the distribution.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> > + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> > + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> > + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> > + * SOFTWARE.
> > + */
>
> And this is not a SPDX BSD-2-Clause license, this is the SPDX
> Linux-OpenIB license.
>
> Please be careful to use the correct tag with SPDX..
>
> Also can you check if these SPDX tags are what are intended:
>
> include/rdma/restrack.h:/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
> drivers/infiniband/core/restrack.c:/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
> drivers/infiniband/hw/mlx5/ib_rep.c:/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
> drivers/infiniband/hw/mlx5/ib_rep.h:/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
>
> I'm not super excited about the license proliferation, so if they
> should have been OR Linux-OpenIB as well then please send a patch.
They are supposed to be OpenIB.
Thanks
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH rdma-next v3 00/14] Verbs flow counters support
From: Leon Romanovsky @ 2018-06-02 5:04 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Boris Pismenny, Matan Barak,
Michael J . Ruhl, Or Gerlitz, Raed Salem, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180601211149.GA24028@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]
On Fri, Jun 01, 2018 at 03:11:49PM -0600, Jason Gunthorpe wrote:
> On Thu, May 31, 2018 at 04:43:27PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > Changelog:
> > v2->v3:
> > * Change function mlx5_fc_query signature to hide the details of
> > internal core driver struct mlx5_fc
> > * Add commen to data[] field at struct mlx5_ib_flow_counters_data (mlx5-abi.h)
> > * Use array of struct mlx5_ib_flow_counters_desc to clarify the output
> > v1->v2:
> > * Removed conversion from struct mlx5_fc* to void*
> > * Fixed one place with double space in it
> > * Balanced release of hardware handler in case of counters allocation failure
> > * Added Tested-by
> > * Minimize time spent holding mutex lock
> > * Fixed deadlock caused by nested lock in error path
> > * Protect from handler pointer derefence in the error paths
>
> Okay,
>
> Acked-by: Jason Gunthorpe <jgg@mellanox.com>
>
> I've revised some of the commit messages, fixed the two bad
> check-patch warnings, and fixed the patch ordering..
>
> https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/log/?h=wip/jgg-counters
>
> Please send a PR with the mlx-core bits and above commits.
Hi,
I applied two mlx5-next commits to the relevant tree:
https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/commit/?h=mlx5-next&id=930821e39d0a5f91ed58fea1692afe04f0fe0e1f
https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/commit/?h=mlx5-next&id=5f9bf63ae80c4d0e5e986b6c1280bf8174978545
In first commit, I dropped the words "as used to be", per-Saeed's request.
The proper signed tag for whole the series is: verbs_flow_counters
git://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git tags/verbs_flow_counters
Thanks
>
> Thanks,
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 15/18] rhashtable: use bit_spin_locks to protect hash bucket.
From: Herbert Xu @ 2018-06-02 5:03 UTC (permalink / raw)
To: NeilBrown
Cc: Thomas Graf, netdev, linux-kernel, Eric Dumazet, David S. Miller
In-Reply-To: <152782824984.30340.1634082820568216846.stgit@noble>
On Fri, Jun 01, 2018 at 02:44:09PM +1000, NeilBrown wrote:
> This patch changes rhashtables to use a bit_spin_lock (BIT(1))
> the bucket pointer to lock the hash chain for that bucket.
>
> The benefits of a bit spin_lock are:
> - no need to allocate a separate array of locks.
> - no need to have a configuration option to guide the
> choice of the size of this array
> - locking cost if often a single test-and-set in a cache line
> that will have to be loaded anyway. When inserting at, or removing
> from, the head of the chain, the unlock is free - writing the new
> address in the bucket head implicitly clears the lock bit.
> - even when lockings costs 2 updates (lock and unlock), they are
> in a cacheline that needs to be read anyway.
>
> The cost of using a bit spin_lock is a little bit of code complexity,
> which I think is quite manageable.
>
> Bit spin_locks are sometimes inappropriate because they are not fair -
> if multiple CPUs repeatedly contend of the same lock, one CPU can
> easily be starved. This is not a credible situation with rhashtable.
> Multiple CPUs may want to repeatedly add or remove objects, but they
> will typically do so at different buckets, so they will attempt to
> acquire different locks.
>
> As we have more bit-locks than we previously had spinlocks (by at
> least a factor of two) we can expect slightly less contention to
> go with the slightly better cache behavior and reduced memory
> consumption.
>
> Signed-off-by: NeilBrown <neilb@suse.com>
...
> @@ -74,6 +71,61 @@ struct bucket_table {
> struct rhash_head __rcu *buckets[] ____cacheline_aligned_in_smp;
> };
>
> +/*
> + * We lock a bucket by setting BIT(1) in the pointer - this is always
> + * zero in real pointers and in the nulls marker.
> + * bit_spin_locks do not handle contention well, but the whole point
> + * of the hashtable design is to achieve minimum per-bucket contention.
> + * A nested hash table might not have a bucket pointer. In that case
> + * we cannot get a lock. For remove and replace the bucket cannot be
> + * interesting and doesn't need locking.
> + * For insert we allocate the bucket if this is the last bucket_table,
> + * and then take the lock.
> + * Sometimes we unlock a bucket by writing a new pointer there. In that
> + * case we don't need to unlock, but we do need to reset state such as
> + * local_bh. For that we have rht_unlocked(). This doesn't include
> + * the memory barrier that bit_spin_unlock() provides, but rcu_assign_pointer()
> + * will have provided that.
> + */
Yes the concept looks good to me. But I would like to hear from
Eric/Dave as to whether this would be acceptable for existing
network hash tables such as the ones in inet.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] samples/bpf: Add xdp_sample_pkts example
From: Daniel Borkmann @ 2018-06-02 4:22 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Song Liu; +Cc: Networking
In-Reply-To: <87a7sgcg7i.fsf@toke.dk>
On 05/31/2018 11:44 AM, Toke Høiland-Jørgensen wrote:
> Song Liu <liu.song.a23@gmail.com> writes:
>
>> On Wed, May 30, 2018 at 9:45 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>> This adds an example program showing how to sample packets from XDP using
>>> the perf event buffer. The example userspace program just prints the
>>> ethernet header for every packet sampled.
>>>
>>> Most of the userspace code is borrowed from other examples, most notably
>>> trace_output.
>>>
>>> Note that the example only works when everything runs on CPU0; so
>>> suitable smp_affinity needs to be set on the device. Some drivers seem
>>> to reset smp_affinity when loading an XDP program, so it may be
>>> necessary to change it after starting the example userspace program.
>>
>> Why does this only works when everything runs on CPU0? Is this
>> something we can improve?
>
> Yeah, good question. Basically, the call from XDP to
> bpf_perf_event_output() will fail with -EOPNOTSUPP. I tracked this down
> to this if statement in __bpf_perf_event_output() in bpf_trace.c:
>
>> if (unlikely(event->oncpu != cpu))
>> return -EOPNOTSUPP;
>
> I *think* that the way to fix this is for the userspace program to open
> a perf file descriptor for each CPU in the system and poll all of them,
> in which case the XDP program can pass the BPF_F_CURRENT_CPU flag to
> access the right one.
That is correct, you need one perf fd per cpu, and map them accordingly
into the map slots when you use BPF_F_CURRENT_CPU.
^ permalink raw reply
* Re: [PATCH bpf-next v4 0/5] fix test_sockmap
From: Daniel Borkmann @ 2018-06-02 4:16 UTC (permalink / raw)
To: Prashant Bhole, Alexei Starovoitov, John Fastabend
Cc: David S . Miller, Shuah Khan, netdev, linux-kselftest
In-Reply-To: <20180531044240.796-1-bhole_prashant_q7@lab.ntt.co.jp>
On 05/31/2018 06:42 AM, Prashant Bhole wrote:
> test_sockmap was originally written only to exercise kernel code
> paths, so there was no strict checking of errors. When the code was
> modified to run as selftests, due to lack of error handling it was not
> able to detect test failures.
>
> In order to improve, this series fixes error handling, test run time
> and data verification.
>
> Also slightly improved test output by printing parameter values (cork,
> apply, start, end) so that parameters for all tests are displayed.
>
> Changes in v4:
> - patch1: Ignore RX timoute error only for corked tests
> - patch3: Setting different timeout for corked tests and reduce
> run time by reducing number of iterations in some tests
>
> Changes in v3:
> - Skipped error checking for corked tests
>
> Prashant Bhole (5):
> selftests/bpf: test_sockmap, check test failure
> selftests/bpf: test_sockmap, join cgroup in selftest mode
> selftests/bpf: test_sockmap, timing improvements
> selftests/bpf: test_sockmap, fix data verification
> selftests/bpf: test_sockmap, print additional test options
>
> tools/testing/selftests/bpf/test_sockmap.c | 87 +++++++++++++++++-----
> 1 file changed, 67 insertions(+), 20 deletions(-)
>
Applied to bpf-next, thanks Prashant!
^ permalink raw reply
* Re: [PATCH bpf] bpf: fix uapi hole for 32 bit compat applications
From: Alexei Starovoitov @ 2018-06-02 3:50 UTC (permalink / raw)
To: Daniel Borkmann
Cc: ast, netdev, jakub.kicinski, kafai, songliubraving, ldv, esyr
In-Reply-To: <20180602032159.21199-1-daniel@iogearbox.net>
On Sat, Jun 02, 2018 at 05:21:59AM +0200, Daniel Borkmann wrote:
> In 64 bit, we have a 4 byte hole between ifindex and netns_dev in the
> case of struct bpf_map_info but also struct bpf_prog_info. In net-next
> commit b85fab0e67b ("bpf: Add gpl_compatible flag to struct bpf_prog_info")
> added a bitfield into it to expose some flags related to programs. Thus,
> add an unnamed __u32 bitfield for both so that alignment keeps the same
> in both 32 and 64 bit cases, and can be naturally extended from there
> as in b85fab0e67b.
>
>
> Reported-by: Dmitry V. Levin <ldv@altlinux.org>
> Reported-by: Eugene Syromiatnikov <esyr@redhat.com>
> Fixes: 52775b33bb507 ("bpf: offload: report device information about offloaded maps")
> Fixes: 675fc275a3a2d ("bpf: offload: report device information for offloaded programs")
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
Applied, Thanks.
^ permalink raw reply
* Re: [PATCH bpf 1/2] bpf: fix alignment of netns_dev/netns_ino fields in bpf_{map,prog}_info
From: Daniel Borkmann @ 2018-06-02 3:28 UTC (permalink / raw)
To: Song Liu, Eugene Syromiatnikov
Cc: netdev, open list, Martin KaFai Lau, Alexei Starovoitov,
David S. Miller, Jiri Olsa, Ingo Molnar, Lawrence Brakmo,
Andrey Ignatov, Jakub Kicinski, John Fastabend, Dmitry V. Levin
In-Reply-To: <CAPhsuW4v=V0mbz07xe_shd68WP3BoV8iofxyVGApi+sL9kgzWQ@mail.gmail.com>
On 05/29/2018 07:17 PM, Song Liu wrote:
> On Sun, May 27, 2018 at 4:28 AM, Eugene Syromiatnikov <esyr@redhat.com> wrote:
>> Recent introduction of netns_dev/netns_ino to bpf_map_info/bpf_prog info
>> has broken compat, as offsets of these fields are different in 32-bit
>> and 64-bit ABIs. One fix (other than implementing compat support in
>> syscall in order to handle this discrepancy) is to use __aligned_u64
>> instead of __u64 for these fields.
>>
>> Reported-by: Dmitry V. Levin <ldv@altlinux.org>
>> Fixes: 52775b33bb507 ("bpf: offload: report device information about
>> offloaded maps")
>> Fixes: 675fc275a3a2d ("bpf: offload: report device information for
>> offloaded programs")
>>
>> Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
>> ---
>> include/uapi/linux/bpf.h | 8 ++++----
>> tools/include/uapi/linux/bpf.h | 8 ++++----
>> 2 files changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>> index c5ec897..903010a 100644
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
>> @@ -1017,8 +1017,8 @@ struct bpf_prog_info {
>> __aligned_u64 map_ids;
>> char name[BPF_OBJ_NAME_LEN];
>> __u32 ifindex;
>> - __u64 netns_dev;
>> - __u64 netns_ino;
>> + __aligned_u64 netns_dev;
>> + __aligned_u64 netns_ino;
>> } __attribute__((aligned(8)));
>
> Shall we add a __u32 padding variable before netns_dev? We can use it
> for in the future.
Agree with Song, and definitely prefer that approach since we already use the hole
as a bitfield in net-next; like this https://patchwork.ozlabs.org/patch/924415/.
^ permalink raw reply
* [PATCH bpf] bpf: fix uapi hole for 32 bit compat applications
From: Daniel Borkmann @ 2018-06-02 3:21 UTC (permalink / raw)
To: ast
Cc: netdev, jakub.kicinski, kafai, songliubraving, ldv, esyr,
Daniel Borkmann
In 64 bit, we have a 4 byte hole between ifindex and netns_dev in the
case of struct bpf_map_info but also struct bpf_prog_info. In net-next
commit b85fab0e67b ("bpf: Add gpl_compatible flag to struct bpf_prog_info")
added a bitfield into it to expose some flags related to programs. Thus,
add an unnamed __u32 bitfield for both so that alignment keeps the same
in both 32 and 64 bit cases, and can be naturally extended from there
as in b85fab0e67b.
Before:
# file test.o
test.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
# pahole test.o
struct bpf_map_info {
__u32 type; /* 0 4 */
__u32 id; /* 4 4 */
__u32 key_size; /* 8 4 */
__u32 value_size; /* 12 4 */
__u32 max_entries; /* 16 4 */
__u32 map_flags; /* 20 4 */
char name[16]; /* 24 16 */
__u32 ifindex; /* 40 4 */
__u64 netns_dev; /* 44 8 */
__u64 netns_ino; /* 52 8 */
/* size: 64, cachelines: 1, members: 10 */
/* padding: 4 */
};
After (same as on 64 bit):
# file test.o
test.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
# pahole test.o
struct bpf_map_info {
__u32 type; /* 0 4 */
__u32 id; /* 4 4 */
__u32 key_size; /* 8 4 */
__u32 value_size; /* 12 4 */
__u32 max_entries; /* 16 4 */
__u32 map_flags; /* 20 4 */
char name[16]; /* 24 16 */
__u32 ifindex; /* 40 4 */
/* XXX 4 bytes hole, try to pack */
__u64 netns_dev; /* 48 8 */
__u64 netns_ino; /* 56 8 */
/* --- cacheline 1 boundary (64 bytes) --- */
/* size: 64, cachelines: 1, members: 10 */
/* sum members: 60, holes: 1, sum holes: 4 */
};
Reported-by: Dmitry V. Levin <ldv@altlinux.org>
Reported-by: Eugene Syromiatnikov <esyr@redhat.com>
Fixes: 52775b33bb507 ("bpf: offload: report device information about offloaded maps")
Fixes: 675fc275a3a2d ("bpf: offload: report device information for offloaded programs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
include/uapi/linux/bpf.h | 2 ++
tools/include/uapi/linux/bpf.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index c5ec897..8c31773 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -1017,6 +1017,7 @@ struct bpf_prog_info {
__aligned_u64 map_ids;
char name[BPF_OBJ_NAME_LEN];
__u32 ifindex;
+ __u32 :32;
__u64 netns_dev;
__u64 netns_ino;
} __attribute__((aligned(8)));
@@ -1030,6 +1031,7 @@ struct bpf_map_info {
__u32 map_flags;
char name[BPF_OBJ_NAME_LEN];
__u32 ifindex;
+ __u32 :32;
__u64 netns_dev;
__u64 netns_ino;
} __attribute__((aligned(8)));
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index c5ec897..8c31773 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -1017,6 +1017,7 @@ struct bpf_prog_info {
__aligned_u64 map_ids;
char name[BPF_OBJ_NAME_LEN];
__u32 ifindex;
+ __u32 :32;
__u64 netns_dev;
__u64 netns_ino;
} __attribute__((aligned(8)));
@@ -1030,6 +1031,7 @@ struct bpf_map_info {
__u32 map_flags;
char name[BPF_OBJ_NAME_LEN];
__u32 ifindex;
+ __u32 :32;
__u64 netns_dev;
__u64 netns_ino;
} __attribute__((aligned(8)));
--
2.9.5
^ permalink raw reply related
* ANNOUNCE: Enhanced IP v1.4
From: Sam Patton @ 2018-06-02 1:48 UTC (permalink / raw)
To: netdev
Hello!
If you do not know what Enhanced IP is, read this post on netdev first:
https://www.spinics.net/lists/netdev/msg327242.html
The Enhanced IP project presents:
Enhanced IP v1.4
The Enhanced IP (EnIP) code has been updated. It now builds with OpenWRT barrier breaker (for 148 different devices). We've been testing with the Western Digital N600 and N750 wireless home routers.
Interested in seeing Enhanced IP in the Linux kernel, read on. Not interested in seeing Enhanced IP in the Linux kernel read on.
Here's the value proposition: if the Internet community wants to pass IP option 26 in the fast path (a scriptable single command enables this for Juniper and Cisco ISPs). Because this is easier than repeering globally(IPv6), this could in a relatively short period of time become a wide-spread option for use of IP option 26 WAN support. Further, for experimentation to begin with EnIP, it is not necessary for IP option 26 to be passed in the fast path. Quickly enabling WAN support is something IPv6 cannot do. Yes, NATs have to be upgraded. This is not optimal. All that being said, the protocol is much much simpler to understand than IPv6. It is an evolution (similar to how CIDR and NAT became pervasive over time in the 1990's). We have a lot of users who want to try the technology out but most of them are not patch your kernel kinds of people. It would work a lot better if Enhanced IP was an option available in standard kernels.
We are new to the Linux kernel community and would take advice on the code. If you look at our repository you will find that every file we update has a comment with the phrase "enhanced ip" so it is easy to see where we have made changes. We are maintaining separate patches across five kernels at the moment. Each new kernel requires a seperate porting process. It takes 30 minutes-1 hour to get all the patch points reinstalled and a little more time to test. We are especially interested in ideas people might have about integrating Enhanced IP with the IPv4 icmp code. I have been able to shim the rest of the code into the existing tcp/udp/ipv4 code base without much trouble. However, the icmp code is a different animal and I would welcome help from another developer(e.g. code patches). At present you can do tcp and udp sockets only. If a message such as an icmp port unreachable needs to be sent to an EnIP address it does not work. We are also working on the process by which we will accept patches to EnIP. We were thinking about adopting the OpenWRT process but would certainly be willing to listen to other arguments based on experience. Enhanced IP is a hobby project, so we're not looking to come up with our own process. Rather, we would happily adopt a simple/terse process.
We've used Apache, samba, and ssh/scp over EnIP. Basically, anything that uses getaddrinfo followed by connect should work fine. E.g. we think all the code that has already been ported to use getaddrinfo pattern for IPv6 compatibility should also work with EnIP.
Our web site:
http://www.enhancedip.org/
Our git:
git clone https://github.com/EnIP/enhancedip.git
Our test virtual machines (write kernel code with VMs to simulate end to
end EnIP connections):
http://www.enhancedip.org/ENIP/
Thank you for your time.
-Sam Patton
^ permalink raw reply
* [net-next:master 379/381] drivers/net/ethernet/marvell/mvpp2/mvpp2.h:553:2: warning: overflow in implicit constant conversion
From: kbuild test robot @ 2018-06-02 1:31 UTC (permalink / raw)
To: Maxime Chevallier; +Cc: kbuild-all, netdev
[-- Attachment #1: Type: text/plain, Size: 4566 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: 21ad1173589ef63a93f94e05c879393e2c27588c
commit: db9d7d36eecc8926f03a8f2e46781887577b3353 [379/381] net: mvpp2: Split the PPv2 driver to a dedicated directory
config: s390-allmodconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout db9d7d36eecc8926f03a8f2e46781887577b3353
# save the attached .config to linux build tree
make.cross ARCH=s390
All warnings (new ones prefixed by >>):
In file included from drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:43:0:
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c: In function 'mvpp2_setup_bm_pool':
>> drivers/net/ethernet/marvell/mvpp2/mvpp2.h:553:2: warning: overflow in implicit constant conversion [-Woverflow]
((total_size) - NET_SKB_PAD - MVPP2_SKB_SHINFO_SIZE)
^
>> drivers/net/ethernet/marvell/mvpp2/mvpp2.h:604:33: note: in expansion of macro 'MVPP2_RX_MAX_PKT_SIZE'
#define MVPP2_BM_SHORT_PKT_SIZE MVPP2_RX_MAX_PKT_SIZE(MVPP2_BM_SHORT_FRAME_SIZE)
^~~~~~~~~~~~~~~~~~~~~
>> drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:543:41: note: in expansion of macro 'MVPP2_BM_SHORT_PKT_SIZE'
mvpp2_pools[MVPP2_BM_SHORT].pkt_size = MVPP2_BM_SHORT_PKT_SIZE;
^~~~~~~~~~~~~~~~~~~~~~~
vim +553 drivers/net/ethernet/marvell/mvpp2/mvpp2.h
532
533 /* TX FIFO constants */
534 #define MVPP22_TX_FIFO_DATA_SIZE_10KB 0xa
535 #define MVPP22_TX_FIFO_DATA_SIZE_3KB 0x3
536 #define MVPP2_TX_FIFO_THRESHOLD_MIN 256
537 #define MVPP2_TX_FIFO_THRESHOLD_10KB \
538 (MVPP22_TX_FIFO_DATA_SIZE_10KB * 1024 - MVPP2_TX_FIFO_THRESHOLD_MIN)
539 #define MVPP2_TX_FIFO_THRESHOLD_3KB \
540 (MVPP22_TX_FIFO_DATA_SIZE_3KB * 1024 - MVPP2_TX_FIFO_THRESHOLD_MIN)
541
542 /* RX buffer constants */
543 #define MVPP2_SKB_SHINFO_SIZE \
544 SKB_DATA_ALIGN(sizeof(struct skb_shared_info))
545
546 #define MVPP2_RX_PKT_SIZE(mtu) \
547 ALIGN((mtu) + MVPP2_MH_SIZE + MVPP2_VLAN_TAG_LEN + \
548 ETH_HLEN + ETH_FCS_LEN, cache_line_size())
549
550 #define MVPP2_RX_BUF_SIZE(pkt_size) ((pkt_size) + NET_SKB_PAD)
551 #define MVPP2_RX_TOTAL_SIZE(buf_size) ((buf_size) + MVPP2_SKB_SHINFO_SIZE)
552 #define MVPP2_RX_MAX_PKT_SIZE(total_size) \
> 553 ((total_size) - NET_SKB_PAD - MVPP2_SKB_SHINFO_SIZE)
554
555 #define MVPP2_BIT_TO_BYTE(bit) ((bit) / 8)
556
557 /* IPv6 max L3 address size */
558 #define MVPP2_MAX_L3_ADDR_SIZE 16
559
560 /* Port flags */
561 #define MVPP2_F_LOOPBACK BIT(0)
562
563 /* Marvell tag types */
564 enum mvpp2_tag_type {
565 MVPP2_TAG_TYPE_NONE = 0,
566 MVPP2_TAG_TYPE_MH = 1,
567 MVPP2_TAG_TYPE_DSA = 2,
568 MVPP2_TAG_TYPE_EDSA = 3,
569 MVPP2_TAG_TYPE_VLAN = 4,
570 MVPP2_TAG_TYPE_LAST = 5
571 };
572
573 /* L2 cast enum */
574 enum mvpp2_prs_l2_cast {
575 MVPP2_PRS_L2_UNI_CAST,
576 MVPP2_PRS_L2_MULTI_CAST,
577 };
578
579 /* L3 cast enum */
580 enum mvpp2_prs_l3_cast {
581 MVPP2_PRS_L3_UNI_CAST,
582 MVPP2_PRS_L3_MULTI_CAST,
583 MVPP2_PRS_L3_BROAD_CAST
584 };
585
586 /* BM constants */
587 #define MVPP2_BM_JUMBO_BUF_NUM 512
588 #define MVPP2_BM_LONG_BUF_NUM 1024
589 #define MVPP2_BM_SHORT_BUF_NUM 2048
590 #define MVPP2_BM_POOL_SIZE_MAX (16*1024 - MVPP2_BM_POOL_PTR_ALIGN/4)
591 #define MVPP2_BM_POOL_PTR_ALIGN 128
592
593 /* BM cookie (32 bits) definition */
594 #define MVPP2_BM_COOKIE_POOL_OFFS 8
595 #define MVPP2_BM_COOKIE_CPU_OFFS 24
596
597 #define MVPP2_BM_SHORT_FRAME_SIZE 512
598 #define MVPP2_BM_LONG_FRAME_SIZE 2048
599 #define MVPP2_BM_JUMBO_FRAME_SIZE 10240
600 /* BM short pool packet size
601 * These value assure that for SWF the total number
602 * of bytes allocated for each buffer will be 512
603 */
> 604 #define MVPP2_BM_SHORT_PKT_SIZE MVPP2_RX_MAX_PKT_SIZE(MVPP2_BM_SHORT_FRAME_SIZE)
605 #define MVPP2_BM_LONG_PKT_SIZE MVPP2_RX_MAX_PKT_SIZE(MVPP2_BM_LONG_FRAME_SIZE)
606 #define MVPP2_BM_JUMBO_PKT_SIZE MVPP2_RX_MAX_PKT_SIZE(MVPP2_BM_JUMBO_FRAME_SIZE)
607
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 49422 bytes --]
^ permalink raw reply
* [net-next 17/17] net/mlx5e: TX, Separate cachelines of xmit and completion stats
From: Saeed Mahameed @ 2018-06-02 0:05 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Tariq Toukan, Saeed Mahameed
In-Reply-To: <20180602000544.18717-1-saeedm@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Avoid false sharing of cachelines by separating the cachelines of
TX stats that are dertied in xmit flow and in completion flow.
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_stats.c | 8 ++++----
drivers/net/ethernet/mellanox/mlx5/core/en_stats.h | 9 +++++----
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_stats.c b/drivers/net/ethernet/mellanox/mlx5/core/en_stats.c
index 697dc7397ba2..1646859974ce 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_stats.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_stats.c
@@ -64,11 +64,11 @@ static const struct counter_desc sw_stats_desc[] = {
{ MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_csum_partial) },
{ MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_csum_partial_inner) },
{ MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_queue_stopped) },
- { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_queue_wake) },
{ MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_queue_dropped) },
{ MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_xmit_more) },
- { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_cqe_err) },
{ MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_recover) },
+ { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_queue_wake) },
+ { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_cqe_err) },
{ MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_wqe_err) },
{ MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_mpwqe_filler) },
{ MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_buff_alloc_err) },
@@ -1137,11 +1137,11 @@ static const struct counter_desc sq_stats_desc[] = {
{ MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, nop) },
{ MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, csum_none) },
{ MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, stopped) },
- { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, wake) },
{ MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, dropped) },
{ MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, xmit_more) },
- { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, cqe_err) },
{ MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, recover) },
+ { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, wake) },
+ { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, cqe_err) },
};
static const struct counter_desc ch_stats_desc[] = {
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_stats.h b/drivers/net/ethernet/mellanox/mlx5/core/en_stats.h
index 390c7afa5188..643153bb3607 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_stats.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_stats.h
@@ -75,11 +75,11 @@ struct mlx5e_sw_stats {
u64 tx_csum_partial;
u64 tx_csum_partial_inner;
u64 tx_queue_stopped;
- u64 tx_queue_wake;
u64 tx_queue_dropped;
u64 tx_xmit_more;
- u64 tx_cqe_err;
u64 tx_recover;
+ u64 tx_queue_wake;
+ u64 tx_cqe_err;
u64 rx_wqe_err;
u64 rx_mpwqe_filler;
u64 rx_buff_alloc_err;
@@ -203,10 +203,11 @@ struct mlx5e_sq_stats {
/* less likely accessed in data path */
u64 csum_none;
u64 stopped;
- u64 wake;
u64 dropped;
- u64 cqe_err;
u64 recover;
+ /* dirtied @completion */
+ u64 wake ____cacheline_aligned_in_smp;
+ u64 cqe_err;
};
struct mlx5e_ch_stats {
--
2.17.0
^ permalink raw reply related
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