* Re: [PATCH v2 net-net 0/4] Increase the limit of tuntap queues
From: David Miller @ 2014-11-24 20:15 UTC (permalink / raw)
To: pagupta
Cc: linux-kernel, netdev, jasowang, dgibson, vfalico, edumazet,
vyasevic, hkchu, xemul, therbert, bhutchings, xii, stephen, jiri,
sergei.shtylyov
In-Reply-To: <1416854006-10041-1-git-send-email-pagupta@redhat.com>
Your header message says "0/4" as if there will be 4 patches, but then
you posted a 3 patch series.
^ permalink raw reply
* Re: [fuse-devel] [PATCH 4/6] fs/fuse: support compiling out splice
From: josh-iaAMLnmF4UmaiuxdJuQwMA @ 2014-11-24 20:14 UTC (permalink / raw)
To: Greg KH
Cc: Pieter Smith, Richard Weinberger, Michael S. Tsirkin,
Bertrand Jacquin, Oleg Nesterov, J. Bruce Fields, Eric Dumazet,
蔡正龙, Jeff Layton, Tom Herbert,
Alexei Starovoitov, Miklos Szeredi, Peter Foley, Hugh Dickins,
Xiao Guangrong, Geert Uytterhoeven, Mel Gorman, Matt Turner,
Paul E. McKenney, Alexander Duyck, open list:FUSE: FILESYSTEM...
In-Reply-To: <20141124193412.GB31618-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Mon, Nov 24, 2014 at 11:34:12AM -0800, Greg KH wrote:
> On Mon, Nov 24, 2014 at 08:05:10AM -0800, Josh Triplett wrote:
> > On Mon, Nov 24, 2014 at 10:49:31AM +0100, Pieter Smith wrote:
> > > On Sun, Nov 23, 2014 at 03:23:02PM -0800, Josh Triplett wrote:
> > > > On Sun, Nov 23, 2014 at 11:29:08PM +0100, Richard Weinberger wrote:
> > > > > On Sun, Nov 23, 2014 at 3:20 PM, Pieter Smith <pieter-qeJ+1H9vRZbz+pZb47iToQ@public.gmane.org> wrote:
> > > > > > To implement splice support, fs/fuse makes use of nosteal_pipe_buf_ops. This
> > > > > > struct is exported by fs/splice. The goal of the larger patch set is to
> > > > > > completely compile out fs/splice, so uses of the exported struct need to be
> > > > > > compiled out along with fs/splice.
> > > > > >
> > > > > > This patch therefore compiles out splice support in fs/fuse when
> > > > > > CONFIG_SYSCALL_SPLICE is undefined.
> > > > > >
> > > > > > Signed-off-by: Pieter Smith <pieter-qeJ+1H9vRZbz+pZb47iToQ@public.gmane.org>
> > > > > > ---
> > > > > > fs/fuse/dev.c | 4 ++--
> > > > > > include/linux/fs.h | 6 ++++++
> > > > > > 2 files changed, 8 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> > > > > > index ca88731..f8f92a4 100644
> > > > > > --- a/fs/fuse/dev.c
> > > > > > +++ b/fs/fuse/dev.c
> > > > > > @@ -1291,7 +1291,7 @@ static ssize_t fuse_dev_read(struct kiocb *iocb, const struct iovec *iov,
> > > > > > return fuse_dev_do_read(fc, file, &cs, iov_length(iov, nr_segs));
> > > > > > }
> > > > > >
> > > > > > -static ssize_t fuse_dev_splice_read(struct file *in, loff_t *ppos,
> > > > > > +static ssize_t __maybe_unused fuse_dev_splice_read(struct file *in, loff_t *ppos,
> > > > > > struct pipe_inode_info *pipe,
> > > > > > size_t len, unsigned int flags)
> > > > > > {
> > > > > > @@ -2144,7 +2144,7 @@ const struct file_operations fuse_dev_operations = {
> > > > > > .llseek = no_llseek,
> > > > > > .read = do_sync_read,
> > > > > > .aio_read = fuse_dev_read,
> > > > > > - .splice_read = fuse_dev_splice_read,
> > > > > > + .splice_read = __splice_p(fuse_dev_splice_read),
> > > > > > .write = do_sync_write,
> > > > > > .aio_write = fuse_dev_write,
> > > > > > .splice_write = fuse_dev_splice_write,
> > > > > > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > > > > > index a957d43..04c0975 100644
> > > > > > --- a/include/linux/fs.h
> > > > > > +++ b/include/linux/fs.h
> > > > > > @@ -2443,6 +2443,12 @@ extern int blkdev_fsync(struct file *filp, loff_t start, loff_t end,
> > > > > > int datasync);
> > > > > > extern void block_sync_page(struct page *page);
> > > > > >
> > > > > > +#ifdef CONFIG_SYSCALL_SPLICE
> > > > > > +#define __splice_p(x) x
> > > > > > +#else
> > > > > > +#define __splice_p(x) NULL
> > > > > > +#endif
> > > > > > +
> > > > >
> > > > > This needs to go into a different patch.
> > > > > One logical change per patch please. :-)
> > > >
> > > > Easy enough to merge this one into the patch introducing
> > > > CONFIG_SYSCALL_SPLICE, then.
> > > >
> > > > - Josh Triplett
> > >
> > > The patch introducing CONFIG_SYSCALL_SPLICE (PATCH 3) only compiles out the
> > > syscalls. PATCH 6 on the other hand, compiles out fs/splice.c. This patch
> > > allows fs/fuse to be compiled when fs/splice.c is compiled out. If I am to
> > > squash it, it would be logical to include it in PATCH 6, not 3.
> >
> > The suggestion wasn't to move the fs/fuse/dev.c bits; those should
> > definitely stay in this patch. The suggestion was just to move the bit
> > of the patch defining __splice_p from this patch to patch 3. (Note that
> > you need to define it before you use it, so it can't go in patch 6.)
>
> I would, again, argue that stuff like __splice_p() not be implemented at
> all please. It will only cause a huge proliferation of stuff like this
> that will not make any sense, and only cause a trivial, if any, amount
> of code savings.
>
> I thought you were going to not do this type of thing until you got the
> gcc optimizer working for function callbacks.
Compared to the previous patchset, there are now only two instances of
ifdefs outside of the splice code for this, and this is one of them. In
this case, the issue is no longer about making the code for this
splice_read function disappear, but rather to eliminate a reference to a
bit of splice functionality (used *inside* the FUSE splice code) that
will not work without SPLICE_SYSCALL.
Would you prefer to see this specific case handled via an #ifdef in
fs/fuse/dev.c rather than introducing a __splice_p that people might be
inclined to propagate? That'd be fine; the code could simply wrap
fuse_dev_splice_read in an #ifdef and have the #else define a NULL
fuse_dev_splice_read.
- Josh Triplett
^ permalink raw reply
* [PATCH] net-timestamp: Fix a documentation typo
From: Andy Lutomirski @ 2014-11-24 20:02 UTC (permalink / raw)
To: Network Development, David S. Miller; +Cc: Andy Lutomirski, Willem de Bruijn
SOF_TIMESTAMPING_OPT_ID puts the id in ee_data, not ee_info.
Cc: Willem de Bruijn <willemb@google.com>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
While I'm here, the docs say:
In practice, it [ee_data] is a monotonically increasing u32 (that wraps).
Is user code supposed to rely on this and, further, on the fact that the
counter starts at zero? If not, how else is user code supposed to match
outgoing data to timestamps?
Also, is it intentional that the payload data associated with the tx
timestamp is (I think) the full outgoing packet including lower-layer
headers?
And, finally, would it be possible to attach IP_PKTINFO to the looped
timestamp? That way I could finally update my fancy ping program to
track which outgoing interface was used for a request.
Documentation/networking/timestamping.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt
index 412f45ca2d73..1d6d02d6ba52 100644
--- a/Documentation/networking/timestamping.txt
+++ b/Documentation/networking/timestamping.txt
@@ -136,7 +136,7 @@ SOF_TIMESTAMPING_OPT_ID:
This option is implemented only for transmit timestamps. There, the
timestamp is always looped along with a struct sock_extended_err.
- The option modifies field ee_info to pass an id that is unique
+ The option modifies field ee_data to pass an id that is unique
among all possibly concurrently outstanding timestamp requests for
that socket. In practice, it is a monotonically increasing u32
(that wraps).
--
1.9.3
^ permalink raw reply related
* [PATCH] net/ping: handle protocol mismatching scenario
From: Jane Zhou @ 2014-11-24 19:44 UTC (permalink / raw)
To: linux-kernel
Cc: Jane Zhou, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, stable, Yiwei Zhao
ping_lookup() may return a wrong sock if sk_buff's and sock's protocols
dont' match. For example, sk_buff's protocol is ETH_P_IPV6, but sock's
sk_family is AF_INET, in that case, if sk->sk_bound_dev_if is zero, a wrong
sock will be returned.
the fix is to "continue" the searching, if no matching, return NULL.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: netdev@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Jane Zhou <a17711@motorola.com>
Signed-off-by: Yiwei Zhao <gbjc64@motorola.com>
---
net/ipv4/ping.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index fc1c4b1..8892913 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -214,6 +214,8 @@ static struct sock *ping_lookup(struct net *net, struct sk_buff *skb, u16 ident)
&ipv6_hdr(skb)->daddr))
continue;
#endif
+ } else {
+ continue;
}
if (sk->sk_bound_dev_if && sk->sk_bound_dev_if != dif)
--
1.8.0
^ permalink raw reply related
* Re: [fuse-devel] [PATCH 4/6] fs/fuse: support compiling out splice
From: Greg KH @ 2014-11-24 19:34 UTC (permalink / raw)
To: Josh Triplett
Cc: Pieter Smith, Richard Weinberger, Michael S. Tsirkin,
Bertrand Jacquin, Oleg Nesterov, J. Bruce Fields, Eric Dumazet,
蔡正龙, Jeff Layton, Tom Herbert,
Alexei Starovoitov, Miklos Szeredi, Peter Foley, Hugh Dickins,
Xiao Guangrong, Geert Uytterhoeven, Mel Gorman, Matt Turner,
Paul E. McKenney, Alexander Duyck, open list:FUSE: FILESYSTEM...
In-Reply-To: <20141124160510.GA2446@jtriplet-mobl1>
On Mon, Nov 24, 2014 at 08:05:10AM -0800, Josh Triplett wrote:
> On Mon, Nov 24, 2014 at 10:49:31AM +0100, Pieter Smith wrote:
> > On Sun, Nov 23, 2014 at 03:23:02PM -0800, Josh Triplett wrote:
> > > On Sun, Nov 23, 2014 at 11:29:08PM +0100, Richard Weinberger wrote:
> > > > On Sun, Nov 23, 2014 at 3:20 PM, Pieter Smith <pieter@boesman.nl> wrote:
> > > > > To implement splice support, fs/fuse makes use of nosteal_pipe_buf_ops. This
> > > > > struct is exported by fs/splice. The goal of the larger patch set is to
> > > > > completely compile out fs/splice, so uses of the exported struct need to be
> > > > > compiled out along with fs/splice.
> > > > >
> > > > > This patch therefore compiles out splice support in fs/fuse when
> > > > > CONFIG_SYSCALL_SPLICE is undefined.
> > > > >
> > > > > Signed-off-by: Pieter Smith <pieter@boesman.nl>
> > > > > ---
> > > > > fs/fuse/dev.c | 4 ++--
> > > > > include/linux/fs.h | 6 ++++++
> > > > > 2 files changed, 8 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> > > > > index ca88731..f8f92a4 100644
> > > > > --- a/fs/fuse/dev.c
> > > > > +++ b/fs/fuse/dev.c
> > > > > @@ -1291,7 +1291,7 @@ static ssize_t fuse_dev_read(struct kiocb *iocb, const struct iovec *iov,
> > > > > return fuse_dev_do_read(fc, file, &cs, iov_length(iov, nr_segs));
> > > > > }
> > > > >
> > > > > -static ssize_t fuse_dev_splice_read(struct file *in, loff_t *ppos,
> > > > > +static ssize_t __maybe_unused fuse_dev_splice_read(struct file *in, loff_t *ppos,
> > > > > struct pipe_inode_info *pipe,
> > > > > size_t len, unsigned int flags)
> > > > > {
> > > > > @@ -2144,7 +2144,7 @@ const struct file_operations fuse_dev_operations = {
> > > > > .llseek = no_llseek,
> > > > > .read = do_sync_read,
> > > > > .aio_read = fuse_dev_read,
> > > > > - .splice_read = fuse_dev_splice_read,
> > > > > + .splice_read = __splice_p(fuse_dev_splice_read),
> > > > > .write = do_sync_write,
> > > > > .aio_write = fuse_dev_write,
> > > > > .splice_write = fuse_dev_splice_write,
> > > > > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > > > > index a957d43..04c0975 100644
> > > > > --- a/include/linux/fs.h
> > > > > +++ b/include/linux/fs.h
> > > > > @@ -2443,6 +2443,12 @@ extern int blkdev_fsync(struct file *filp, loff_t start, loff_t end,
> > > > > int datasync);
> > > > > extern void block_sync_page(struct page *page);
> > > > >
> > > > > +#ifdef CONFIG_SYSCALL_SPLICE
> > > > > +#define __splice_p(x) x
> > > > > +#else
> > > > > +#define __splice_p(x) NULL
> > > > > +#endif
> > > > > +
> > > >
> > > > This needs to go into a different patch.
> > > > One logical change per patch please. :-)
> > >
> > > Easy enough to merge this one into the patch introducing
> > > CONFIG_SYSCALL_SPLICE, then.
> > >
> > > - Josh Triplett
> >
> > The patch introducing CONFIG_SYSCALL_SPLICE (PATCH 3) only compiles out the
> > syscalls. PATCH 6 on the other hand, compiles out fs/splice.c. This patch
> > allows fs/fuse to be compiled when fs/splice.c is compiled out. If I am to
> > squash it, it would be logical to include it in PATCH 6, not 3.
>
> The suggestion wasn't to move the fs/fuse/dev.c bits; those should
> definitely stay in this patch. The suggestion was just to move the bit
> of the patch defining __splice_p from this patch to patch 3. (Note that
> you need to define it before you use it, so it can't go in patch 6.)
I would, again, argue that stuff like __splice_p() not be implemented at
all please. It will only cause a huge proliferation of stuff like this
that will not make any sense, and only cause a trivial, if any, amount
of code savings.
I thought you were going to not do this type of thing until you got the
gcc optimizer working for function callbacks.
Again, don't do this please.
thanks,
greg k-h
^ permalink raw reply
* Fw: [Bug 88111] New: Race condition in net_tx_action?
From: Stephen Hemminger @ 2014-11-13 3:19 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Wed, 12 Nov 2014 10:52:10 -0800
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 88111] New: Race condition in net_tx_action?
https://bugzilla.kernel.org/show_bug.cgi?id=88111
Bug ID: 88111
Summary: Race condition in net_tx_action?
Product: Networking
Version: 2.5
Kernel Version: all
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: shemminger@linux-foundation.org
Reporter: angelo.rizzi@3dautomazione.it
Regression: No
Hi all,
I have a question about a strange situation i've faced on my linux-based
embedded system:
Using 2 network device (transmitting asynchronously), i found a kind of "leak"
in sk_buff alloc/free that drives my test program, after some days of
continuous transmission, to be unable to write on the xmitting socket ("poll()"
function using POLLOUT request always returning 0).
After a lot of test, i've found the reason for such behaviour in the
net_tx_action() function (net/core/dev.c):
Let me explain what i've found:
The following code is used in order to get the current list of sk_buff to free:
static void net_tx_action(struct softirq_action *h)
{
struct softnet_data *sd = &__get_cpu_var(softnet_data);
if (sd->completion_queue) {
struct sk_buff *clist;
local_irq_disable();
clist = sd->completion_queue;
sd->completion_queue = NULL;
local_irq_enable();
Transmitting asynchronously on all the network devices available i've noticed
the following behaviour:
a) The instruction "if (sd->completion_queue) {" saves on a CPU register the
pointer value (register contents is used for the comparison)
b) The interupt is disabled (using "local_irq_disable")
c) when the content of "clist" is updated, the register is used, instead of
re-read the "completion_queue" variable.
So, when a low-level tx interrupt arrives after the latching of
"completion_queue", but before "local_irq_disable", the value stored in "clist"
reflect the situation before low-level tx interrupt, resulting in a sk_buff
leak
I've changed the declaration of "sd" as follows:
volatile struct softnet_data *sd = &__get_cpu_var(softnet_data);
and everything is now ok.
Is that correct?
Thanks,
Angelo
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: qstats update in packet scheduling
From: Dave Taht @ 2014-11-24 19:25 UTC (permalink / raw)
To: Josh Clark; +Cc: netdev
In-Reply-To: <CAHmvzZTF76DwdyBF9og2v9Vumx5v0BhHR584uX54o5R+T+iUMw@mail.gmail.com>
On Mon, Nov 24, 2014 at 11:14 AM, Josh Clark <jcinma@gmail.com> wrote:
> On Mon, Nov 24, 2014 at 2:01 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> On Mon, Nov 24, 2014 at 10:42 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>> On Mon, 2014-11-24 at 13:17 -0500, Josh Clark wrote:
>>>
>>>> But I'm seeing no change at all in qlen. qlen and backlog are both
>>>> zero, which results in zero qavg, meaning I can't test the RED
>>>> functionality at all.
>>>
>>> Wait. If you use some kernel patch without giving it, I can not comment.
>>>
>>> If you use regular "tc -s qdisc ...", then you'll see non zero qlen
>>
>> Well, assuming you have BQL or a software rate limiter in place in
>> front of it...
>>
> At the moment, I'm using standard RED (from /net/sched/sch_red.c) with
> some printks to output qstats.
> Are you saying that when I set this up, I need to use the -s flag in
> tc to maintain those statistics?
No. tc -s qdisc whatever, prints statistics with the -s option.
Statistics are always kept.
Example:
d@snapon:~$ tc -s qdisc show dev eth0
qdisc fq_codel 8001: root refcnt 2 limit 10240p flows 1024 quantum
1514 target 5.0ms interval 100.0ms ecn
Sent 76100781413 bytes 60627857 pkt (dropped 0, overlimits 0 requeues 267912)
backlog 0b 0p requeues 267912
maxpacket 68264 drop_overlimit 0 new_flow_count 383247 ecn_mark 0
new_flows_len 0 old_flows_len 0
And your printks will heisenbug your statistics collections, packet
processing can take place a lot faster than printks can.
>
> One more question: if I don't use -s, then what would RED use to calculate qavg?
The backlog. And if you dont have BQL in your device driver or a rate
limiter in front of RED, or are using a minimal number of tcp flows,
you rarely will see a backlog anymore in mainline linux.
Why?
"tcp small queues" keeps data in the tcp stack until it is needed.
Without bql there is no backpressure from the device drivers to feed
into the qdisc.
If you dont have BQL but you use a rate limiter, like HTB, + RED, and
run at a low rate, you will start to see RED keeping packets around
long enough to do various degrees of useful to nasty stuff to it.
And...
RED is dead. There is no reason to bother with it anymore. Please feel
free to catch up on decades worth of subsequent research instead.
See for example Van Jacobson's (the original author of RED)'s presentation here:
http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos
Or paper here:
http://queue.acm.org/detail.cfm?id=2209336
If there are interesting statistics you would like to pull out of pie,
codel, or fq_codel instead that are not already provided, please let
us know.
>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> Dave Täht
>>
>> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
--
Dave Täht
thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
^ permalink raw reply
* Re: qstats update in packet scheduling
From: Josh Clark @ 2014-11-24 19:14 UTC (permalink / raw)
To: Dave Taht; +Cc: Eric Dumazet, netdev
In-Reply-To: <CAA93jw4URTCK_O5mrJB14qAraubqj4Y-pvWMFX7ts=BWSgd-Og@mail.gmail.com>
On Mon, Nov 24, 2014 at 2:01 PM, Dave Taht <dave.taht@gmail.com> wrote:
> On Mon, Nov 24, 2014 at 10:42 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On Mon, 2014-11-24 at 13:17 -0500, Josh Clark wrote:
>>
>>> But I'm seeing no change at all in qlen. qlen and backlog are both
>>> zero, which results in zero qavg, meaning I can't test the RED
>>> functionality at all.
>>
>> Wait. If you use some kernel patch without giving it, I can not comment.
>>
>> If you use regular "tc -s qdisc ...", then you'll see non zero qlen
>
> Well, assuming you have BQL or a software rate limiter in place in
> front of it...
>
At the moment, I'm using standard RED (from /net/sched/sch_red.c) with
some printks to output qstats.
Are you saying that when I set this up, I need to use the -s flag in
tc to maintain those statistics?
One more question: if I don't use -s, then what would RED use to calculate qavg?
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Dave Täht
>
> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
^ permalink raw reply
* Re: [linux-nics] FIX ME in e1000_82575.c
From: nick @ 2014-11-24 19:14 UTC (permalink / raw)
To: Fujinaka, Todd, Kirsher, Jeffrey T
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Linux NICS, linux-kernel@vger.kernel.or
In-Reply-To: <9B4A1B1917080E46B64F07F2989DADD653451A92@ORSMSX114.amr.corp.intel.com>
Sounds good enough, just a question why is my email bouncing against linux-nics mailing list?
Cheers Nick
On 14-11-24 11:32 AM, Fujinaka, Todd wrote:
> I'm not sure there's much need to actually change the value. It's been the same since 2007 when the log message says, "Removed FIXME comment."
>
> I think someone forgot to remove the second FIXME comment. I'll send a patch.
>
> Todd Fujinaka
> Software Application Engineer
> Networking Division (ND)
> Intel Corporation
> todd.fujinaka@intel.com
> (503) 712-4565
>
> -----Original Message-----
> From: linux-nics-bounces@isotope.jf.intel.com [mailto:linux-nics-bounces@isotope.jf.intel.com] On Behalf Of nick
> Sent: Saturday, November 22, 2014 8:43 PM
> To: Kirsher, Jeffrey T
> Cc: Linux NICS; e1000-devel@lists.sourceforge.net; Vick, Matthew; netdev@vger.kernel.org; Wyborny, Carolyn; linux-kernel@vger.kernel.or
> Subject: [linux-nics] FIX ME in e1000_82575.c
>
> Greetings Again Jeff,
> I am wondering about sending in a patch to FIX ME in the file, e1000_82575 due to incorrect values in the function, igdb_acquire_swfw_sync_82575. If you or one of the other maintainers at Intel can send me the correct values or a hardware reference for me to find the values, I would be glad to send it a patch fixing these outstanding issues.
> Regards Nick
> _______________________________________________
> Linux-nics mailing list
> Linux-nics@intel.com
>
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: qstats update in packet scheduling
From: Dave Taht @ 2014-11-24 19:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Josh Clark, netdev
In-Reply-To: <1416854568.17888.69.camel@edumazet-glaptop2.roam.corp.google.com>
On Mon, Nov 24, 2014 at 10:42 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2014-11-24 at 13:17 -0500, Josh Clark wrote:
>
>> But I'm seeing no change at all in qlen. qlen and backlog are both
>> zero, which results in zero qavg, meaning I can't test the RED
>> functionality at all.
>
> Wait. If you use some kernel patch without giving it, I can not comment.
>
> If you use regular "tc -s qdisc ...", then you'll see non zero qlen
Well, assuming you have BQL or a software rate limiter in place in
front of it...
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dave Täht
thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
^ permalink raw reply
* [PATCH] net/smsc911x: Add minimal runtime PM support
From: Geert Uytterhoeven @ 2014-11-24 18:58 UTC (permalink / raw)
To: Steve Glendinning, David S. Miller
Cc: netdev, linux-pm, linux-sh, linux-kernel, Geert Uytterhoeven
Add minimal runtime PM support (enable on probe, disable on remove), to
ensure proper operation with a parent device that uses runtime PM.
This is needed on systems where the external bus controller module of
the SoC is contained in a PM domain and/or has a gateable functional
clock. In such cases, before accessing any device connected to the
external bus, the PM domain must be powered up, and/or the functional
clock must be enabled, which is typically handled through runtime PM by
the bus controller driver.
An example of this is the kzm9g development board, where an smsc9220
Ethernet controller is connected to the Bus State Controller (BSC) of a
Renesas sh73a0 SoC.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/net/ethernet/smsc/smsc911x.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
index 77ed74561e5fe815..f9c87624a0afb08b 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -59,6 +59,8 @@
#include <linux/of_device.h>
#include <linux/of_gpio.h>
#include <linux/of_net.h>
+#include <linux/pm_runtime.h>
+
#include "smsc911x.h"
#define SMSC_CHIPNAME "smsc911x"
@@ -2338,6 +2340,9 @@ static int smsc911x_drv_remove(struct platform_device *pdev)
free_netdev(dev);
+ pm_runtime_put(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+
return 0;
}
@@ -2491,6 +2496,9 @@ static int smsc911x_drv_probe(struct platform_device *pdev)
if (pdata->config.shift)
pdata->ops = &shifted_smsc911x_ops;
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_get_sync(&pdev->dev);
+
retval = smsc911x_init(dev);
if (retval < 0)
goto out_disable_resources;
@@ -2572,6 +2580,8 @@ out_unregister_netdev_5:
out_free_irq:
free_irq(dev->irq, dev);
out_disable_resources:
+ pm_runtime_put(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
(void)smsc911x_disable_resources(pdev);
out_enable_resources_fail:
smsc911x_free_resources(pdev);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 net-next 3/3] tuntap: Increase the number of queues in tun.
From: Pankaj Gupta @ 2014-11-24 18:46 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: davem, jasowang, dgibson, vfalico, edumazet, vyasevic, hkchu,
xemul, therbert, bhutchings, xii, stephen, jiri, sergei shtylyov,
Michael S. Tsirkin
In-Reply-To: <1416854050-10165-1-git-send-email-pagupta@redhat.com>
Adding Michael to CC.
>
> Networking under kvm works best if we allocate a per-vCPU RX and TX
> queue in a virtual NIC. This requires a per-vCPU queue on the host side.
>
> It is now safe to increase the maximum number of queues.
> Preceding patches:
> net: allow large number of rx queues
> tuntap: Reduce the size of tun_struct by using flex array
>
> made sure this won't cause failures due to high order memory
> allocations. Increase it to 256: this is the max number of vCPUs
> KVM supports.
>
> Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
> Reviewed-by: David Gibson <dgibson@redhat.com>
> ---
> drivers/net/tun.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index e3fa65a..a19dc5f8 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -113,10 +113,11 @@ struct tap_filter {
> unsigned char addr[FLT_EXACT_COUNT][ETH_ALEN];
> };
>
> -/* DEFAULT_MAX_NUM_RSS_QUEUES were chosen to let the rx/tx queues allocated
> for
> - * the netdevice to be fit in one page. So we can make sure the success of
> - * memory allocation. TODO: increase the limit. */
> -#define MAX_TAP_QUEUES DEFAULT_MAX_NUM_RSS_QUEUES
> +/* MAX_TAP_QUEUES 256 is chosen to allow rx/tx queues to be equal
> + * to max number of vCPUS in guest. Also, we are making sure here
> + * queue memory allocation do not fail.
> + */
> +#define MAX_TAP_QUEUES 256
> #define MAX_TAP_FLOWS 4096
>
> #define TUN_FLOW_EXPIRE (3 * HZ)
> --
> 1.8.3.1
>
>
^ permalink raw reply
* Re: [PATCH v2 net-next 2/3] tuntap: reduce the size of tun_struct by using flex array.
From: Pankaj Gupta @ 2014-11-24 18:45 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: davem, jasowang, dgibson, vfalico, edumazet, vyasevic, hkchu,
xemul, therbert, bhutchings, xii, stephen, jiri, sergei shtylyov
In-Reply-To: <1416854044-10124-1-git-send-email-pagupta@redhat.com>
Sorry! forgot to cc Michael, doing now.
>
> This patch switches to flex array to implement the flow caches, it brings
> several advantages:
>
> - Reduce the size of the tun_struct structure, which allows us to increase
> the
> upper limit of queues in future.
> - Avoid higher order memory allocation. It will be useful when switching to
> pure hashing in flow cache which may demand a larger size array in future.
>
> After this patch, the size of tun_struct on x86_64 reduced from 8512 to
> 328
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
> Reviewed-by: David Gibson <dgibson@redhat.com>
> ---
> drivers/net/tun.c | 49 +++++++++++++++++++++++++++++++++++++------------
> 1 file changed, 37 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index e3fa65a..bd07a6d 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -65,6 +65,7 @@
> #include <linux/nsproxy.h>
> #include <linux/virtio_net.h>
> #include <linux/rcupdate.h>
> +#include <linux/flex_array.h>
> #include <net/ipv6.h>
> #include <net/net_namespace.h>
> #include <net/netns/generic.h>
> @@ -188,7 +189,7 @@ struct tun_struct {
> int debug;
> #endif
> spinlock_t lock;
> - struct hlist_head flows[TUN_NUM_FLOW_ENTRIES];
> + struct flex_array *flows;
> struct timer_list flow_gc_timer;
> unsigned long ageing_time;
> unsigned int numdisabled;
> @@ -249,10 +250,11 @@ static void tun_flow_flush(struct tun_struct *tun)
>
> spin_lock_bh(&tun->lock);
> for (i = 0; i < TUN_NUM_FLOW_ENTRIES; i++) {
> + struct hlist_head *h = flex_array_get(tun->flows, i);
> struct tun_flow_entry *e;
> struct hlist_node *n;
>
> - hlist_for_each_entry_safe(e, n, &tun->flows[i], hash_link)
> + hlist_for_each_entry_safe(e, n, h, hash_link)
> tun_flow_delete(tun, e);
> }
> spin_unlock_bh(&tun->lock);
> @@ -264,10 +266,11 @@ static void tun_flow_delete_by_queue(struct tun_struct
> *tun, u16 queue_index)
>
> spin_lock_bh(&tun->lock);
> for (i = 0; i < TUN_NUM_FLOW_ENTRIES; i++) {
> + struct hlist_head *h = flex_array_get(tun->flows, i);
> struct tun_flow_entry *e;
> struct hlist_node *n;
>
> - hlist_for_each_entry_safe(e, n, &tun->flows[i], hash_link) {
> + hlist_for_each_entry_safe(e, n, h, hash_link) {
> if (e->queue_index == queue_index)
> tun_flow_delete(tun, e);
> }
> @@ -287,10 +290,11 @@ static void tun_flow_cleanup(unsigned long data)
>
> spin_lock_bh(&tun->lock);
> for (i = 0; i < TUN_NUM_FLOW_ENTRIES; i++) {
> + struct hlist_head *h = flex_array_get(tun->flows, i);
> struct tun_flow_entry *e;
> struct hlist_node *n;
>
> - hlist_for_each_entry_safe(e, n, &tun->flows[i], hash_link) {
> + hlist_for_each_entry_safe(e, n, h, hash_link) {
> unsigned long this_timer;
> count++;
> this_timer = e->updated + delay;
> @@ -317,7 +321,7 @@ static void tun_flow_update(struct tun_struct *tun, u32
> rxhash,
> if (!rxhash)
> return;
> else
> - head = &tun->flows[tun_hashfn(rxhash)];
> + head = flex_array_get(tun->flows, tun_hashfn(rxhash));
>
> rcu_read_lock();
>
> @@ -380,7 +384,8 @@ static u16 tun_select_queue(struct net_device *dev,
> struct sk_buff *skb,
>
> txq = skb_get_hash(skb);
> if (txq) {
> - e = tun_flow_find(&tun->flows[tun_hashfn(txq)], txq);
> + e = tun_flow_find(flex_array_get(tun->flows,
> + tun_hashfn(txq)), txq);
> if (e) {
> tun_flow_save_rps_rxhash(e, txq);
> txq = e->queue_index;
> @@ -760,8 +765,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb,
> struct net_device *dev)
> rxhash = skb_get_hash(skb);
> if (rxhash) {
> struct tun_flow_entry *e;
> - e = tun_flow_find(&tun->flows[tun_hashfn(rxhash)],
> - rxhash);
> + e = tun_flow_find(flex_array_get(tun->flows,
> + tun_hashfn(rxhash)), rxhash);
> if (e)
> tun_flow_save_rps_rxhash(e, rxhash);
> }
> @@ -896,23 +901,40 @@ static const struct net_device_ops tap_netdev_ops = {
> #endif
> };
>
> -static void tun_flow_init(struct tun_struct *tun)
> +static int tun_flow_init(struct tun_struct *tun)
> {
> - int i;
> + struct flex_array *buckets;
> + int i, err;
> +
> + buckets = flex_array_alloc(sizeof(struct hlist_head),
> + TUN_NUM_FLOW_ENTRIES, GFP_KERNEL);
> + if (!buckets)
> + return -ENOMEM;
> +
> + err = flex_array_prealloc(buckets, 0, TUN_NUM_FLOW_ENTRIES, GFP_KERNEL);
> + if (err) {
> + flex_array_free(buckets);
> + return -ENOMEM;
> + }
>
> + tun->flows = buckets;
> for (i = 0; i < TUN_NUM_FLOW_ENTRIES; i++)
> - INIT_HLIST_HEAD(&tun->flows[i]);
> + INIT_HLIST_HEAD((struct hlist_head *)
> + flex_array_get(buckets, i));
>
> tun->ageing_time = TUN_FLOW_EXPIRE;
> setup_timer(&tun->flow_gc_timer, tun_flow_cleanup, (unsigned long)tun);
> mod_timer(&tun->flow_gc_timer,
> round_jiffies_up(jiffies + tun->ageing_time));
> +
> + return 0;
> }
>
> static void tun_flow_uninit(struct tun_struct *tun)
> {
> del_timer_sync(&tun->flow_gc_timer);
> tun_flow_flush(tun);
> + flex_array_free(tun->flows);
> }
>
> /* Initialize net device. */
> @@ -1674,7 +1696,10 @@ static int tun_set_iff(struct net *net, struct file
> *file, struct ifreq *ifr)
> goto err_free_dev;
>
> tun_net_init(dev);
> - tun_flow_init(tun);
> +
> + err = tun_flow_init(tun);
> + if (err < 0)
> + goto err_free_dev;
>
> dev->hw_features = NETIF_F_SG | NETIF_F_FRAGLIST |
> TUN_USER_FEATURES | NETIF_F_HW_VLAN_CTAG_TX |
> --
> 1.8.3.1
>
>
^ permalink raw reply
* Re: [PATCH v2 net-next 1/3] net: allow large number of rx queues
From: Pankaj Gupta @ 2014-11-24 18:43 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: davem, jasowang, dgibson, vfalico, edumazet, vyasevic, hkchu,
xemul, therbert, bhutchings, xii, stephen, jiri, sergei shtylyov,
Michael S. Tsirkin
In-Reply-To: <1416854032-10083-1-git-send-email-pagupta@redhat.com>
Sorry! forgot to CC Michael, doing now.
> netif_alloc_rx_queues() uses kcalloc() to allocate memory
> for "struct netdev_queue *_rx" array.
> If we are doing large rx queue allocation kcalloc() might
> fail, so this patch does a fallback to vzalloc().
> Similar implementation is done for tx queue allocation in
> netif_alloc_netdev_queues().
>
> We avoid failure of high order memory allocation
> with the help of vzalloc(), this allows us to do large
> rx and tx queue allocation which in turn helps us to
> increase the number of queues in tun.
>
> As vmalloc() adds overhead on a critical network path,
> __GFP_REPEAT flag is used with kzalloc() to do this fallback
> only when really needed.
>
> Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
> Reviewed-by: David Gibson <dgibson@redhat.com>
> ---
> net/core/dev.c | 19 +++++++++++++------
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index e916ba8..abe9560 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -6059,17 +6059,25 @@ void netif_stacked_transfer_operstate(const struct
> net_device *rootdev,
> EXPORT_SYMBOL(netif_stacked_transfer_operstate);
>
> #ifdef CONFIG_SYSFS
> +static void netif_free_rx_queues(struct net_device *dev)
> +{
> + kvfree(dev->_rx);
> +}
> +
> static int netif_alloc_rx_queues(struct net_device *dev)
> {
> unsigned int i, count = dev->num_rx_queues;
> struct netdev_rx_queue *rx;
> + size_t sz = count * sizeof(*rx);
>
> BUG_ON(count < 1);
>
> - rx = kcalloc(count, sizeof(struct netdev_rx_queue), GFP_KERNEL);
> - if (!rx)
> - return -ENOMEM;
> -
> + rx = kzalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);
> + if (!rx) {
> + rx = vzalloc(sz);
> + if (!rx)
> + return -ENOMEM;
> + }
> dev->_rx = rx;
>
> for (i = 0; i < count; i++)
> @@ -6698,9 +6706,8 @@ void free_netdev(struct net_device *dev)
>
> netif_free_tx_queues(dev);
> #ifdef CONFIG_SYSFS
> - kfree(dev->_rx);
> + netif_free_rx_queues(dev);
> #endif
> -
> kfree(rcu_dereference_protected(dev->ingress_queue, 1));
>
> /* Flush device addresses */
> --
> 1.8.3.1
>
>
^ permalink raw reply
* Re: qstats update in packet scheduling
From: Eric Dumazet @ 2014-11-24 18:42 UTC (permalink / raw)
To: Josh Clark; +Cc: netdev
In-Reply-To: <CAHmvzZRwsd7S+T4cdAVzWGORcbkq+WWMtFAV6Ss3UrA+Ogeujg@mail.gmail.com>
On Mon, 2014-11-24 at 13:17 -0500, Josh Clark wrote:
> But I'm seeing no change at all in qlen. qlen and backlog are both
> zero, which results in zero qavg, meaning I can't test the RED
> functionality at all.
Wait. If you use some kernel patch without giving it, I can not comment.
If you use regular "tc -s qdisc ...", then you'll see non zero qlen
^ permalink raw reply
* Re: [PATCH v2 net-net 0/3] Increase the limit of tuntap queues
From: Pankaj Gupta @ 2014-11-24 18:42 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: davem, jasowang, dgibson, vfalico, edumazet, vyasevic, hkchu,
xemul, therbert, bhutchings, xii, stephen, jiri, sergei shtylyov,
Michael S. Tsirkin
In-Reply-To: <1416854006-10041-1-git-send-email-pagupta@redhat.com>
Sorry! forgot to add Michael, adding now.
> Networking under KVM works best if we allocate a per-vCPU rx and tx
> queue in a virtual NIC. This requires a per-vCPU queue on the host side.
> Modern physical NICs have multiqueue support for large number of queues.
> To scale vNIC to run multiple queues parallel to maximum number of vCPU's
> we need to increase number of queues support in tuntap.
>
> Changes from v1
> PATCH 2: David Miller - sysctl changes to limit number of queues
> not required for unprivileged users(dropped).
>
> Changes from RFC
> PATCH 1: Sergei Shtylyov - Add an empty line after declarations.
> PATCH 2: Jiri Pirko - Do not introduce new module paramaters.
> Michael.S.Tsirkin- We can use sysctl for limiting max number
> of queues.
>
> This series is to increase the limit of tuntap queues. Original work is being
> done by 'jasowang@redhat.com'. I am taking this
> 'https://lkml.org/lkml/2013/6/19/29'
> patch series as a reference. As per discussion in the patch series:
>
> There were two reasons which prevented us from increasing number of tun
> queues:
>
> - The netdev_queue array in netdevice were allocated through kmalloc, which
> may
> cause a high order memory allocation too when we have several queues.
> E.g. sizeof(netdev_queue) is 320, which means a high order allocation would
> happens when the device has more than 16 queues.
>
> - We store the hash buckets in tun_struct which results a very large size of
> tun_struct, this high order memory allocation fail easily when the memory
> is
> fragmented.
>
> The patch 60877a32bce00041528576e6b8df5abe9251fa73 increases the number of tx
> queues. Memory allocation fallback to vzalloc() when kmalloc() fails.
>
> This series tries to address following issues:
>
> - Increase the number of netdev_queue queues for rx similarly its done for tx
> queues by falling back to vzalloc() when memory allocation with kmalloc()
> fails.
>
> - Switches to use flex array to implement the flow caches to avoid higher
> order
> allocations.
>
> - Increase number of queues to 256, maximum number is equal to maximum number
> of vCPUS allowed in a guest.
>
> I have done some testing to test any regression with sample program which
> creates
> tun/tap for single queue / multiqueue device. I have also done testing with
> multiple
> parallel Netperf sessions from guest to host for different combination of
> queues
> and CPU's. It seems to be working fine without much increase in cpu load with
> the
> increase in number of queues.
>
> For this test vhost threads are pinned to separate CPU's. Below are the
> results:
> Host kernel: 3.18.rc4, Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 4 CPUS
> NIC : Ethernet controller: Intel Corporation 82579LM Gigabit Network
>
> 1] Before patch applied limit: Single Queue
> Guest, smp=2,
> 19:57:44 CPU %usr %nice %sys %iowait %irq %soft %steal
> %guest %gnice %idle
> 19:57:44 all 2.90 0.00 3.68 0.98 0.13 0.61 0.00
> 4.64 0.00 87.06
>
> 2] Patch applied, Tested with 2 queues, with vhost threads pinned to
> different physical cpus
> Guest, smp=2, queues =2
> 23:21:59 CPU %usr %nice %sys %iowait %irq %soft %steal
> %guest %gnice %idle
> 23:21:59 all 1.80 0.00 1.57 1.49 0.18 0.23 0.00
> 1.41 0.00 93.32
>
> 3] Tested with 4 queues, with vhost threads pinned to different physical cpus
> -------------------------------------------------------------------------------
> Guest, smp=4, queues =4
> 23:09:43 CPU %usr %nice %sys %iowait %irq %soft %steal
> %guest %gnice %idle
> 23:09:43 all 1.89 0.00 1.63 1.35 0.19 0.23 0.00
> 1.33 0.00 93.37
>
> Patches Summary:
> net: allow large number of rx queues
> tuntap: Reduce the size of tun_struct by using flex array
> tuntap: Increase the number of queues in tun
>
> drivers/net/tun.c | 58
> +++++++++++++++++++++++++++++++++++++++---------------
> net/core/dev.c | 19 ++++++++++++-----
> 2 files changed, 55 insertions(+), 22 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 1/1] fix return code from fib_rules_lookup()
From: Ani Sinha @ 2014-11-24 18:34 UTC (permalink / raw)
To: David Miller; +Cc: maze, Eric Dumazet, netdev@vger.kernel.org, fruggeri
In-Reply-To: <20141123.142438.1266838467850561800.davem@davemloft.net>
On Sun, Nov 23, 2014 at 11:24 AM, David Miller <davem@davemloft.net> wrote:
>
> How does this relate to the already committed:
>
> commit 49dd18ba4615eaa72f15c9087dea1c2ab4744cf5
> Author: Panu Matilainen <pmatilai@redhat.com>
> Date: Fri Nov 14 13:14:32 2014 +0200
>
> ipv4: Fix incorrect error code when adding an unreachable route
>
Oh wow! This was committed only a week or so ago. My tree wasn't
updated. Sorry. Yes, this is the same problem I was referring to and
this patch should fix it.
Ani
^ permalink raw reply
* [PATCH 2/2] net: wireless: rtlwifi: rtl8192ee: Fix compilation of the driver
From: Andreas Ruprecht @ 2014-11-24 18:34 UTC (permalink / raw)
To: Larry Finger
Cc: Chaoming Li, John W. Linville, linux-wireless, netdev,
linux-kernel, Andreas Ruprecht
In-Reply-To: <1416854072-14794-1-git-send-email-rupran@einserver.de>
In the Makefile for this driver, the wrong Kconfig option is used
to trigger the compilation of the object file. This leads to the
driver only being included into the kernel when both CONFIG_RTL8821AE
and CONFIG_RTL8192AE are set to "y".
Signed-off-by: Andreas Ruprecht <rupran@einserver.de>
---
drivers/net/wireless/rtlwifi/rtl8192ee/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/Makefile b/drivers/net/wireless/rtlwifi/rtl8192ee/Makefile
index 6bd46a9..0315eed 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ee/Makefile
+++ b/drivers/net/wireless/rtlwifi/rtl8192ee/Makefile
@@ -11,6 +11,6 @@ rtl8192ee-objs := \
trx.o \
-obj-$(CONFIG_RTL8821AE) += rtl8192ee.o
+obj-$(CONFIG_RTL8192EE) += rtl8192ee.o
ccflags-y += -D__CHECK_ENDIAN__
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] net: wireless: rtlwifi: Do not always include drivers in obj-m
From: Andreas Ruprecht @ 2014-11-24 18:34 UTC (permalink / raw)
To: Larry Finger
Cc: Chaoming Li, John W. Linville, linux-wireless, netdev,
linux-kernel, Andreas Ruprecht
In-Reply-To: <1416854072-14794-1-git-send-email-rupran@einserver.de>
In four of the rtlwifi drivers, the Makefile contains superfluous
statements indicating the compilation of the driver as an LKM
regardless of the corresponding Kconfig option.
If the corresponding option is set to 'y', the build system will then
see the object file in obj-m and obj-y, which leads to a compilation
as a built-in only. Even though this leads to the desired behavior,
the unconditional appearance in obj-m is confusing for someone reading
the Makefile.
This patch removes the superfluous Makefile statements.
Signed-off-by: Andreas Ruprecht <rupran@einserver.de>
---
drivers/net/wireless/rtlwifi/rtl8192ee/Makefile | 3 ---
drivers/net/wireless/rtlwifi/rtl8723ae/Makefile | 3 ---
drivers/net/wireless/rtlwifi/rtl8723be/Makefile | 3 ---
drivers/net/wireless/rtlwifi/rtl8821ae/Makefile | 3 ---
4 files changed, 12 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/Makefile b/drivers/net/wireless/rtlwifi/rtl8192ee/Makefile
index 11952b9..6bd46a9 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ee/Makefile
+++ b/drivers/net/wireless/rtlwifi/rtl8192ee/Makefile
@@ -1,6 +1,3 @@
-obj-m := rtl8192ee.o
-
-
rtl8192ee-objs := \
dm.o \
fw.o \
diff --git a/drivers/net/wireless/rtlwifi/rtl8723ae/Makefile b/drivers/net/wireless/rtlwifi/rtl8723ae/Makefile
index 9c34a85..6220672 100644
--- a/drivers/net/wireless/rtlwifi/rtl8723ae/Makefile
+++ b/drivers/net/wireless/rtlwifi/rtl8723ae/Makefile
@@ -1,6 +1,3 @@
-obj-m := rtl8723ae.o
-
-
rtl8723ae-objs := \
dm.o \
fw.o \
diff --git a/drivers/net/wireless/rtlwifi/rtl8723be/Makefile b/drivers/net/wireless/rtlwifi/rtl8723be/Makefile
index 59e416a..a77c341 100644
--- a/drivers/net/wireless/rtlwifi/rtl8723be/Makefile
+++ b/drivers/net/wireless/rtlwifi/rtl8723be/Makefile
@@ -1,6 +1,3 @@
-obj-m := rtl8723be.o
-
-
rtl8723be-objs := \
dm.o \
fw.o \
diff --git a/drivers/net/wireless/rtlwifi/rtl8821ae/Makefile b/drivers/net/wireless/rtlwifi/rtl8821ae/Makefile
index 87ad604..f7a26f7 100644
--- a/drivers/net/wireless/rtlwifi/rtl8821ae/Makefile
+++ b/drivers/net/wireless/rtlwifi/rtl8821ae/Makefile
@@ -1,6 +1,3 @@
-obj-m := rtl8821ae.o
-
-
rtl8821ae-objs := \
dm.o \
fw.o \
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] net: wireless: rtlwifi: Fix issues with Makefiles
From: Andreas Ruprecht @ 2014-11-24 18:34 UTC (permalink / raw)
To: Larry Finger
Cc: Chaoming Li, John W. Linville, linux-wireless, netdev,
linux-kernel, Andreas Ruprecht
This patch series fixes two issues in the Makefiles for different
rtlwifi drivers.
The first one lead to object files for the drivers always being
included in obj-m even if the corresponding Kconfig option is set to
'y'.
The second one is likely to be a copy-and-paste mistake, which
prevents compilation of the rtl8192ee driver unless the
completely unrelated Kconfig option for the rtl8821ae driver
(CONFIG_RTL8821AE) is also enabled.
Andreas Ruprecht (2):
net: wireless: rtlwifi: Do not always include drivers in obj-m
net: wireless: rtlwifi: rtl8192ee: Fix compilation of the driver
drivers/net/wireless/rtlwifi/rtl8192ee/Makefile | 5 +----
drivers/net/wireless/rtlwifi/rtl8723ae/Makefile | 3 ---
drivers/net/wireless/rtlwifi/rtl8723be/Makefile | 3 ---
drivers/net/wireless/rtlwifi/rtl8821ae/Makefile | 3 ---
4 files changed, 1 insertion(+), 13 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH v2 net-next 3/3] tuntap: Increase the number of queues in tun.
From: Pankaj Gupta @ 2014-11-24 18:34 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: davem, jasowang, dgibson, vfalico, edumazet, vyasevic, hkchu,
xemul, therbert, bhutchings, xii, stephen, jiri, sergei.shtylyov,
pagupta
Networking under kvm works best if we allocate a per-vCPU RX and TX
queue in a virtual NIC. This requires a per-vCPU queue on the host side.
It is now safe to increase the maximum number of queues.
Preceding patches:
net: allow large number of rx queues
tuntap: Reduce the size of tun_struct by using flex array
made sure this won't cause failures due to high order memory
allocations. Increase it to 256: this is the max number of vCPUs
KVM supports.
Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
Reviewed-by: David Gibson <dgibson@redhat.com>
---
drivers/net/tun.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index e3fa65a..a19dc5f8 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -113,10 +113,11 @@ struct tap_filter {
unsigned char addr[FLT_EXACT_COUNT][ETH_ALEN];
};
-/* DEFAULT_MAX_NUM_RSS_QUEUES were chosen to let the rx/tx queues allocated for
- * the netdevice to be fit in one page. So we can make sure the success of
- * memory allocation. TODO: increase the limit. */
-#define MAX_TAP_QUEUES DEFAULT_MAX_NUM_RSS_QUEUES
+/* MAX_TAP_QUEUES 256 is chosen to allow rx/tx queues to be equal
+ * to max number of vCPUS in guest. Also, we are making sure here
+ * queue memory allocation do not fail.
+ */
+#define MAX_TAP_QUEUES 256
#define MAX_TAP_FLOWS 4096
#define TUN_FLOW_EXPIRE (3 * HZ)
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 net-next 3/3] tuntap: reduce the size of tun_struct by using flex array.
From: Pankaj Gupta @ 2014-11-24 18:34 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: davem, jasowang, dgibson, vfalico, edumazet, vyasevic, hkchu,
xemul, therbert, bhutchings, xii, stephen, jiri, sergei.shtylyov,
pagupta
This patch switches to flex array to implement the flow caches, it brings
several advantages:
- Reduce the size of the tun_struct structure, which allows us to increase the
upper limit of queues in future.
- Avoid higher order memory allocation. It will be useful when switching to
pure hashing in flow cache which may demand a larger size array in future.
After this patch, the size of tun_struct on x86_64 reduced from 8512 to
328
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
Reviewed-by: David Gibson <dgibson@redhat.com>
---
drivers/net/tun.c | 49 +++++++++++++++++++++++++++++++++++++------------
1 file changed, 37 insertions(+), 12 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index e3fa65a..bd07a6d 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -65,6 +65,7 @@
#include <linux/nsproxy.h>
#include <linux/virtio_net.h>
#include <linux/rcupdate.h>
+#include <linux/flex_array.h>
#include <net/ipv6.h>
#include <net/net_namespace.h>
#include <net/netns/generic.h>
@@ -188,7 +189,7 @@ struct tun_struct {
int debug;
#endif
spinlock_t lock;
- struct hlist_head flows[TUN_NUM_FLOW_ENTRIES];
+ struct flex_array *flows;
struct timer_list flow_gc_timer;
unsigned long ageing_time;
unsigned int numdisabled;
@@ -249,10 +250,11 @@ static void tun_flow_flush(struct tun_struct *tun)
spin_lock_bh(&tun->lock);
for (i = 0; i < TUN_NUM_FLOW_ENTRIES; i++) {
+ struct hlist_head *h = flex_array_get(tun->flows, i);
struct tun_flow_entry *e;
struct hlist_node *n;
- hlist_for_each_entry_safe(e, n, &tun->flows[i], hash_link)
+ hlist_for_each_entry_safe(e, n, h, hash_link)
tun_flow_delete(tun, e);
}
spin_unlock_bh(&tun->lock);
@@ -264,10 +266,11 @@ static void tun_flow_delete_by_queue(struct tun_struct *tun, u16 queue_index)
spin_lock_bh(&tun->lock);
for (i = 0; i < TUN_NUM_FLOW_ENTRIES; i++) {
+ struct hlist_head *h = flex_array_get(tun->flows, i);
struct tun_flow_entry *e;
struct hlist_node *n;
- hlist_for_each_entry_safe(e, n, &tun->flows[i], hash_link) {
+ hlist_for_each_entry_safe(e, n, h, hash_link) {
if (e->queue_index == queue_index)
tun_flow_delete(tun, e);
}
@@ -287,10 +290,11 @@ static void tun_flow_cleanup(unsigned long data)
spin_lock_bh(&tun->lock);
for (i = 0; i < TUN_NUM_FLOW_ENTRIES; i++) {
+ struct hlist_head *h = flex_array_get(tun->flows, i);
struct tun_flow_entry *e;
struct hlist_node *n;
- hlist_for_each_entry_safe(e, n, &tun->flows[i], hash_link) {
+ hlist_for_each_entry_safe(e, n, h, hash_link) {
unsigned long this_timer;
count++;
this_timer = e->updated + delay;
@@ -317,7 +321,7 @@ static void tun_flow_update(struct tun_struct *tun, u32 rxhash,
if (!rxhash)
return;
else
- head = &tun->flows[tun_hashfn(rxhash)];
+ head = flex_array_get(tun->flows, tun_hashfn(rxhash));
rcu_read_lock();
@@ -380,7 +384,8 @@ static u16 tun_select_queue(struct net_device *dev, struct sk_buff *skb,
txq = skb_get_hash(skb);
if (txq) {
- e = tun_flow_find(&tun->flows[tun_hashfn(txq)], txq);
+ e = tun_flow_find(flex_array_get(tun->flows,
+ tun_hashfn(txq)), txq);
if (e) {
tun_flow_save_rps_rxhash(e, txq);
txq = e->queue_index;
@@ -760,8 +765,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
rxhash = skb_get_hash(skb);
if (rxhash) {
struct tun_flow_entry *e;
- e = tun_flow_find(&tun->flows[tun_hashfn(rxhash)],
- rxhash);
+ e = tun_flow_find(flex_array_get(tun->flows,
+ tun_hashfn(rxhash)), rxhash);
if (e)
tun_flow_save_rps_rxhash(e, rxhash);
}
@@ -896,23 +901,40 @@ static const struct net_device_ops tap_netdev_ops = {
#endif
};
-static void tun_flow_init(struct tun_struct *tun)
+static int tun_flow_init(struct tun_struct *tun)
{
- int i;
+ struct flex_array *buckets;
+ int i, err;
+
+ buckets = flex_array_alloc(sizeof(struct hlist_head),
+ TUN_NUM_FLOW_ENTRIES, GFP_KERNEL);
+ if (!buckets)
+ return -ENOMEM;
+
+ err = flex_array_prealloc(buckets, 0, TUN_NUM_FLOW_ENTRIES, GFP_KERNEL);
+ if (err) {
+ flex_array_free(buckets);
+ return -ENOMEM;
+ }
+ tun->flows = buckets;
for (i = 0; i < TUN_NUM_FLOW_ENTRIES; i++)
- INIT_HLIST_HEAD(&tun->flows[i]);
+ INIT_HLIST_HEAD((struct hlist_head *)
+ flex_array_get(buckets, i));
tun->ageing_time = TUN_FLOW_EXPIRE;
setup_timer(&tun->flow_gc_timer, tun_flow_cleanup, (unsigned long)tun);
mod_timer(&tun->flow_gc_timer,
round_jiffies_up(jiffies + tun->ageing_time));
+
+ return 0;
}
static void tun_flow_uninit(struct tun_struct *tun)
{
del_timer_sync(&tun->flow_gc_timer);
tun_flow_flush(tun);
+ flex_array_free(tun->flows);
}
/* Initialize net device. */
@@ -1674,7 +1696,10 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
goto err_free_dev;
tun_net_init(dev);
- tun_flow_init(tun);
+
+ err = tun_flow_init(tun);
+ if (err < 0)
+ goto err_free_dev;
dev->hw_features = NETIF_F_SG | NETIF_F_FRAGLIST |
TUN_USER_FEATURES | NETIF_F_HW_VLAN_CTAG_TX |
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 net-next 1/3] net: allow large number of rx queues
From: Pankaj Gupta @ 2014-11-24 18:33 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: davem, jasowang, dgibson, vfalico, edumazet, vyasevic, hkchu,
xemul, therbert, bhutchings, xii, stephen, jiri, sergei.shtylyov,
pagupta
netif_alloc_rx_queues() uses kcalloc() to allocate memory
for "struct netdev_queue *_rx" array.
If we are doing large rx queue allocation kcalloc() might
fail, so this patch does a fallback to vzalloc().
Similar implementation is done for tx queue allocation in
netif_alloc_netdev_queues().
We avoid failure of high order memory allocation
with the help of vzalloc(), this allows us to do large
rx and tx queue allocation which in turn helps us to
increase the number of queues in tun.
As vmalloc() adds overhead on a critical network path,
__GFP_REPEAT flag is used with kzalloc() to do this fallback
only when really needed.
Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: David Gibson <dgibson@redhat.com>
---
net/core/dev.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index e916ba8..abe9560 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6059,17 +6059,25 @@ void netif_stacked_transfer_operstate(const struct net_device *rootdev,
EXPORT_SYMBOL(netif_stacked_transfer_operstate);
#ifdef CONFIG_SYSFS
+static void netif_free_rx_queues(struct net_device *dev)
+{
+ kvfree(dev->_rx);
+}
+
static int netif_alloc_rx_queues(struct net_device *dev)
{
unsigned int i, count = dev->num_rx_queues;
struct netdev_rx_queue *rx;
+ size_t sz = count * sizeof(*rx);
BUG_ON(count < 1);
- rx = kcalloc(count, sizeof(struct netdev_rx_queue), GFP_KERNEL);
- if (!rx)
- return -ENOMEM;
-
+ rx = kzalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);
+ if (!rx) {
+ rx = vzalloc(sz);
+ if (!rx)
+ return -ENOMEM;
+ }
dev->_rx = rx;
for (i = 0; i < count; i++)
@@ -6698,9 +6706,8 @@ void free_netdev(struct net_device *dev)
netif_free_tx_queues(dev);
#ifdef CONFIG_SYSFS
- kfree(dev->_rx);
+ netif_free_rx_queues(dev);
#endif
-
kfree(rcu_dereference_protected(dev->ingress_queue, 1));
/* Flush device addresses */
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 net-net 0/4] Increase the limit of tuntap queues
From: Pankaj Gupta @ 2014-11-24 18:33 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: davem, jasowang, dgibson, vfalico, edumazet, vyasevic, hkchu,
xemul, therbert, bhutchings, xii, stephen, jiri, sergei.shtylyov,
pagupta
Networking under KVM works best if we allocate a per-vCPU rx and tx
queue in a virtual NIC. This requires a per-vCPU queue on the host side.
Modern physical NICs have multiqueue support for large number of queues.
To scale vNIC to run multiple queues parallel to maximum number of vCPU's
we need to increase number of queues support in tuntap.
Changes from v1
PATCH 2: David Miller - sysctl changes to limit number of queues
not required for unprivileged users(dropped).
Changes from RFC
PATCH 1: Sergei Shtylyov - Add an empty line after declarations.
PATCH 2: Jiri Pirko - Do not introduce new module paramaters.
Michael.S.Tsirkin- We can use sysctl for limiting max number
of queues.
This series is to increase the limit of tuntap queues. Original work is being
done by 'jasowang@redhat.com'. I am taking this 'https://lkml.org/lkml/2013/6/19/29'
patch series as a reference. As per discussion in the patch series:
There were two reasons which prevented us from increasing number of tun queues:
- The netdev_queue array in netdevice were allocated through kmalloc, which may
cause a high order memory allocation too when we have several queues.
E.g. sizeof(netdev_queue) is 320, which means a high order allocation would
happens when the device has more than 16 queues.
- We store the hash buckets in tun_struct which results a very large size of
tun_struct, this high order memory allocation fail easily when the memory is
fragmented.
The patch 60877a32bce00041528576e6b8df5abe9251fa73 increases the number of tx
queues. Memory allocation fallback to vzalloc() when kmalloc() fails.
This series tries to address following issues:
- Increase the number of netdev_queue queues for rx similarly its done for tx
queues by falling back to vzalloc() when memory allocation with kmalloc() fails.
- Switches to use flex array to implement the flow caches to avoid higher order
allocations.
- Increase number of queues to 256, maximum number is equal to maximum number
of vCPUS allowed in a guest.
I have done some testing to test any regression with sample program which creates
tun/tap for single queue / multiqueue device. I have also done testing with multiple
parallel Netperf sessions from guest to host for different combination of queues
and CPU's. It seems to be working fine without much increase in cpu load with the
increase in number of queues.
For this test vhost threads are pinned to separate CPU's. Below are the results:
Host kernel: 3.18.rc4, Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 4 CPUS
NIC : Ethernet controller: Intel Corporation 82579LM Gigabit Network
1] Before patch applied limit: Single Queue
Guest, smp=2,
19:57:44 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
19:57:44 all 2.90 0.00 3.68 0.98 0.13 0.61 0.00 4.64 0.00 87.06
2] Patch applied, Tested with 2 queues, with vhost threads pinned to different physical cpus
Guest, smp=2, queues =2
23:21:59 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
23:21:59 all 1.80 0.00 1.57 1.49 0.18 0.23 0.00 1.41 0.00 93.32
3] Tested with 4 queues, with vhost threads pinned to different physical cpus
-------------------------------------------------------------------------------
Guest, smp=4, queues =4
23:09:43 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
23:09:43 all 1.89 0.00 1.63 1.35 0.19 0.23 0.00 1.33 0.00 93.37
Patches Summary:
net: allow large number of rx queues
tuntap: Reduce the size of tun_struct by using flex array
tuntap: Increase the number of queues in tun
drivers/net/tun.c | 58 +++++++++++++++++++++++++++++++++++++++---------------
net/core/dev.c | 19 ++++++++++++-----
2 files changed, 55 insertions(+), 22 deletions(-)
^ permalink raw reply
* Re: qstats update in packet scheduling
From: Josh Clark @ 2014-11-24 18:17 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1416850289.17888.67.camel@edumazet-glaptop2.roam.corp.google.com>
On Mon, Nov 24, 2014 at 12:31 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2014-11-24 at 12:06 -0500, Josh Clark wrote:
>> Hi everyone,
>>
>> I'm working on a research project to add some extra functionality to
>> RED. Right now, I'm tracking qstats to look at the factors that RED
>> uses to calculate marking probability. Using standard RED with printk
>> debug statements, I'm seeing that there are some drops, but no change
>> in qlen or backlog when I send 12Mbps through a 10Mbps link.
>>
>> Does RED use some other means to update qstats and track backlog, or
>> do I need to change how I'm sending the test traffic though?
>
> With steady traffic, there is no reason qlen should vary.
>
> It should reach some equilibrium as well.
>
But I'm seeing no change at all in qlen. qlen and backlog are both
zero, which results in zero qavg, meaning I can't test the RED
functionality at all.
^ 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