* Re: [PATCH] samples/bpf: Fix cross compiler error with bpf sample
From: Joel Fernandes @ 2017-08-04 18:33 UTC (permalink / raw)
To: Daniel Borkmann
Cc: LKML, Alexei Starovoitov,
open list:BPF (Safe dynamic programs and tools)
In-Reply-To: <59847D97.8080003@iogearbox.net>
On Fri, Aug 4, 2017 at 6:58 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 08/04/2017 07:46 AM, Joel Fernandes wrote:
>>
>> When cross-compiling the bpf sample map_perf_test for aarch64, I find that
>> __NR_getpgrp is undefined. This causes build errors. Fix it by allowing
>> the
>> deprecated syscall in the sample.
>>
>> Signed-off-by: Joel Fernandes <joelaf@google.com>
>> ---
>> samples/bpf/map_perf_test_user.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/samples/bpf/map_perf_test_user.c
>> b/samples/bpf/map_perf_test_user.c
>> index 1a8894b5ac51..6e6fc7121640 100644
>> --- a/samples/bpf/map_perf_test_user.c
>> +++ b/samples/bpf/map_perf_test_user.c
>> @@ -8,7 +8,9 @@
>> #include <sched.h>
>> #include <stdio.h>
>> #include <sys/types.h>
>> +#define __ARCH_WANT_SYSCALL_DEPRECATED
>> #include <asm/unistd.h>
>> +#undef __ARCH_WANT_SYSCALL_DEPRECATED
>
>
> So the only arch that sets __ARCH_WANT_SYSCALL_DEPRECATED
> is score:
>
> $ git grep -n __ARCH_WANT_SYSCALL_DEPRECATED
> arch/score/include/uapi/asm/unistd.h:7:#define
> __ARCH_WANT_SYSCALL_DEPRECATED
> include/uapi/asm-generic/unistd.h:837:#ifdef
> __ARCH_WANT_SYSCALL_DEPRECATED
> include/uapi/asm-generic/unistd.h:899:#endif /*
> __ARCH_WANT_SYSCALL_DEPRECATED */
>
> But even if this would make aarch64 compile, the syscall
> numbers don't match up:
>
> $ git grep -n __NR_getpgrp include/uapi/asm-generic/unistd.h
> include/uapi/asm-generic/unistd.h:841:#define __NR_getpgrp 1060
> include/uapi/asm-generic/unistd.h:843:__SYSCALL(__NR_getpgrp, sys_getpgrp)
>
> The only thing that can be found on arm64 is:
>
> $ git grep -n __NR_getpgrp arch/arm64/
> arch/arm64/include/asm/unistd32.h:154:#define __NR_getpgrp 65
> arch/arm64/include/asm/unistd32.h:155:__SYSCALL(__NR_getpgrp, sys_getpgrp)
>
> In arch/arm64/include/asm/unistd.h, it does include the
> uapi/asm/unistd.h when compat is not set, but without the
> __ARCH_WANT_SYSCALL_DEPRECATED. That doesn't look correct
> unless I'm missing something, hmm, can't we just attach the
> kprobes to a different syscall, one that is not deprecated,
> so that we don't run into this in the first place?
Yes, I agree that's better. I think we can use getpgid. I'll try to
whip something today and send it out.
I also wanted to fix something else, HOSTCC is set to gcc, but I want
the boostrap part of the sample to run an ARM so I have to make HOSTCC
my cross-compiler. Right now I'm hacking it to point to the arm64 gcc
however I think I'd like to add a 'cross compile mode' or something
whether HOSTCC points to CROSS_COMPILE instead. I'm happy to discuss
any ideas to get this fixed too.
thanks!
-Joel
>
> Thanks,
> Daniel
^ permalink raw reply
* Re: [PATCH net] xgene: Always get clk source, but ignore if it's missing for SGMII ports
From: David Miller @ 2017-08-04 18:30 UTC (permalink / raw)
To: tsbogend; +Cc: isubramanian, kchudgar, qnguyen, netdev, linux-kernel, labbott
In-Reply-To: <20170803140311.34C7E50870B@solo.franken.de>
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Date: Thu, 3 Aug 2017 15:43:14 +0200
> From: Thomas Bogendoerfer <tbogendoerfer@suse.de>
>
> Even the driver doesn't do anything with the clk source for SGMII
> ports it needs to be enabled by doing a devm_clk_get(), if there is
> a clk source in DT.
>
> Fixes: 0db01097cabd ('xgene: Don't fail probe, if there is no clk resource for SGMII interfaces')
> Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
> Tested-by: Laura Abbott <labbott@redhat.com>
> Acked-by: Iyappan Subramanian <isubramanian@apm.com>
Applied, thanks.
^ permalink raw reply
* Re: [net-next PATCH v2] net: comment fixes against BPF devmap helper calls
From: David Miller @ 2017-08-04 18:29 UTC (permalink / raw)
To: john.fastabend; +Cc: daniel, ast, netdev
In-Reply-To: <20170804152404.28045.15462.stgit@john-Precision-Tower-5810>
From: John Fastabend <john.fastabend@gmail.com>
Date: Fri, 04 Aug 2017 08:24:05 -0700
> Update BPF comments to accurately reflect XDP usage.
>
> Fixes: 97f91a7cf04ff ("bpf: add bpf_redirect_map helper routine")
> Reported-by: Alexei Starovoitov <ast@kernel.org>
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 2/5] ipv6: sr: export SRH insertion functions
From: David Miller @ 2017-08-04 18:28 UTC (permalink / raw)
To: david.lebrun; +Cc: netdev
In-Reply-To: <20170804132415.9701-3-david.lebrun@uclouvain.be>
From: David Lebrun <david.lebrun@uclouvain.be>
Date: Fri, 4 Aug 2017 15:24:12 +0200
> +EXPORT_SYMBOL(seg6_do_srh_encap);
...
> +EXPORT_SYMBOL(seg6_do_srh_inline);
EXPORT_SYMBOL_GPL() please.
^ permalink raw reply
* Re: [PATCH] MIPS: Add missing file for eBPF JIT.
From: David Miller @ 2017-08-04 18:24 UTC (permalink / raw)
To: daniel
Cc: david.daney, ast, netdev, linux-kernel, linux-mips, ralf,
James.Cowgill, markos.chandras
In-Reply-To: <5984710F.4010301@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Fri, 04 Aug 2017 15:05:19 +0200
> On 08/04/2017 02:10 AM, David Daney wrote:
>> Inexplicably, commit f381bf6d82f0 ("MIPS: Add support for eBPF JIT.")
>> lost a file somewhere on its path to Linus' tree. Add back the
>> missing ebpf_jit.c so that we can build with CONFIG_BPF_JIT selected.
>>
>> This version of ebpf_jit.c is identical to the original except for two
>> minor change need to resolve conflicts with changes merged from the
>> BPF branch:
>>
>> A) Set prog->jited_len = image_size;
>> B) Use BPF_TAIL_CALL instead of BPF_CALL | BPF_X
>>
>> Fixes: f381bf6d82f0 ("MIPS: Add support for eBPF JIT.")
>> Signed-off-by: David Daney <david.daney@cavium.com>
>> ---
>>
>> It might be best to merge this along the path of BPF fixes rather than
>> MIPS, as the MIPS maintainer (Ralf) seems to be inactive recently.
>
> Looks like situation is that multiple people including myself tried
> to contact Ralf due to 'half/mis-applied' MIPS BPF JIT in [1,2] that
> sits currently in Linus tree, but never got a reply back since mid
> June.
>
> Given the work was accepted long ago but incorrectly merged, would be
> great if this could still be fixed up with this patch. Given Ralf
> seems
> unfortunately unresponsive, is there a chance, if people are fine with
> it, that we could try route this fix e.g. via -net instead before a
> final v4.13?
>
> Anyway, the generic pieces interacting with core BPF look good to me:
>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Ok, I've applied this to the net GIT tree.
Thanks.
^ permalink raw reply
* Re: [patch net-next v2 00/20] net: sched: summer cleanup part 1, mainly in exts area
From: David Miller @ 2017-08-04 18:23 UTC (permalink / raw)
To: jiri; +Cc: netdev, jhs, xiyou.wangcong, daniel, mlxsw
In-Reply-To: <20170804122915.15177-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 4 Aug 2017 14:28:55 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> This patchset is one of the couple cleanup patchsets I have in queue.
> The motivation aside the obvious need to "make things nicer" is also
> to prepare for shared filter blocks introduction. That requires tp->q
> removal, and therefore removal of all tp->q users.
>
> Patch 1 is just some small thing I spotted on the way
> Patch 2 removes one user of tp->q, namely tcf_em_tree_change
> Patches 3-8 do preparations for exts->nr_actions removal
> Patches 9-10 do simple renames of functions in cls*
> Patches 11-19 remove unnecessary calls of tcf_exts_change helper
> The last patch changes tcf_exts_change to don't take lock
>
> Tested by tools/testing/selftests/tc-testing
>
> v1->v2:
> - removed conversion of action array to list as noted by Cong
> - added the past patch instead
> - small rebases of patches 11-19
Series applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH net 0/2] Two BPF fixes for s390
From: David Miller @ 2017-08-04 18:19 UTC (permalink / raw)
To: daniel; +Cc: holzheu, ast, netdev
In-Reply-To: <cover.1501848914.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Fri, 4 Aug 2017 14:20:53 +0200
> Found while testing some other work touching JITs.
Series applied and patch #1 queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH net 3/3] tcp: fix xmit timer to only be reset if data ACKed/SACKed
From: Willy Tarreau @ 2017-08-04 18:18 UTC (permalink / raw)
To: Neal Cardwell
Cc: maowenan, David Miller, netdev@vger.kernel.org, Yuchung Cheng,
Nandita Dukkipati, Eric Dumazet
In-Reply-To: <CADVnQymnVwT30EzVvTfZ0EX_6ehRom1W8Yt2Z5SQHhmWO+e+sw@mail.gmail.com>
On Fri, Aug 04, 2017 at 02:01:34PM -0400, Neal Cardwell wrote:
> On Fri, Aug 4, 2017 at 1:10 PM, Willy Tarreau <w@1wt.eu> wrote:
> > Hi Neal,
> >
> > On Fri, Aug 04, 2017 at 12:59:51PM -0400, Neal Cardwell wrote:
> >> I have attached patches for this fix rebased on to v3.10.107, the
> >> latest stable release for 3.10. That's pretty far back in history, so
> >> there were substantial conflict resolutions and adjustments required.
> >> :-) Hope that helps.
> >
> > At least it will help me :-)
> >
> > Do you suggest that I queue them for 3.10.108, that I wait for Maowenan
> > to test them more broadly first or anything else ?
>
> Let's wait for Maowenan to test them first.
Fine, thanks.
Willy
^ permalink raw reply
* Re: [patch net 0/2] mlxsw: Couple of fixes
From: David Miller @ 2017-08-04 18:17 UTC (permalink / raw)
To: jiri; +Cc: netdev, idosch, mlxsw
In-Reply-To: <20170804121230.2144-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 4 Aug 2017 14:12:28 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> Ido says:
>
> The first patch prevents us from warning about valid situations that can
> happen due to the fact that some operations in switchdev are deferred.
>
> Second patch fixes a long standing problem in which we didn't correctly
> free resources upon module removal, resulting in a memory leak.
Series applied, thanks!
^ permalink raw reply
* Re: [PATCH net-next] net: hns: Fix for __udivdi3 compiler error
From: David Miller @ 2017-08-04 18:07 UTC (permalink / raw)
To: linyunsheng
Cc: huangdaode, xuwei5, liguozhu, Yisen.Zhuang, gabriele.paoloni,
john.garry, linuxarm, salil.mehta, lipeng321, tremyfr, netdev,
linux-kernel
In-Reply-To: <1501838699-95356-1-git-send-email-linyunsheng@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
Date: Fri, 4 Aug 2017 17:24:59 +0800
> This patch fixes the __udivdi3 undefined error reported by
> test robot.
>
> Fixes: b8c17f708831 ("net: hns: Add self-adaptive interrupt coalesce support in hns driver")
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Applied, thank you.
^ permalink raw reply
* [PATCH v5] ss: Enclose IPv6 address in brackets
From: Florian Lehner @ 2017-08-04 18:02 UTC (permalink / raw)
To: netdev
In-Reply-To: <fc81757c-8dbb-dbed-7a24-7011cb8bb9e0@der-flo.net>
This updated patch adds support for RFC2732 IPv6 address format with
brackets for the tool ss.
Now checking the complete IPv6 address if it is IN6ADDR_ANY.
Signed-off-by: Lehner Florian <dev@der-flo.net>
---
misc/ss.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/misc/ss.c b/misc/ss.c
index 12763c9..83683b5 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -1046,8 +1046,9 @@ do_numeric:
static void inet_addr_print(const inet_prefix *a, int port, unsigned
int ifindex)
{
- char buf[1024];
+ char buf[1024], buf2[1024];
const char *ap = buf;
+ char *c = NULL;
int est_len = addr_width;
const char *ifname = NULL;
@@ -1059,7 +1060,18 @@ static void inet_addr_print(const inet_prefix *a,
int port, unsigned int ifindex
ap = format_host(AF_INET, 4, a->data);
}
} else {
- ap = format_host(a->family, 16, a->data);
+ if (a->data[0] == 0 && a->data[1] == 0 &&
+ a->data[2] == 0 && a->data[3] == 0) {
+ buf[0] = '*';
+ buf[1] = 0;
+ } else {
+ ap = format_host(a->family, 16, a->data);
+ c = strchr(ap, ':');
+ if (c != NULL && a->family == AF_INET6) {
+ sprintf(buf2, "[%s]", ap);
+ ap = buf2;
+ }
+ }
est_len = strlen(ap);
if (est_len <= addr_width)
est_len = addr_width;
--
2.9.4
^ permalink raw reply related
* Re: [PATCH net 3/3] tcp: fix xmit timer to only be reset if data ACKed/SACKed
From: Neal Cardwell @ 2017-08-04 18:01 UTC (permalink / raw)
To: Willy Tarreau
Cc: maowenan, David Miller, netdev@vger.kernel.org, Yuchung Cheng,
Nandita Dukkipati, Eric Dumazet
In-Reply-To: <20170804171000.GB5342@1wt.eu>
On Fri, Aug 4, 2017 at 1:10 PM, Willy Tarreau <w@1wt.eu> wrote:
> Hi Neal,
>
> On Fri, Aug 04, 2017 at 12:59:51PM -0400, Neal Cardwell wrote:
>> I have attached patches for this fix rebased on to v3.10.107, the
>> latest stable release for 3.10. That's pretty far back in history, so
>> there were substantial conflict resolutions and adjustments required.
>> :-) Hope that helps.
>
> At least it will help me :-)
>
> Do you suggest that I queue them for 3.10.108, that I wait for Maowenan
> to test them more broadly first or anything else ?
Let's wait for Maowenan to test them first.
Thanks!
neal
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: logical vs bitwise OR typo
From: David Miller @ 2017-08-04 17:57 UTC (permalink / raw)
To: dan.carpenter; +Cc: andrew, f.fainelli, netdev, kernel-janitors
In-Reply-To: <20170804081720.2g6yuthplhc4rv6b@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Fri, 4 Aug 2017 11:17:21 +0300
> This was supposed to be a bitwise OR but there is a || vs | typo.
>
> Fixes: 864dc729d528 ("net: phy: marvell: Refactor m88e1121 RGMII delay configuration")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, but please specify "[PATCH net-next]" in your Subject line
and make your target tree explicit in the future.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next V2] net ipv6: convert fib6_table rwlock to a percpu lock
From: David Miller @ 2017-08-04 17:51 UTC (permalink / raw)
To: dsahern; +Cc: eric.dumazet, shli, netdev, Kernel-team, shli, weiwan, stephen
In-Reply-To: <a297a638-83e6-41bf-e803-9a3fd158ad00@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Fri, 4 Aug 2017 11:11:40 -0600
> On 8/4/17 11:07 AM, Eric Dumazet wrote:
>> On Fri, 2017-08-04 at 09:38 -0700, Shaohua Li wrote:
>>> From: Shaohua Li <shli@fb.com>
>>>
>>> In a syn flooding test, the fib6_table rwlock is a significant
>>> bottleneck. While converting the rwlock to rcu sounds straighforward,
>>> but is very challenging if it's possible. A percpu spinlock (lglock has
>>> been removed from kernel, so I added a simple implementation here) is
>>> quite trival for this problem since updating the routing table is a rare
>>> event. In my test, the server receives around 1.5 Mpps in syn flooding
>>> test without the patch in a dual sockets and 56-CPU system. With the
>>> patch, the server receives around 3.8Mpps, and perf report doesn't show
>>> the locking issue.
>>>
>>> Of course the percpu lock isn't as good as rcu, so this isn't intended
>>> to replace rcu, but this is much better than current readwrite lock.
>>> Before we have a rcu implementation, this is a good temporary solution.
>>> Plus, this is a trival change, there is nothing to prevent pursuing a
>>> rcu implmentation.
>>>
>>> Cc: Wei Wang <weiwan@google.com>
>>> Cc: Eric Dumazet <eric.dumazet@gmail.com>
>>> Cc: Stephen Hemminger <stephen@networkplumber.org>
>>> Signed-off-by: Shaohua Li <shli@fb.com>
>>> ---
>>
>> Wei has almost done the RCU conversion.
>>
>> This patch is probably coming too late.
>
>
> +1
>
> I'd rather see the RCU conversion than a move to per-cpu locks.
Me too.
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: logical vs bitwise OR typo
From: Andrew Lunn @ 2017-08-04 17:48 UTC (permalink / raw)
To: David Laight
Cc: 'Dan Carpenter', Florian Fainelli, netdev@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD004B432@AcuExch.aculab.com>
On Fri, Aug 04, 2017 at 02:54:45PM +0000, David Laight wrote:
> From: Dan Carpenter
> > Sent: 04 August 2017 09:17
> > This was supposed to be a bitwise OR but there is a || vs | typo.
> >
> > Fixes: 864dc729d528 ("net: phy: marvell: Refactor m88e1121 RGMII delay configuration")
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> >
> > diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> > index 361fe9927ef2..15cbcdba618a 100644
> > --- a/drivers/net/phy/marvell.c
> > +++ b/drivers/net/phy/marvell.c
> > @@ -83,7 +83,7 @@
> > #define MII_88E1121_PHY_MSCR_REG 21
> > #define MII_88E1121_PHY_MSCR_RX_DELAY BIT(5)
> > #define MII_88E1121_PHY_MSCR_TX_DELAY BIT(4)
> > -#define MII_88E1121_PHY_MSCR_DELAY_MASK (~(BIT(5) || BIT(4)))
> > +#define MII_88E1121_PHY_MSCR_DELAY_MASK (~(BIT(5) | BIT(4)))
>
> Wouldn't:
> +#define MII_88E1121_PHY_MSCR_DELAY_MASK (~(MII_88E1121_PHY_MSCR_RX_DELAY | MII_88E1121_PHY_MSCR_TX_DELAY))
> be more correct?
> If a little long?
> Actually the ~ looks odd here....
> Reads code....
> Kill the define and explicitly mask off the two values just before
> conditionally setting them.
Hi David
I will put this on my TODO list. But lets get Dan's fix included
first.
Andrew
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: logical vs bitwise OR typo
From: Andrew Lunn @ 2017-08-04 17:46 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Florian Fainelli, netdev, kernel-janitors
In-Reply-To: <20170804081720.2g6yuthplhc4rv6b@mwanda>
On Fri, Aug 04, 2017 at 11:17:21AM +0300, Dan Carpenter wrote:
> This was supposed to be a bitwise OR but there is a || vs | typo.
>
> Fixes: 864dc729d528 ("net: phy: marvell: Refactor m88e1121 RGMII delay configuration")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Hi Dan
Thanks for the fix.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: User per-cpu 64-bit statistics
From: Eric Dumazet @ 2017-08-04 17:43 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, davem, Andrew Lunn, Vivien Didelot, David S. Miller,
open list
In-Reply-To: <1501866711.25002.46.camel@edumazet-glaptop3.roam.corp.google.com>
On Fri, 2017-08-04 at 10:11 -0700, Eric Dumazet wrote:
> You could add a debug version of u64_stats_update_begin()
>
> doing
>
> int ret = atomic_inc((atomic_t *)syncp);
I meant atomic_inc_return() of course.
>
> BUG_ON(ret & 1);
>
>
> And u64_stats_update_end()
>
> int ret = atomic_inc((atomic_t *)syncp);
>
> BUG_ON(!(ret & 1));
>
>
> We probably could have a CONFIG_DEBUG_U64_STATS that could be used on
> 64bit kernels as well...
>
>
>
^ permalink raw reply
* Re: [PATCH net-next V2] net ipv6: convert fib6_table rwlock to a percpu lock
From: Wei Wang @ 2017-08-04 17:20 UTC (permalink / raw)
To: David Ahern, Eric Dumazet, Shaohua Li
Cc: Linux Kernel Network Developers, David S . Miller, Kernel-team,
Shaohua Li, Stephen Hemminger
In-Reply-To: <a297a638-83e6-41bf-e803-9a3fd158ad00@gmail.com>
On Fri, Aug 4, 2017 at 10:11 AM, David Ahern <dsahern@gmail.com> wrote:
> On 8/4/17 11:07 AM, Eric Dumazet wrote:
>> On Fri, 2017-08-04 at 09:38 -0700, Shaohua Li wrote:
>>> From: Shaohua Li <shli@fb.com>
>>>
>>> In a syn flooding test, the fib6_table rwlock is a significant
>>> bottleneck. While converting the rwlock to rcu sounds straighforward,
>>> but is very challenging if it's possible. A percpu spinlock (lglock has
>>> been removed from kernel, so I added a simple implementation here) is
>>> quite trival for this problem since updating the routing table is a rare
>>> event. In my test, the server receives around 1.5 Mpps in syn flooding
>>> test without the patch in a dual sockets and 56-CPU system. With the
>>> patch, the server receives around 3.8Mpps, and perf report doesn't show
>>> the locking issue.
>>>
>>> Of course the percpu lock isn't as good as rcu, so this isn't intended
>>> to replace rcu, but this is much better than current readwrite lock.
>>> Before we have a rcu implementation, this is a good temporary solution.
>>> Plus, this is a trival change, there is nothing to prevent pursuing a
>>> rcu implmentation.
>>>
>>> Cc: Wei Wang <weiwan@google.com>
>>> Cc: Eric Dumazet <eric.dumazet@gmail.com>
>>> Cc: Stephen Hemminger <stephen@networkplumber.org>
>>> Signed-off-by: Shaohua Li <shli@fb.com>
>>> ---
>>
>> Wei has almost done the RCU conversion.
>>
>> This patch is probably coming too late.
>
>
> +1
>
> I'd rather see the RCU conversion than a move to per-cpu locks.
I am actively working on the RCU conversion.
The main coding part is mostly done and I am working on testing it.
Some more time is needed to catch the rest of the missing pieces and
get the patches ready.
Thanks.
Wei
^ permalink raw reply
* Re: [PATCH net 1/2] bpf, s390: fix jit branch offset related to ldimm64
From: David Miller @ 2017-08-04 17:13 UTC (permalink / raw)
To: holzheu; +Cc: daniel, ast, netdev
In-Reply-To: <20170804191033.30bd8f03@TP-holzheu>
From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Date: Fri, 4 Aug 2017 19:10:33 +0200
> At least I would vote for "Cc: stable".
No, please do not ever do this for networking patches.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: User per-cpu 64-bit statistics
From: Eric Dumazet @ 2017-08-04 17:11 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, davem, Andrew Lunn, Vivien Didelot, David S. Miller,
open list
In-Reply-To: <455c39d3-302e-68ab-3812-112c48ed48c2@gmail.com>
On Fri, 2017-08-04 at 08:51 -0700, Florian Fainelli wrote:
> On 08/03/2017 10:36 PM, Eric Dumazet wrote:
> > On Thu, 2017-08-03 at 21:33 -0700, Florian Fainelli wrote:
> >> During testing with a background iperf pushing 1Gbit/sec worth of
> >> traffic and having both ifconfig and ethtool collect statistics, we
> >> could see quite frequent deadlocks. Convert the often accessed DSA slave
> >> network devices statistics to per-cpu 64-bit statistics to remove these
> >> deadlocks and provide fast efficient statistics updates.
> >>
> >
> > This seems to be a bug fix, it would be nice to get a proper tag like :
> >
> > Fixes: f613ed665bb3 ("net: dsa: Add support for 64-bit statistics")
>
> Right, should have been added, thanks!
>
> >
> > Problem here is that if multiple cpus can call dsa_switch_rcv() at the
> > same time, then u64_stats_update_begin() contract is not respected.
>
> This is really where I struggled understanding what is wrong in the
> non-per CPU version, my understanding is that we have:
>
> - writers for xmit executes in process context
> - writers for receive executes from NAPI (from the DSA's master network
> device through it's own NAPI doing netif_receive_skb -> netdev_uses_dsa
> -> netif_receive_skb)
>
> readers should all execute in process context. The test scenario that
> led to a deadlock involved running iperf in the background, having a
> while loop with both ifconfig and ethtool reading stats, and somehow
> when iperf exited, either reader would just be locked. So I guess this
> leaves us with the two writers not being mutually excluded then, right?
You could add a debug version of u64_stats_update_begin()
doing
int ret = atomic_inc((atomic_t *)syncp);
BUG_ON(ret & 1);
And u64_stats_update_end()
int ret = atomic_inc((atomic_t *)syncp);
BUG_ON(!(ret & 1));
We probably could have a CONFIG_DEBUG_U64_STATS that could be used on
64bit kernels as well...
^ permalink raw reply
* Re: [PATCH net-next V2] net ipv6: convert fib6_table rwlock to a percpu lock
From: David Ahern @ 2017-08-04 17:11 UTC (permalink / raw)
To: Eric Dumazet, Shaohua Li
Cc: netdev, davem, Kernel-team, Shaohua Li, Wei Wang,
Stephen Hemminger
In-Reply-To: <1501866461.25002.41.camel@edumazet-glaptop3.roam.corp.google.com>
On 8/4/17 11:07 AM, Eric Dumazet wrote:
> On Fri, 2017-08-04 at 09:38 -0700, Shaohua Li wrote:
>> From: Shaohua Li <shli@fb.com>
>>
>> In a syn flooding test, the fib6_table rwlock is a significant
>> bottleneck. While converting the rwlock to rcu sounds straighforward,
>> but is very challenging if it's possible. A percpu spinlock (lglock has
>> been removed from kernel, so I added a simple implementation here) is
>> quite trival for this problem since updating the routing table is a rare
>> event. In my test, the server receives around 1.5 Mpps in syn flooding
>> test without the patch in a dual sockets and 56-CPU system. With the
>> patch, the server receives around 3.8Mpps, and perf report doesn't show
>> the locking issue.
>>
>> Of course the percpu lock isn't as good as rcu, so this isn't intended
>> to replace rcu, but this is much better than current readwrite lock.
>> Before we have a rcu implementation, this is a good temporary solution.
>> Plus, this is a trival change, there is nothing to prevent pursuing a
>> rcu implmentation.
>>
>> Cc: Wei Wang <weiwan@google.com>
>> Cc: Eric Dumazet <eric.dumazet@gmail.com>
>> Cc: Stephen Hemminger <stephen@networkplumber.org>
>> Signed-off-by: Shaohua Li <shli@fb.com>
>> ---
>
> Wei has almost done the RCU conversion.
>
> This patch is probably coming too late.
+1
I'd rather see the RCU conversion than a move to per-cpu locks.
^ permalink raw reply
* Re: [PATCH net 1/2] bpf, s390: fix jit branch offset related to ldimm64
From: Michael Holzheu @ 2017-08-04 17:10 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, ast, netdev
In-Reply-To: <59847C2F.6010306@iogearbox.net>
Am Fri, 04 Aug 2017 15:52:47 +0200
schrieb Daniel Borkmann <daniel@iogearbox.net>:
> On 08/04/2017 03:44 PM, Michael Holzheu wrote:
> > Am Fri, 4 Aug 2017 14:20:54 +0200
> > schrieb Daniel Borkmann <daniel@iogearbox.net>:
> [...]
> >
> > What about "Cc: stable@vger.kernel.org"?
>
> Handled by Dave, see also: Documentation/networking/netdev-FAQ.txt +117
Thanks, good to know! At least I would vote for "Cc: stable".
Michael
^ permalink raw reply
* Re: [PATCH net 3/3] tcp: fix xmit timer to only be reset if data ACKed/SACKed
From: Willy Tarreau @ 2017-08-04 17:10 UTC (permalink / raw)
To: Neal Cardwell
Cc: maowenan, David Miller, netdev@vger.kernel.org, Yuchung Cheng,
Nandita Dukkipati
In-Reply-To: <CADVnQykAKkb7KDhM03HHOHk8Uk7rMfXcyaLsHMLZRVT_g69euA@mail.gmail.com>
Hi Neal,
On Fri, Aug 04, 2017 at 12:59:51PM -0400, Neal Cardwell wrote:
> I have attached patches for this fix rebased on to v3.10.107, the
> latest stable release for 3.10. That's pretty far back in history, so
> there were substantial conflict resolutions and adjustments required.
> :-) Hope that helps.
At least it will help me :-)
Do you suggest that I queue them for 3.10.108, that I wait for Maowenan
to test them more broadly first or anything else ?
I'm fine with any option.
Thanks!
Willy
^ permalink raw reply
* Re: [PATCH 0/3] ARM: dts: keystone-k2g: Add DCAN instances to 66AK2G
From: Santosh Shilimkar @ 2017-08-04 17:07 UTC (permalink / raw)
To: Franklin S Cooper Jr, wg, mkl, robh+dt, ssantosh, linux,
linux-can, netdev, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20170802201822.11532-1-fcooper@ti.com>
Hi Franklin,
On 8/2/2017 1:18 PM, Franklin S Cooper Jr wrote:
> Add D CAN nodes to 66AK2G based SoC dtsi.
>
> Franklin S Cooper Jr (2):
> dt-bindings: net: c_can: Update binding for clock and power-domains
> property
> ARM: configs: keystone: Enable D_CAN driver
>
> Lokesh Vutla (1):
> ARM: dts: k2g: Add DCAN nodes
>
Any DCAN driver dependency with these patchset ? If not, I can
queue this up so do let me know.
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH net-next V2] net ipv6: convert fib6_table rwlock to a percpu lock
From: Eric Dumazet @ 2017-08-04 17:07 UTC (permalink / raw)
To: Shaohua Li
Cc: netdev, davem, Kernel-team, Shaohua Li, Wei Wang,
Stephen Hemminger
In-Reply-To: <2dcefcf7e75a5c242a20d7904096be91addbfba7.1501864467.git.shli@fb.com>
On Fri, 2017-08-04 at 09:38 -0700, Shaohua Li wrote:
> From: Shaohua Li <shli@fb.com>
>
> In a syn flooding test, the fib6_table rwlock is a significant
> bottleneck. While converting the rwlock to rcu sounds straighforward,
> but is very challenging if it's possible. A percpu spinlock (lglock has
> been removed from kernel, so I added a simple implementation here) is
> quite trival for this problem since updating the routing table is a rare
> event. In my test, the server receives around 1.5 Mpps in syn flooding
> test without the patch in a dual sockets and 56-CPU system. With the
> patch, the server receives around 3.8Mpps, and perf report doesn't show
> the locking issue.
>
> Of course the percpu lock isn't as good as rcu, so this isn't intended
> to replace rcu, but this is much better than current readwrite lock.
> Before we have a rcu implementation, this is a good temporary solution.
> Plus, this is a trival change, there is nothing to prevent pursuing a
> rcu implmentation.
>
> Cc: Wei Wang <weiwan@google.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Shaohua Li <shli@fb.com>
> ---
Wei has almost done the RCU conversion.
This patch is probably coming too late.
^ 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