* [PATCH iproute2] ifstat/nstat: fix help output alignment
From: Mike Frysinger @ 2016-11-16 3:34 UTC (permalink / raw)
To: stephen.hemminger, netdev
Some lines use tabs while others use spaces. Use spaces everywhere.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
misc/ifstat.c | 24 ++++++++++++------------
misc/nstat.c | 22 +++++++++++-----------
2 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/misc/ifstat.c b/misc/ifstat.c
index d55197375e3c..92d67b0c5fd1 100644
--- a/misc/ifstat.c
+++ b/misc/ifstat.c
@@ -662,18 +662,18 @@ static void usage(void)
{
fprintf(stderr,
"Usage: ifstat [OPTION] [ PATTERN [ PATTERN ] ]\n"
-" -h, --help this message\n"
-" -a, --ignore ignore history\n"
-" -d, --scan=SECS sample every statistics every SECS\n"
-" -e, --errors show errors\n"
-" -j, --json format output in JSON\n"
-" -n, --nooutput do history only\n"
-" -p, --pretty pretty print\n"
-" -r, --reset reset history\n"
-" -s, --noupdate don\'t update history\n"
-" -t, --interval=SECS report average over the last SECS\n"
-" -V, --version output version information\n"
-" -z, --zeros show entries with zero activity\n");
+" -h, --help this message\n"
+" -a, --ignore ignore history\n"
+" -d, --scan=SECS sample every statistics every SECS\n"
+" -e, --errors show errors\n"
+" -j, --json format output in JSON\n"
+" -n, --nooutput do history only\n"
+" -p, --pretty pretty print\n"
+" -r, --reset reset history\n"
+" -s, --noupdate don't update history\n"
+" -t, --interval=SECS report average over the last SECS\n"
+" -V, --version output version information\n"
+" -z, --zeros show entries with zero activity\n");
exit(-1);
}
diff --git a/misc/nstat.c b/misc/nstat.c
index 1cb6c7eea27a..1212b1f2c812 100644
--- a/misc/nstat.c
+++ b/misc/nstat.c
@@ -526,17 +526,17 @@ static void usage(void)
{
fprintf(stderr,
"Usage: nstat [OPTION] [ PATTERN [ PATTERN ] ]\n"
-" -h, --help this message\n"
-" -a, --ignore ignore history\n"
-" -d, --scan=SECS sample every statistics every SECS\n"
-" -j, --json format output in JSON\n"
-" -n, --nooutput do history only\n"
-" -p, --pretty pretty print\n"
-" -r, --reset reset history\n"
-" -s, --noupdate don\'t update history\n"
-" -t, --interval=SECS report average over the last SECS\n"
-" -V, --version output version information\n"
-" -z, --zeros show entries with zero activity\n");
+" -h, --help this message\n"
+" -a, --ignore ignore history\n"
+" -d, --scan=SECS sample every statistics every SECS\n"
+" -j, --json format output in JSON\n"
+" -n, --nooutput do history only\n"
+" -p, --pretty pretty print\n"
+" -r, --reset reset history\n"
+" -s, --noupdate don't update history\n"
+" -t, --interval=SECS report average over the last SECS\n"
+" -V, --version output version information\n"
+" -z, --zeros show entries with zero activity\n");
exit(-1);
}
--
2.10.2
^ permalink raw reply related
* Re: [PATCH net-next v8 0/9] dpaa_eth: Add the QorIQ DPAA Ethernet driver
From: David Miller @ 2016-11-16 3:34 UTC (permalink / raw)
To: madalin.bucur
Cc: netdev, linuxppc-dev, linux-kernel, oss, ppc, joe, pebolle,
joakim.tjernlund
In-Reply-To: <1479199269-9748-1-git-send-email-madalin.bucur@nxp.com>
From: Madalin Bucur <madalin.bucur@nxp.com>
Date: Tue, 15 Nov 2016 10:41:00 +0200
> This patch series adds the Ethernet driver for the Freescale
> QorIQ Data Path Acceleration Architecture (DPAA).
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: marvell: Allow drivers to be built with COMPILE_TEST
From: kbuild test robot @ 2016-11-16 3:35 UTC (permalink / raw)
To: Florian Fainelli
Cc: kbuild-all, netdev, davem, mw, arnd, gregory.clement, Shaohui.Xie,
Igal.Liberman, Florian Fainelli
In-Reply-To: <20161115173548.32567-3-f.fainelli@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3163 bytes --]
Hi Florian,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-ethernet-Allow-Marvell-Freescale-to-COMPILE_TEST/20161116-024633
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `.mvneta_bm_pool_use':
>> (.text+0x19a18cc): undefined reference to `.mvebu_mbus_get_dram_win_info'
drivers/built-in.o: In function `.brcmf_create_iovar.constprop.1':
fwil.c:(.text+0x1ff95f0): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `.memcpy' defined in .text section in arch/powerpc/lib/built-in.o
fwil.c:(.text+0x1ff9614): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `.memcpy' defined in .text section in arch/powerpc/lib/built-in.o
drivers/built-in.o: In function `.brcmf_create_bsscfg.constprop.0':
fwil.c:(.text+0x1ff976c): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `.memcpy' defined in .text section in arch/powerpc/lib/built-in.o
fwil.c:(.text+0x1ff9790): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `.memcpy' defined in .text section in arch/powerpc/lib/built-in.o
drivers/built-in.o: In function `.brcmf_fil_cmd_data_get':
(.text+0x1ff9c7c): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `.debug_lockdep_rcu_enabled' defined in .text section in kernel/built-in.o
drivers/built-in.o: In function `.brcmf_fil_cmd_data_get':
(.text+0x1ff9dc4): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `.debug_lockdep_rcu_enabled' defined in .text section in kernel/built-in.o
drivers/built-in.o: In function `.brcmf_fil_iovar_data_set':
(.text+0x1ffa1ac): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `.debug_lockdep_rcu_enabled' defined in .text section in kernel/built-in.o
drivers/built-in.o: In function `.brcmf_fil_iovar_data_set':
(.text+0x1ffa2f4): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `.debug_lockdep_rcu_enabled' defined in .text section in kernel/built-in.o
drivers/built-in.o: In function `.brcmf_fil_iovar_data_get':
(.text+0x1ffa51c): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `.memcpy' defined in .text section in arch/powerpc/lib/built-in.o
drivers/built-in.o: In function `.brcmf_fil_iovar_data_get':
(.text+0x1ffa5fc): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `.debug_lockdep_rcu_enabled' defined in .text section in kernel/built-in.o
drivers/built-in.o: In function `.brcmf_fil_iovar_data_get':
(.text+0x1ffa744): additional relocation overflows omitted from the output
---
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: 51094 bytes --]
^ permalink raw reply
* Re: [PATCH net] rtnetlink: fix rtnl_vfinfo_size
From: David Miller @ 2016-11-16 3:42 UTC (permalink / raw)
To: sd; +Cc: netdev, eranbe, hadarh, ogerlitz, sucheta.chakraborty
In-Reply-To: <188991b3f1ede7ff1231f78411f4716cb5926950.1479202614.git.sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Tue, 15 Nov 2016 10:39:03 +0100
> The size reported by rtnl_vfinfo_size doesn't match the space used by
> rtnl_fill_vfinfo.
>
> rtnl_vfinfo_size currently doesn't account for the nest attributes
> used by statistics (added in commit 3b766cd83232), nor for struct
> ifla_vf_tx_rate (since commit ed616689a3d9, which added ifla_vf_rate
> to the dump without removing ifla_vf_tx_rate, but replaced
> ifla_vf_tx_rate with ifla_vf_rate in the size computation).
>
> Fixes: 3b766cd83232 ("net/core: Add reading VF statistics through the PF netdevice")
> Fixes: ed616689a3d9 ("net-next:v4: Add support to configure SR-IOV VF minimum and maximum Tx rate through ip tool")
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] rtnetlink: fix rtnl message size computation for XDP
From: David Miller @ 2016-11-16 3:43 UTC (permalink / raw)
To: sd; +Cc: netdev, bblanco
In-Reply-To: <0169d2419991a4ba533087a4fda70420ccdaca30.1479204870.git.sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Tue, 15 Nov 2016 11:16:35 +0100
> rtnl_xdp_size() only considers the size of the actual payload attribute,
> and misses the space taken by the attribute used for nesting (IFLA_XDP).
>
> Fixes: d1fdd9138682 ("rtnl: add option for setting link xdp prog")
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next v3 0/5] Adding PHY-Tunables and downshift support
From: David Miller @ 2016-11-16 3:44 UTC (permalink / raw)
To: allan.nielsen; +Cc: netdev, andrew, raju.lakkaraju
In-Reply-To: <1479205204-27768-1-git-send-email-allan.nielsen@microsemi.com>
From: "Allan W. Nielsen" <allan.nielsen@microsemi.com>
Date: Tue, 15 Nov 2016 11:19:59 +0100
> Old cover letters included below.
Please do not form your cover letter by quoting older and older
cover letters.
Always write a clean, single, cover letter with a changelog of
changed between each and every version leading up to the
current one.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next V2 0/9] alx: add multi queue support
From: David Miller @ 2016-11-16 3:46 UTC (permalink / raw)
To: tobias.regnery; +Cc: netdev, jcliburn, chris.snook
In-Reply-To: <cover.1479208627.git.tobias.regnery@gmail.com>
From: Tobias Regnery <tobias.regnery@gmail.com>
Date: Tue, 15 Nov 2016 12:43:07 +0100
> This patchset lays the groundwork for multi queue support in the alx driver
> and enables multi queue support for the tx path by default. The hardware
> supports up to 4 tx queues.
Series applied, thanks.
^ permalink raw reply
* RE: [PATCH] net: ioctl SIOCSIFADDR minor cleanup
From: YUAN Linyu @ 2016-11-16 3:57 UTC (permalink / raw)
To: David Miller; +Cc: cugyly@163.com, netdev@vger.kernel.org
In-Reply-To: <20161115.223111.734917440131578613.davem@davemloft.net>
No, this patch will not change dev->name,
It's care about ifa->ifa_label.
> - if (colon)
> - memcpy(ifa->ifa_label, ifr.ifr_name, IFNAMSIZ);
> - else
> - memcpy(ifa->ifa_label, dev->name, IFNAMSIZ);
When ifr.ifr_name have no colon, dev->name must equal to ifr.ifr_name.
So we change to
> - else
> - memcpy(ifa->ifa_label, ifr.ifr_name, IFNAMSIZ);
Then if and else do same thing. Just one line is enough,
memcpy(ifa->ifa_label, ifr.ifr_name, IFNAMSIZ);
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Wednesday, November 16, 2016 11:31 AM
> To: YUAN Linyu
> Cc: cugyly@163.com; netdev@vger.kernel.org
> Subject: Re: [PATCH] net: ioctl SIOCSIFADDR minor cleanup
>
> From: YUAN Linyu <Linyu.Yuan@alcatel-sbell.com.cn>
> Date: Wed, 16 Nov 2016 03:13:31 +0000
>
> > So assign label to request name will do same thing as original code.
>
> Nope. dev->name does not have the colon, it was trimmed from the
> string for the device lookup. So the found device's dev->name does
> not have the colon character, even if it was in ifr.ifr_name
>
> This was my entire point.
>
> You are changing the behvaior of the code in an invalid way.
^ permalink raw reply
* Re: [RFC PATCH 1/2] net: use cmpxchg instead of spinlock in ptr rings
From: John Fastabend @ 2016-11-16 4:30 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: jasowang, netdev, linux-kernel
In-Reply-To: <20161115002552-mutt-send-email-mst@kernel.org>
On 16-11-14 03:01 PM, Michael S. Tsirkin wrote:
> On Thu, Nov 10, 2016 at 08:44:08PM -0800, John Fastabend wrote:
>>
>> ---
>> include/linux/ptr_ring_ll.h | 136 +++++++++++++++++++++++++++++++++++++++++++
>> include/linux/skb_array.h | 25 ++++++++
>> 2 files changed, 161 insertions(+)
>> create mode 100644 include/linux/ptr_ring_ll.h
>>
>> diff --git a/include/linux/ptr_ring_ll.h b/include/linux/ptr_ring_ll.h
>> new file mode 100644
>> index 0000000..bcb11f3
>> --- /dev/null
>> +++ b/include/linux/ptr_ring_ll.h
>> @@ -0,0 +1,136 @@
>> +/*
>> + * Definitions for the 'struct ptr_ring_ll' datastructure.
>> + *
>> + * Author:
>> + * John Fastabend <john.r.fastabend@intel.com>
>> + *
>> + * Copyright (C) 2016 Intel Corp.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the
>> + * Free Software Foundation; either version 2 of the License, or (at your
>> + * option) any later version.
>> + *
>> + * This is a limited-size FIFO maintaining pointers in FIFO order, with
>> + * one CPU producing entries and another consuming entries from a FIFO.
>> + * extended from ptr_ring_ll to use cmpxchg over spin lock.
>
> So when is each one (ptr-ring/ptr-ring-ll) a win? _ll suffix seems to
> imply this gives a better latency, OTOH for a ping/pong I suspect
> ptr-ring would be better as it avoids index cache line bounces.
My observation under qdisc testing with pktgen is that I get better pps
numbers with this code vs ptr_ring using spinlock. I actually wrote
this implementation before the skb_array code was around though and
haven't done a thorough analysis of the two yet only pktgen benchmarks.
In my pktgen benchmarks I test 1:1 producer/consumer and many to one
producer/consumer tests. I'll post some numbers later this week.
[...]
>> + */
>> +static inline int __ptr_ring_ll_produce(struct ptr_ring_ll *r, void *ptr)
>> +{
>> + u32 ret, head, tail, next, slots, mask;
>> +
>> + do {
>> + head = READ_ONCE(r->prod_head);
>> + mask = READ_ONCE(r->prod_mask);
>> + tail = READ_ONCE(r->cons_tail);
>> +
>> + slots = mask + tail - head;
>> + if (slots < 1)
>> + return -ENOMEM;
>> +
>> + next = head + 1;
>> + ret = cmpxchg(&r->prod_head, head, next);
>> + } while (ret != head);
>
>
> So why is this preferable to a lock?
>
> I suspect it's nothing else than the qspinlock fairness
> and polling code complexity. It's all not very useful if you
> 1. are just doing a couple of instructions under the lock
> and
> 2. use a finite FIFO which is unfair anyway
>
>
> How about this hack (lifted from virt_spin_lock):
>
> static inline void quick_spin_lock(struct qspinlock *lock)
> {
> do {
> while (atomic_read(&lock->val) != 0)
> cpu_relax();
> } while (atomic_cmpxchg(&lock->val, 0, _Q_LOCKED_VAL) != 0);
> }
>
> Or maybe we should even drop the atomic_read in the middle -
> worth profiling and comparing:
>
> static inline void quick_spin_lock(struct qspinlock *lock)
> {
> while (atomic_cmpxchg(&lock->val, 0, _Q_LOCKED_VAL) != 0)
> cpu_relax();
> }
>
>
> Then, use quick_spin_lock instead of spin_lock everywhere in
> ptr_ring - will that make it more efficient?
>
I think this could be the case. I'll give it a test later this week I
am working on the xdp bits for virtio at the moment. To be honest though
for my qdisc patchset first I need to resolve a bug and then probably in
the first set just use the existing skb_array implementation. Its fun
to micro-optimize this stuff but really any implementation will show
improvement over existing code.
Thanks,
John
^ permalink raw reply
* Re: [RFC PATCH 1/2] net: use cmpxchg instead of spinlock in ptr rings
From: John Fastabend @ 2016-11-16 4:37 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev@vger.kernel.org; +Cc: Michael S. Tsirkin
In-Reply-To: <20161115143258.2c46fc9a@redhat.com>
On 16-11-15 05:32 AM, Jesper Dangaard Brouer wrote:
>
> (looks like my message didn't reach the netdev list, due to me sending
> from the wrong email, forwarded message again):
>
> On Thu, 10 Nov 2016 20:44:08 -0800 John Fastabend <john.fastabend@gmail.com> wrote:
>
>> ---
>> include/linux/ptr_ring_ll.h | 136 +++++++++++++++++++++++++++++++++++++++++++
>> include/linux/skb_array.h | 25 ++++++++
>> 2 files changed, 161 insertions(+)
>> create mode 100644 include/linux/ptr_ring_ll.h
>>
>> diff --git a/include/linux/ptr_ring_ll.h b/include/linux/ptr_ring_ll.h
>> new file mode 100644
>> index 0000000..bcb11f3
>> --- /dev/null
>> +++ b/include/linux/ptr_ring_ll.h
>> @@ -0,0 +1,136 @@
>> +/*
>> + * Definitions for the 'struct ptr_ring_ll' datastructure.
>> + *
>> + * Author:
>> + * John Fastabend <john.r.fastabend@intel.com>
> [...]
>> + *
>> + * This is a limited-size FIFO maintaining pointers in FIFO order, with
>> + * one CPU producing entries and another consuming entries from a FIFO.
>> + * extended from ptr_ring_ll to use cmpxchg over spin lock.
>
> It sounds like this is Single Producer Single Consumer (SPSC)
> implementation, but your implementation actually is Multi Producer
> Multi Consumer (MPMC) capable.
Correct qdisc requires a MPMC to handle all the OOO cases.
>
> The implementation looks a lot like my alf_queue[1] implementation:
> [1] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/include/linux/alf_queue.h
>
Sure, I was using that implementation originally.
> If the primary use-case is one CPU producing and another consuming,
> then the normal ptr_ring (skb_array) will actually be faster!
>
> The reason is ptr_ring avoids bouncing a cache-line between the CPUs on
> every ring access. This is achieved by having the checks for full
> (__ptr_ring_full) and empty (__ptr_ring_empty) use the contents of the
> array (NULL value).
>
> I actually implemented two micro-benchmarks to measure the difference
> between skb_array[2] and alf_queue[3]:
> [2] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/lib/skb_array_parallel01.c
> [3] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/lib/alf_queue_parallel01.c
>
But :) this doesn't jive with my experiments where this implementation
was actually giving better numbers with pktgen over pfifo_fast even in
the SPSC case. I'll rerun metrics later this week its possible there was
some other issue causing the difference I guess.
As I noted in Michael's email though really I need to fix a bug in my
qdisc code and submit it before I worry too much about this
optimization.
>
>> + */
>> +
>> +#ifndef _LINUX_PTR_RING_LL_H
>> +#define _LINUX_PTR_RING_LL_H 1
>> +
> [...]
>> +
>> +struct ptr_ring_ll {
>> + u32 prod_size;
>> + u32 prod_mask;
>> + u32 prod_head;
>> + u32 prod_tail;
>> + u32 cons_size;
>> + u32 cons_mask;
>> + u32 cons_head;
>> + u32 cons_tail;
>> +
>> + void **queue;
>> +};
>
> Your implementation doesn't even split the consumer and producer into
> different cachelines (which in practice doesn't help much due to how
> the empty/full checks are performed).
Its was just a implementation to get the qdisc patches off the ground. I
expected to follow up with patches to optimize the implementation.
[...]
>> +static inline int ptr_ring_ll_init(struct ptr_ring_ll *r, int size, gfp_t gfp)
>> +{
>> + r->queue = __ptr_ring_init_queue_alloc(size, gfp);
>> + if (!r->queue)
>> + return -ENOMEM;
>> +
>> + r->prod_size = r->cons_size = size;
>> + r->prod_mask = r->cons_mask = size - 1;
>
> Shouldn't we have some check like is_power_of_2(size), as this code
> looks like it depend on this.
>
Sure it is required. I was just ensuring callers do it correctly.
>> + r->prod_tail = r->prod_head = 0;
>> + r->cons_tail = r->prod_tail = 0;
>> +
>> + return 0;
>> +}
>> +
[...]
>>
>> +static inline struct sk_buff *skb_array_ll_consume(struct skb_array_ll *a)
>> +{
>> + return __ptr_ring_ll_consume(&a->ring);
>> +}
>> +
>
> Note in the Multi Producer Multi Consumer (MPMC) use-case this type of
> queue can be faster than normal ptr_ring. And in patch2 you implement
> bulking, which is where the real benefit shows (in the MPMC case) for
> this kind of queue.
>
> What I would really like to see is a lock-free (locked cmpxchg) queue
> implementation, what like ptr_ring use the array as empty/full check,
> and still (somehow) support bulking.
>
OK perhaps worth experimenting with after if I can _finally_ get the
qdisc series in.
.John
^ permalink raw reply
* Re: [RFC PATCH 2/2] ptr_ring_ll: pop/push multiple objects at once
From: John Fastabend @ 2016-11-16 4:42 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: jasowang, netdev, linux-kernel
In-Reply-To: <20161115010140-mutt-send-email-mst@kernel.org>
On 16-11-14 03:06 PM, Michael S. Tsirkin wrote:
> On Thu, Nov 10, 2016 at 08:44:32PM -0800, John Fastabend wrote:
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>
> This will naturally reduce the cache line bounce
> costs, but so will a _many API for ptr-ring,
> doing lock-add many-unlock.
>
> the number of atomics also scales better with the lock:
> one per push instead of one per queue.
>
> Also, when can qdisc use a _many operation?
>
On dequeue we can pull off many skbs instead of one at a time and
then either (a) pass them down as an array to the driver (I started
to write this on top of ixgbe and it seems like a win) or (b) pass
them one by one down to the driver and set the xmit_more bit correctly.
The pass one by one also seems like a win because we avoid the lock
per skb.
On enqueue qdisc side its a bit more evasive to start doing this.
[...]
>> +++ b/net/sched/sch_generic.c
>> @@ -571,7 +571,7 @@ static int pfifo_fast_enqueue(struct sk_buff *skb, struct Qdisc *qdisc,
>> struct skb_array_ll *q = band2list(priv, band);
>> int err;
>>
>> - err = skb_array_ll_produce(q, skb);
>> + err = skb_array_ll_produce(q, &skb);
>>
>> if (unlikely(err)) {
>> net_warn_ratelimited("drop a packet from fast enqueue\n");
>
> I don't see a pop many operation here.
>
Patches need a bit of cleanup looks like it was part of another patch.
.John
^ permalink raw reply
* Re: [RFC PATCH 2/2] ptr_ring_ll: pop/push multiple objects at once
From: Michael S. Tsirkin @ 2016-11-16 5:23 UTC (permalink / raw)
To: John Fastabend; +Cc: jasowang, netdev, linux-kernel
In-Reply-To: <582BE39B.9050007@gmail.com>
On Tue, Nov 15, 2016 at 08:42:03PM -0800, John Fastabend wrote:
> On 16-11-14 03:06 PM, Michael S. Tsirkin wrote:
> > On Thu, Nov 10, 2016 at 08:44:32PM -0800, John Fastabend wrote:
> >> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> >
> > This will naturally reduce the cache line bounce
> > costs, but so will a _many API for ptr-ring,
> > doing lock-add many-unlock.
> >
> > the number of atomics also scales better with the lock:
> > one per push instead of one per queue.
> >
> > Also, when can qdisc use a _many operation?
> >
>
> On dequeue we can pull off many skbs instead of one at a time and
> then either (a) pass them down as an array to the driver (I started
> to write this on top of ixgbe and it seems like a win) or (b) pass
> them one by one down to the driver and set the xmit_more bit correctly.
>
> The pass one by one also seems like a win because we avoid the lock
> per skb.
>
> On enqueue qdisc side its a bit more evasive to start doing this.
>
>
> [...]
I see. So we could wrap __ptr_ring_consume and
implement __skb_array_consume. You can call that
in a loop under a lock. I would limit it to something
small like 16 pointers, to make sure lock contention is
not an issue.
--
MST
^ permalink raw reply
* Re: [PATCH] igmp: Make igmp group member RFC 3376 compliant
From: Hangbin Liu @ 2016-11-16 6:20 UTC (permalink / raw)
To: Michal Tesar; +Cc: David Miller, kuznet, jmorris, kaber, netdev
In-Reply-To: <20161108092625.GA14456@sparky-lenivo.brq.redhat.com>
Hi David,
On Tue, Nov 08, 2016 at 10:26:25AM +0100, Michal Tesar wrote:
> On Mon, Nov 07, 2016 at 08:13:45PM -0500, David Miller wrote:
>
> > From: Michal Tesar <mtesar@redhat.com>
> > Date: Thu, 3 Nov 2016 10:38:34 +0100
> >
> > > 2. If the received Query is a General Query, the interface timer is
> > > used to schedule a response to the General Query after the
> > > selected delay. Any previously pending response to a General
> > > Query is canceled.
> > > --8<--
> > >
> > > Currently the timer is rearmed with new random expiration time for
> > > every incoming query regardless of possibly already pending report.
> > > Which is not aligned with the above RFE.
> >
> > I don't read it that way. #2 says if this is a general query then any
> > pending response to a general query is cancelled. And that's
> > effectively what the code is doing right now.
>
> Hi David,
> I think that it is important to notice that the RFC says also
> that only the first matching rule is applied.
>
> "
> When new Query with the Router-Alert option arrives on an
> interface, provided the system has state to report, a delay for a
> response is randomly selected in the range (0, [Max Resp Time]) where
> Max Resp Time is derived from Max Resp Code in the received Query
> message. The following rules are then used to determine if a Report
> needs to be scheduled and the type of Report to schedule. The rules
> are considered in order and only the first matching rule is applied.
^^
Would you like to reconsider about this? I also agree with Michal that we
need to choose the sooner timer. Or if we receive query very quickly, we
will keep refresh the timer and may never reply the report.
Thanks
Hangbin
>
> 1. If there is a pending response to a previous General Query
> scheduled sooner than the selected delay, no additional response
> needs to be scheduled.
>
> 2. If the received Query is a General Query, the interface timer is
> used to schedule a response to the General Query after the
> selected delay. Any previously pending response to a General
> Query is canceled.
> "
>
> So I would read the above like below:
> If some general query arrives and there is some
> already pending response scheduled sooner,
> no action is needed.
> That is how I understand to the rule [1].
>
> But when an general query arrives and there is some other
> response already pending, but not sooner as rule one says but later,
> new report should be scheduled and the already pending one
> needs to be canceled.
> That is how I understand to the rule [2]
>
> If there is no already pending report scheduled
> the first part of the rule [2] is applied
> and new report is scheduled along the selected delay.
>
> So basically we need to compare the already scheduled response exp time
> with the one coming in and choose the sooner one.
> This is exactly what the patch does.
>
> What do you think?
> Best regards Michal Tesar
^ permalink raw reply
* [PATCH net] virtio-net: add a missing synchronize_net()
From: Eric Dumazet @ 2016-11-16 6:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Jason Wang, Michael S. Tsirkin
From: Eric Dumazet <edumazet@google.com>
It seems many drivers do not respect napi_hash_del() contract.
When napi_hash_del() is used before netif_napi_del(), an RCU grace
period is needed before freeing NAPI object.
Fixes: 91815639d880 ("virtio-net: rx busy polling support")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
---
drivers/net/virtio_net.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index fd8b1e62301f..7276d5a95bd0 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1497,6 +1497,11 @@ static void virtnet_free_queues(struct virtnet_info *vi)
netif_napi_del(&vi->rq[i].napi);
}
+ /* We called napi_hash_del() before netif_napi_del(),
+ * we need to respect an RCU grace period before freeing vi->rq
+ */
+ synchronize_net();
+
kfree(vi->rq);
kfree(vi->sq);
}
^ permalink raw reply related
* Re: [PATCH net-next 2/5] net: ethoc: Implement ethtool::nway_reset
From: Tobias Klauser @ 2016-11-16 7:38 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, davem, andrew, tremyfr, Colin Ian King, open list
In-Reply-To: <20161115191949.15361-3-f.fainelli@gmail.com>
On 2016-11-15 at 20:19:46 +0100, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Implement ethtool::nway_reset using phy_ethtool_nway_reset. We are
> already using dev->phydev all over the place so this comes for free.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Tobias Klauser <tklauser@distanz.ch>
^ permalink raw reply
* Re: [PATCH for-next 03/11] IB/hns: Optimize the logic of allocating memory using APIs
From: Leon Romanovsky @ 2016-11-16 8:36 UTC (permalink / raw)
To: Salil Mehta
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Huwei (Xavier),
oulijun, mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linuxarm,
Zhangping (ZP)
In-Reply-To: <F4CC6FACFEB3C54C9141D49AD221F7F91A7A2371@lhreml503-mbx>
[-- Attachment #1: Type: text/plain, Size: 3338 bytes --]
On Tue, Nov 15, 2016 at 03:52:46PM +0000, Salil Mehta wrote:
> > -----Original Message-----
> > From: Leon Romanovsky [mailto:leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
> > Sent: Wednesday, November 09, 2016 7:22 AM
> > To: Salil Mehta
> > Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org; Huwei (Xavier); oulijun;
> > mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm;
> > Zhangping (ZP)
> > Subject: Re: [PATCH for-next 03/11] IB/hns: Optimize the logic of
> > allocating memory using APIs
> >
> > On Fri, Nov 04, 2016 at 04:36:25PM +0000, Salil Mehta wrote:
> > > From: "Wei Hu (Xavier)" <xavier.huwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > >
> > > This patch modified the logic of allocating memory using APIs in
> > > hns RoCE driver. We used kcalloc instead of kmalloc_array and
> > > bitmap_zero. And When kcalloc failed, call vzalloc to alloc
> > > memory.
> > >
> > > Signed-off-by: Wei Hu (Xavier) <xavier.huwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > > Signed-off-by: Ping Zhang <zhangping5-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > > Signed-off-by: Salil Mehta <salil.mehta-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > > ---
> > > drivers/infiniband/hw/hns/hns_roce_mr.c | 15 ++++++++-------
> > > 1 file changed, 8 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/infiniband/hw/hns/hns_roce_mr.c
> > b/drivers/infiniband/hw/hns/hns_roce_mr.c
> > > index fb87883..d3dfb5f 100644
> > > --- a/drivers/infiniband/hw/hns/hns_roce_mr.c
> > > +++ b/drivers/infiniband/hw/hns/hns_roce_mr.c
> > > @@ -137,11 +137,12 @@ static int hns_roce_buddy_init(struct
> > hns_roce_buddy *buddy, int max_order)
> > >
> > > for (i = 0; i <= buddy->max_order; ++i) {
> > > s = BITS_TO_LONGS(1 << (buddy->max_order - i));
> > > - buddy->bits[i] = kmalloc_array(s, sizeof(long),
> > GFP_KERNEL);
> > > - if (!buddy->bits[i])
> > > - goto err_out_free;
> > > -
> > > - bitmap_zero(buddy->bits[i], 1 << (buddy->max_order - i));
> > > + buddy->bits[i] = kcalloc(s, sizeof(long), GFP_KERNEL);
> > > + if (!buddy->bits[i]) {
> > > + buddy->bits[i] = vzalloc(s * sizeof(long));
> >
> > I wonder, why don't you use directly vzalloc instead of kcalloc
> > fallback?
> As we know we will have physical contiguous pages if the kcalloc
> call succeeds. This will give us a chance to have better performance
> over the allocations which are just virtually contiguous through the
> function vzalloc(). Therefore, later has only been used as a fallback
> when our memory request cannot be entertained through kcalloc.
>
> Are you suggesting that there will not be much performance penalty
> if we use just vzalloc ?
Not exactly,
I asked it, because we have similar code in our drivers and this
construction looks strange to me.
1. If performance is critical, we will use kmalloc.
2. If performance is not critical, we will use vmalloc.
But in this case, such construction shows me that we can live with
vmalloc performance and kmalloc allocation are not really needed.
In your specific case, I'm not sure that kcalloc will ever fail.
Thanks
>
> >
> > > + if (!buddy->bits[i])
> > > + goto err_out_free;
> > > + }
> > > }
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH net] net: nsid cannot be allocated for a dead netns
From: Nicolas Dichtel @ 2016-11-16 8:41 UTC (permalink / raw)
To: avagin; +Cc: davem, netdev, xiyou.wangcong, Nicolas Dichtel
In-Reply-To: <CANaxB-yaizaZbUi-OaJLzy+k2fNOkTCb8L8uwBCw4L5axOCzdg@mail.gmail.com>
Andrei reports the following kmemleak error:
unreferenced object 0xffff91badb543950 (size 2096):
comm "kworker/u4:0", pid 6, jiffies 4295152553 (age 28.418s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 cb 5f df ba 91 ff ff .........._.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffffb1865bea>] kmemleak_alloc+0x4a/0xa0
[<ffffffffb1243b38>] kmem_cache_alloc+0x128/0x280
[<ffffffffb142f5ab>] idr_layer_alloc+0x2b/0x90
[<ffffffffb142f9cd>] idr_get_empty_slot+0x34d/0x370
[<ffffffffb142fa4e>] idr_alloc+0x5e/0x110
[<ffffffffb170ac3d>] __peernet2id_alloc+0x6d/0x90
[<ffffffffb170bda5>] peernet2id_alloc+0x55/0xb0
[<ffffffffb1731216>] rtnl_fill_ifinfo+0xaa6/0x10a0
[<ffffffffb1733073>] rtmsg_ifinfo_build_skb+0x73/0xd0
[<ffffffffb17125d5>] rollback_registered_many+0x295/0x390
[<ffffffffb1712765>] unregister_netdevice_many+0x25/0x80
[<ffffffffb17138a5>] default_device_exit_batch+0x145/0x170
[<ffffffffb170ae52>] ops_exit_list.isra.4+0x52/0x60
[<ffffffffb170c17f>] cleanup_net+0x1bf/0x2a0
[<ffffffffb10b616f>] process_one_work+0x1ff/0x660
[<ffffffffb10b661e>] worker_thread+0x4e/0x480
There is no reason to try to allocate an nsid for a netns which is dying.
Reported-by: Andrei Vagin <avagin@gmail.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
Thank you for the report. Can you test this patch?
Regards,
Nicolas
net/core/net_namespace.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index f61c0e02a413..f1340ed0d8df 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -159,6 +159,9 @@ static int alloc_netid(struct net *net, struct net *peer, int reqid)
max = reqid + 1;
}
+ if (!atomic_read(&net->count) || !&atomic_read(peer->count))
+ return -EINVAL;
+
return idr_alloc(&net->netns_ids, peer, min, max, GFP_ATOMIC);
}
--
2.8.1
^ permalink raw reply related
* Re: [PATCH net] net: nsid cannot be allocated for a dead netns
From: Nicolas Dichtel @ 2016-11-16 8:42 UTC (permalink / raw)
To: avagin; +Cc: davem, netdev, xiyou.wangcong
In-Reply-To: <1479285671-1298-1-git-send-email-nicolas.dichtel@6wind.com>
Le 16/11/2016 à 09:41, Nicolas Dichtel a écrit :
> Andrei reports the following kmemleak error:
> unreferenced object 0xffff91badb543950 (size 2096):
> comm "kworker/u4:0", pid 6, jiffies 4295152553 (age 28.418s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 cb 5f df ba 91 ff ff .........._.....
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<ffffffffb1865bea>] kmemleak_alloc+0x4a/0xa0
> [<ffffffffb1243b38>] kmem_cache_alloc+0x128/0x280
> [<ffffffffb142f5ab>] idr_layer_alloc+0x2b/0x90
> [<ffffffffb142f9cd>] idr_get_empty_slot+0x34d/0x370
> [<ffffffffb142fa4e>] idr_alloc+0x5e/0x110
> [<ffffffffb170ac3d>] __peernet2id_alloc+0x6d/0x90
> [<ffffffffb170bda5>] peernet2id_alloc+0x55/0xb0
> [<ffffffffb1731216>] rtnl_fill_ifinfo+0xaa6/0x10a0
> [<ffffffffb1733073>] rtmsg_ifinfo_build_skb+0x73/0xd0
> [<ffffffffb17125d5>] rollback_registered_many+0x295/0x390
> [<ffffffffb1712765>] unregister_netdevice_many+0x25/0x80
> [<ffffffffb17138a5>] default_device_exit_batch+0x145/0x170
> [<ffffffffb170ae52>] ops_exit_list.isra.4+0x52/0x60
> [<ffffffffb170c17f>] cleanup_net+0x1bf/0x2a0
> [<ffffffffb10b616f>] process_one_work+0x1ff/0x660
> [<ffffffffb10b661e>] worker_thread+0x4e/0x480
>
> There is no reason to try to allocate an nsid for a netns which is dying.
>
> Reported-by: Andrei Vagin <avagin@gmail.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
'Fixes' tag is missing :/
Fixes: 0c7aecd4bde4 ("netns: add rtnl cmd to add and get peer netns ids")
^ permalink raw reply
* [PATCH] net: ethernet: faraday: To support device tree usage.
From: Greentime Hu @ 2016-11-16 8:43 UTC (permalink / raw)
To: netdev, linux-kernel; +Cc: Greentime Hu
To support device tree usage for ftmac100.
Signed-off-by: Greentime Hu <green.hu@gmail.com>
---
drivers/net/ethernet/faraday/ftmac100.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/faraday/ftmac100.c b/drivers/net/ethernet/faraday/ftmac100.c
index dce5f7b..81dd9e1 100644
--- a/drivers/net/ethernet/faraday/ftmac100.c
+++ b/drivers/net/ethernet/faraday/ftmac100.c
@@ -1172,11 +1172,17 @@ static int __exit ftmac100_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id mac_of_ids[] = {
+ { .compatible = "andestech,atmac100" },
+ { }
+};
+
static struct platform_driver ftmac100_driver = {
.probe = ftmac100_probe,
.remove = __exit_p(ftmac100_remove),
.driver = {
.name = DRV_NAME,
+ .of_match_table = mac_of_ids
},
};
@@ -1200,3 +1206,4 @@ static void __exit ftmac100_exit(void)
MODULE_AUTHOR("Po-Yu Chuang <ratbert@faraday-tech.com>");
MODULE_DESCRIPTION("FTMAC100 driver");
MODULE_LICENSE("GPL");
+MODULE_DEVICE_TABLE(of, mac_of_ids);
--
1.7.9.5
^ permalink raw reply related
* 58410 netdev
From: marketing @ 2016-11-16 8:51 UTC (permalink / raw)
To: netdev
[-- Attachment #1: EMAIL_7613265_netdev.zip --]
[-- Type: application/zip, Size: 11263 bytes --]
^ permalink raw reply
* [patch net-next] mlxsw: spectrum_router: Adjust placement of FIB abort warning
From: Jiri Pirko @ 2016-11-16 8:51 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, eladr, yotamg, nogahf, arkadis, ogerlitz
From: Ido Schimmel <idosch@mellanox.com>
The recent merge commit bb598c1b8c9b ("Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net") would cause
the FIB abort warning to fire whenever we flush the FIB tables - either
during module removal or actual abort.
Move it back to its rightful location in the FIB abort function.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 164bd30..683f045 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -1872,9 +1872,6 @@ static void mlxsw_sp_router_fib_flush(struct mlxsw_sp *mlxsw_sp)
struct mlxsw_sp_vr *vr;
int i;
- if (mlxsw_sp->router.aborted)
- return;
- dev_warn(mlxsw_sp->bus_info->dev, "FIB abort triggered. Note that FIB entries are no longer being offloaded to this device.\n");
for (i = 0; i < MLXSW_CORE_RES_GET(mlxsw_sp->core, MAX_VRS); i++) {
vr = &mlxsw_sp->router.vrs[i];
@@ -1899,6 +1896,9 @@ static void mlxsw_sp_router_fib4_abort(struct mlxsw_sp *mlxsw_sp)
{
int err;
+ if (mlxsw_sp->router.aborted)
+ return;
+ dev_warn(mlxsw_sp->bus_info->dev, "FIB abort triggered. Note that FIB entries are no longer being offloaded to this device.\n");
mlxsw_sp_router_fib_flush(mlxsw_sp);
mlxsw_sp->router.aborted = true;
err = mlxsw_sp_router_set_abort_trap(mlxsw_sp);
--
2.7.4
^ permalink raw reply related
* [PATCH v2] net/phy/vitesse: Configure RGMII skew on VSC8601, if needed
From: Alexandru Gagniuc @ 2016-11-16 9:02 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, linux-kernel, davem, Alexandru Gagniuc
In-Reply-To: <20161115.221217.2076182289174952941.davem@davemloft.net>
With RGMII, we need a 1.5 to 2ns skew between clock and data lines. The
VSC8601 can handle this internally. While the VSC8601 can set more
fine-grained delays, the standard skew settings work out of the box.
The same heuristic is used to determine when this skew should be enabled
as in vsc824x_config_init().
Tested on custom board with AM3352 SOC and VSC801 PHY.
Signed-off-by: Alexandru Gagniuc <alex.g@adaptrum.com>
---
Changes since v1:
* Added comment detailing applicability to different RGMII interfaces.
drivers/net/phy/vitesse.c | 34 +++++++++++++++++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
index 2e37eb3..24b4a09 100644
--- a/drivers/net/phy/vitesse.c
+++ b/drivers/net/phy/vitesse.c
@@ -62,6 +62,10 @@
/* Vitesse Extended Page Access Register */
#define MII_VSC82X4_EXT_PAGE_ACCESS 0x1f
+/* Vitesse VSC8601 Extended PHY Control Register 1 */
+#define MII_VSC8601_EPHY_CTL 0x17
+#define MII_VSC8601_EPHY_CTL_RGMII_SKEW (1 << 8)
+
#define PHY_ID_VSC8234 0x000fc620
#define PHY_ID_VSC8244 0x000fc6c0
#define PHY_ID_VSC8514 0x00070670
@@ -111,6 +115,34 @@ static int vsc824x_config_init(struct phy_device *phydev)
return err;
}
+/* This adds a skew for both TX and RX clocks, so the skew should only be
+ * applied to "rgmii-id" interfaces. It may not work as expected
+ * on "rgmii-txid", "rgmii-rxid" or "rgmii" interfaces. */
+static int vsc8601_add_skew(struct phy_device *phydev)
+{
+ int ret;
+
+ ret = phy_read(phydev, MII_VSC8601_EPHY_CTL);
+ if (ret < 0)
+ return ret;
+
+ ret |= MII_VSC8601_EPHY_CTL_RGMII_SKEW;
+ return phy_write(phydev, MII_VSC8601_EPHY_CTL, ret);
+}
+
+static int vsc8601_config_init(struct phy_device *phydev)
+{
+ int ret = 0;
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
+ ret = vsc8601_add_skew(phydev);
+
+ if (ret < 0)
+ return ret;
+
+ return genphy_config_init(phydev);
+}
+
static int vsc824x_ack_interrupt(struct phy_device *phydev)
{
int err = 0;
@@ -275,7 +307,7 @@ static struct phy_driver vsc82xx_driver[] = {
.phy_id_mask = 0x000ffff0,
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
- .config_init = &genphy_config_init,
+ .config_init = &vsc8601_config_init,
.config_aneg = &genphy_config_aneg,
.read_status = &genphy_read_status,
.ack_interrupt = &vsc824x_ack_interrupt,
--
2.7.4
^ permalink raw reply related
* [PATCH net-next] lwtunnel: subtract tunnel headroom from mtu on output redirect
From: David Lebrun @ 2016-11-16 9:05 UTC (permalink / raw)
To: netdev; +Cc: roopa, David Lebrun
This patch changes the lwtunnel_headroom() function which is called
in ipv4_mtu() and ip6_mtu(), to also return the correct headroom
value when the lwtunnel state is OUTPUT_REDIRECT.
This patch enables e.g. SR-IPv6 encapsulations to work without
manually setting the route mtu.
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
---
include/net/lwtunnel.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/net/lwtunnel.h b/include/net/lwtunnel.h
index 82e76fe..d4c1c75 100644
--- a/include/net/lwtunnel.h
+++ b/include/net/lwtunnel.h
@@ -94,7 +94,8 @@ static inline bool lwtunnel_xmit_redirect(struct lwtunnel_state *lwtstate)
static inline unsigned int lwtunnel_headroom(struct lwtunnel_state *lwtstate,
unsigned int mtu)
{
- if (lwtunnel_xmit_redirect(lwtstate) && lwtstate->headroom < mtu)
+ if ((lwtunnel_xmit_redirect(lwtstate) ||
+ lwtunnel_output_redirect(lwtstate)) && lwtstate->headroom < mtu)
return lwtstate->headroom;
return 0;
--
2.7.3
^ permalink raw reply related
* Re: [PATCH net] net: nsid cannot be allocated for a dead netns
From: kbuild test robot @ 2016-11-16 9:10 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: kbuild-all, avagin, davem, netdev, xiyou.wangcong,
Nicolas Dichtel
In-Reply-To: <1479285671-1298-1-git-send-email-nicolas.dichtel@6wind.com>
[-- Attachment #1: Type: text/plain, Size: 11624 bytes --]
Hi Nicolas,
[auto build test ERROR on net/master]
url: https://github.com/0day-ci/linux/commits/Nicolas-Dichtel/net-nsid-cannot-be-allocated-for-a-dead-netns/20161116-164739
config: i386-randconfig-x006-201646 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/timer.h:4,
from include/linux/workqueue.h:8,
from net/core/net_namespace.c:3:
net/core/net_namespace.c: In function 'alloc_netid':
>> net/core/net_namespace.c:162:49: error: incompatible type for argument 1 of 'atomic_read'
if (!atomic_read(&net->count) || !&atomic_read(peer->count))
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> net/core/net_namespace.c:162:2: note: in expansion of macro 'if'
if (!atomic_read(&net->count) || !&atomic_read(peer->count))
^~
In file included from arch/x86/include/asm/msr.h:66:0,
from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:58,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/ktime.h:24,
from include/linux/timer.h:5,
from include/linux/workqueue.h:8,
from net/core/net_namespace.c:3:
arch/x86/include/asm/atomic.h:24:28: note: expected 'const atomic_t * {aka const struct <anonymous> *}' but argument is of type 'atomic_t {aka struct <anonymous>}'
static __always_inline int atomic_read(const atomic_t *v)
^~~~~~~~~~~
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/timer.h:4,
from include/linux/workqueue.h:8,
from net/core/net_namespace.c:3:
>> net/core/net_namespace.c:162:49: error: incompatible type for argument 1 of 'atomic_read'
if (!atomic_read(&net->count) || !&atomic_read(peer->count))
^
include/linux/compiler.h:149:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> net/core/net_namespace.c:162:2: note: in expansion of macro 'if'
if (!atomic_read(&net->count) || !&atomic_read(peer->count))
^~
In file included from arch/x86/include/asm/msr.h:66:0,
from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:58,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/ktime.h:24,
from include/linux/timer.h:5,
from include/linux/workqueue.h:8,
from net/core/net_namespace.c:3:
arch/x86/include/asm/atomic.h:24:28: note: expected 'const atomic_t * {aka const struct <anonymous> *}' but argument is of type 'atomic_t {aka struct <anonymous>}'
static __always_inline int atomic_read(const atomic_t *v)
^~~~~~~~~~~
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/timer.h:4,
from include/linux/workqueue.h:8,
from net/core/net_namespace.c:3:
>> net/core/net_namespace.c:162:49: error: incompatible type for argument 1 of 'atomic_read'
if (!atomic_read(&net->count) || !&atomic_read(peer->count))
^
include/linux/compiler.h:160:16: note: in definition of macro '__trace_if'
______r = !!(cond); \
^~~~
>> net/core/net_namespace.c:162:2: note: in expansion of macro 'if'
if (!atomic_read(&net->count) || !&atomic_read(peer->count))
^~
In file included from arch/x86/include/asm/msr.h:66:0,
from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:58,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/ktime.h:24,
from include/linux/timer.h:5,
from include/linux/workqueue.h:8,
from net/core/net_namespace.c:3:
arch/x86/include/asm/atomic.h:24:28: note: expected 'const atomic_t * {aka const struct <anonymous> *}' but argument is of type 'atomic_t {aka struct <anonymous>}'
static __always_inline int atomic_read(const atomic_t *v)
^~~~~~~~~~~
vim +/atomic_read +162 net/core/net_namespace.c
1 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
2
> 3 #include <linux/workqueue.h>
4 #include <linux/rtnetlink.h>
5 #include <linux/cache.h>
6 #include <linux/slab.h>
7 #include <linux/list.h>
8 #include <linux/delay.h>
9 #include <linux/sched.h>
10 #include <linux/idr.h>
11 #include <linux/rculist.h>
12 #include <linux/nsproxy.h>
13 #include <linux/fs.h>
14 #include <linux/proc_ns.h>
15 #include <linux/file.h>
16 #include <linux/export.h>
17 #include <linux/user_namespace.h>
18 #include <linux/net_namespace.h>
19 #include <net/sock.h>
20 #include <net/netlink.h>
21 #include <net/net_namespace.h>
22 #include <net/netns/generic.h>
23
24 /*
25 * Our network namespace constructor/destructor lists
26 */
27
28 static LIST_HEAD(pernet_list);
29 static struct list_head *first_device = &pernet_list;
30 DEFINE_MUTEX(net_mutex);
31
32 LIST_HEAD(net_namespace_list);
33 EXPORT_SYMBOL_GPL(net_namespace_list);
34
35 struct net init_net = {
36 .dev_base_head = LIST_HEAD_INIT(init_net.dev_base_head),
37 };
38 EXPORT_SYMBOL(init_net);
39
40 static bool init_net_initialized;
41
42 #define INITIAL_NET_GEN_PTRS 13 /* +1 for len +2 for rcu_head */
43
44 static unsigned int max_gen_ptrs = INITIAL_NET_GEN_PTRS;
45
46 static struct net_generic *net_alloc_generic(void)
47 {
48 struct net_generic *ng;
49 size_t generic_size = offsetof(struct net_generic, ptr[max_gen_ptrs]);
50
51 ng = kzalloc(generic_size, GFP_KERNEL);
52 if (ng)
53 ng->len = max_gen_ptrs;
54
55 return ng;
56 }
57
58 static int net_assign_generic(struct net *net, int id, void *data)
59 {
60 struct net_generic *ng, *old_ng;
61
62 BUG_ON(!mutex_is_locked(&net_mutex));
63 BUG_ON(id == 0);
64
65 old_ng = rcu_dereference_protected(net->gen,
66 lockdep_is_held(&net_mutex));
67 ng = old_ng;
68 if (old_ng->len >= id)
69 goto assign;
70
71 ng = net_alloc_generic();
72 if (ng == NULL)
73 return -ENOMEM;
74
75 /*
76 * Some synchronisation notes:
77 *
78 * The net_generic explores the net->gen array inside rcu
79 * read section. Besides once set the net->gen->ptr[x]
80 * pointer never changes (see rules in netns/generic.h).
81 *
82 * That said, we simply duplicate this array and schedule
83 * the old copy for kfree after a grace period.
84 */
85
86 memcpy(&ng->ptr, &old_ng->ptr, old_ng->len * sizeof(void*));
87
88 rcu_assign_pointer(net->gen, ng);
89 kfree_rcu(old_ng, rcu);
90 assign:
91 ng->ptr[id - 1] = data;
92 return 0;
93 }
94
95 static int ops_init(const struct pernet_operations *ops, struct net *net)
96 {
97 int err = -ENOMEM;
98 void *data = NULL;
99
100 if (ops->id && ops->size) {
101 data = kzalloc(ops->size, GFP_KERNEL);
102 if (!data)
103 goto out;
104
105 err = net_assign_generic(net, *ops->id, data);
106 if (err)
107 goto cleanup;
108 }
109 err = 0;
110 if (ops->init)
111 err = ops->init(net);
112 if (!err)
113 return 0;
114
115 cleanup:
116 kfree(data);
117
118 out:
119 return err;
120 }
121
122 static void ops_free(const struct pernet_operations *ops, struct net *net)
123 {
124 if (ops->id && ops->size) {
125 int id = *ops->id;
126 kfree(net_generic(net, id));
127 }
128 }
129
130 static void ops_exit_list(const struct pernet_operations *ops,
131 struct list_head *net_exit_list)
132 {
133 struct net *net;
134 if (ops->exit) {
135 list_for_each_entry(net, net_exit_list, exit_list)
136 ops->exit(net);
137 }
138 if (ops->exit_batch)
139 ops->exit_batch(net_exit_list);
140 }
141
142 static void ops_free_list(const struct pernet_operations *ops,
143 struct list_head *net_exit_list)
144 {
145 struct net *net;
146 if (ops->size && ops->id) {
147 list_for_each_entry(net, net_exit_list, exit_list)
148 ops_free(ops, net);
149 }
150 }
151
152 /* should be called with nsid_lock held */
153 static int alloc_netid(struct net *net, struct net *peer, int reqid)
154 {
155 int min = 0, max = 0;
156
157 if (reqid >= 0) {
158 min = reqid;
159 max = reqid + 1;
160 }
161
> 162 if (!atomic_read(&net->count) || !&atomic_read(peer->count))
163 return -EINVAL;
164
165 return idr_alloc(&net->netns_ids, peer, min, max, GFP_ATOMIC);
---
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: 27870 bytes --]
^ permalink raw reply
* Re: [PATCH net] net: nsid cannot be allocated for a dead netns
From: Nicolas Dichtel @ 2016-11-16 9:45 UTC (permalink / raw)
To: kbuild test robot; +Cc: kbuild-all, avagin, davem, netdev, xiyou.wangcong
In-Reply-To: <201611161759.tCk5fdCO%fengguang.wu@intel.com>
Le 16/11/2016 à 10:10, kbuild test robot a écrit :
> Hi Nicolas,
>
> [auto build test ERROR on net/master]
And I finally send the wrong version of the patch :(
^ 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