* Re: [fuse-devel] [PATCH 4/6] fs/fuse: support compiling out splice
From: Josh Triplett @ 2014-11-24 16:05 UTC (permalink / raw)
To: Pieter Smith
Cc: 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...,
Luis R. Rodriguez
In-Reply-To: <20141124094931.GA1055@smipidev>
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.)
- Josh Triplett
^ permalink raw reply
* GRE with GRO very slow when forwarding starting with 3.14.24
From: Wolfgang Walter @ 2014-11-24 16:13 UTC (permalink / raw)
To: netdev; +Cc: Stable Kernel
Hello,
starting with 3.14.24 GRE with GRO on is very slow. To be more specific:
yyyy <--> GRO_endpoint <-_> .... <--> |eth0<->GRO-endpoint | eth1 |<-> xxxx
routing (IPv4) between xxxx and yyyy is very slow when GRO is enabled on eth0
and/or eth1 starting with stable kernel 3.14.24
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
^ permalink raw reply
* RE: [linux-nics] FIX ME in e1000_82575.c
From: Fujinaka, Todd @ 2014-11-24 16:32 UTC (permalink / raw)
To: nick, Kirsher, Jeffrey T
Cc: Linux NICS, e1000-devel@lists.sourceforge.net, Vick, Matthew,
netdev@vger.kernel.org, Wyborny, Carolyn,
linux-kernel@vger.kernel.or
In-Reply-To: <547165BC.2000508@gmail.com>
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
^ permalink raw reply
* [PATCH iproute2] iplink: allow to show ip addresses
From: Nicolas Dichtel @ 2014-11-24 16:42 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Nicolas Dichtel
This patch adds a new option (-addresses) to the 'ip link' command so that the
user can display link details and IP addresses with the same command.
Example:
$ ip -d -a l ls gre1
9: gre1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1468 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/gre 10.16.0.249 peer 10.16.0.121 promiscuity 0
gre remote 10.16.0.121 local 10.16.0.249 ttl inherit ikey 0.0.0.10 okey 0.0.0.10 icsum ocsum
inet 192.168.0.249 peer 192.168.0.121/32 scope global gre1
valid_lft forever preferred_lft forever
inet6 fe80::5efe:a10:f9/64 scope link
valid_lft forever preferred_lft forever
Suggested-by: Christophe Gouault <christophe.gouault@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
include/utils.h | 1 +
ip/ip.c | 3 +++
ip/ipaddress.c | 5 +++--
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/utils.h b/include/utils.h
index eef9c42d2fd5..9d0f2ad83e49 100644
--- a/include/utils.h
+++ b/include/utils.h
@@ -15,6 +15,7 @@ extern int human_readable;
extern int use_iec;
extern int show_stats;
extern int show_details;
+extern int show_addresses;
extern int show_raw;
extern int resolve_hosts;
extern int oneline;
diff --git a/ip/ip.c b/ip/ip.c
index 5f759d5424aa..ad53d14a1fd9 100644
--- a/ip/ip.c
+++ b/ip/ip.c
@@ -28,6 +28,7 @@ int human_readable = 0;
int use_iec = 0;
int show_stats = 0;
int show_details = 0;
+int show_addresses = 0;
int resolve_hosts = 0;
int oneline = 0;
int timestamp = 0;
@@ -226,6 +227,8 @@ int main(int argc, char **argv)
++show_stats;
} else if (matches(opt, "-details") == 0) {
++show_details;
+ } else if (matches(opt, "-addresses") == 0) {
+ ++show_addresses;
} else if (matches(opt, "-resolve") == 0) {
++resolve_hosts;
} else if (matches(opt, "-oneline") == 0) {
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index db39437305a9..10cbb4248a67 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -1323,7 +1323,7 @@ static int ipaddr_list_flush_or_save(int argc, char **argv, int action)
* link filters are present, use RTM_GETLINK to get
* the link device
*/
- if (filter_dev && filter.group == -1 && do_link == 1) {
+ if (filter_dev && filter.group == -1 && do_link == 1 && show_addresses == 0) {
if (iplink_get(0, filter_dev, RTEXT_FILTER_VF) < 0) {
perror("Cannot send link get request");
exit(1);
@@ -1437,7 +1437,8 @@ void ipaddr_get_vf_rate(int vfnum, int *min, int *max, int idx)
int ipaddr_list_link(int argc, char **argv)
{
- preferred_family = AF_PACKET;
+ if (show_addresses == 0)
+ preferred_family = AF_PACKET;
do_link = 1;
return ipaddr_list_flush_or_save(argc, argv, IPADD_LIST);
}
--
2.1.0
^ permalink raw reply related
* Re: GRE with GRO very slow when forwarding starting with 3.14.24
From: Eric Dumazet @ 2014-11-24 16:48 UTC (permalink / raw)
To: Wolfgang Walter; +Cc: netdev, Tom Herbert, Alexander Duyck
In-Reply-To: <2340533.MickblD7NF@h2o.as.studentenwerk.mhn.de>
On Mon, 2014-11-24 at 17:13 +0100, Wolfgang Walter wrote:
> Hello,
>
> starting with 3.14.24 GRE with GRO on is very slow. To be more specific:
>
> yyyy <--> GRO_endpoint <-_> .... <--> |eth0<->GRO-endpoint | eth1 |<-> xxxx
>
> routing (IPv4) between xxxx and yyyy is very slow when GRO is enabled on eth0
> and/or eth1 starting with stable kernel 3.14.24
>
> Regards,
tcpdump might help, but I presume GSO is no longer working properly on
egress.
Can you try to revert :
commit abe640984aa492652232b65d3579361cf6d461f5
Author: Tom Herbert <therbert@google.com>
Date: Thu Oct 30 08:40:56 2014 -0700
gre: Use inner mac length when computing tunnel length
[ Upstream commit 14051f0452a2c26a3f4791e6ad6a435e8f1945ff ]
Currently, skb_inner_network_header is used but this does not account
for Ethernet header for ETH_P_TEB. Use skb_inner_mac_header which
handles TEB and also should work with IP encapsulation in which case
inner mac and inner network headers are the same.
Tested: Ran TCP_STREAM over GRE, worked as expected.
Signed-off-by: Tom Herbert <therbert@google.com>
Acked-by: Alexander Duyck <alexander.h.duyck@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
diff --git a/net/ipv4/gre_offload.c b/net/ipv4/gre_offload.c
index 2d24f293f977..8c8493ea6b1c 100644
--- a/net/ipv4/gre_offload.c
+++ b/net/ipv4/gre_offload.c
@@ -50,7 +50,7 @@ static struct sk_buff *gre_gso_segment(struct sk_buff *skb,
greh = (struct gre_base_hdr *)skb_transport_header(skb);
- ghl = skb_inner_network_header(skb) - skb_transport_header(skb);
+ ghl = skb_inner_mac_header(skb) - skb_transport_header(skb);
if (unlikely(ghl < sizeof(*greh)))
goto out;
^ permalink raw reply related
* RE: [net-next 03/17] i40e: allow various base numbers in debugfs aq commands
From: David Laight @ 2014-11-24 16:50 UTC (permalink / raw)
To: 'Jeff Kirsher', davem@davemloft.net
Cc: Shannon Nelson, netdev@vger.kernel.org, nhorman@redhat.com,
sassmann@redhat.com, jogreene@redhat.com
In-Reply-To: <1416635708-4765-5-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher
> From: Shannon Nelson <shannon.nelson@intel.com>
>
> Use the 'i' rather than the more restrictive 'x' or 'd' in the aq_cmd
> arguments. This makes the user interface much more forgiving and user
> friendly.
>
> Change-ID: I5dcd57b9befc047e06b74cf1152a25a3fa9e1309
> Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
> b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
> index 3a3c237..16ac3f8 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
> @@ -1493,7 +1493,7 @@ static ssize_t i40e_dbg_command_write(struct file *filp,
> if (!desc)
> goto command_write_done;
> cnt = sscanf(&cmd_buf[11],
> - "%hx %hx %hx %hx %x %x %x %x %x %x",
> + "%hi %hi %hi %hi %i %i %i %i %i %i",
Isn't that an API change?
Anything that used to specify "10" will now get 10 instead of 16.
So if this has been in a release kernel you probably shouldn't change it.
David
> &desc->flags,
> &desc->opcode, &desc->datalen, &desc->retval,
> &desc->cookie_high, &desc->cookie_low,
> @@ -1541,7 +1541,7 @@ static ssize_t i40e_dbg_command_write(struct file *filp,
> if (!desc)
> goto command_write_done;
> cnt = sscanf(&cmd_buf[20],
> - "%hx %hx %hx %hx %x %x %x %x %x %x %hd",
> + "%hi %hi %hi %hi %i %i %i %i %i %i %hi",
> &desc->flags,
> &desc->opcode, &desc->datalen, &desc->retval,
> &desc->cookie_high, &desc->cookie_low,
> --
> 1.9.3
>
> --
> 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
^ permalink raw reply
* qstats update in packet scheduling
From: Josh Clark @ 2014-11-24 17:06 UTC (permalink / raw)
To: netdev
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?
Thank you for all your help.
-Josh Clark
^ permalink raw reply
* Re: net_tx_action race condition?
From: Angelo Rizzi @ 2014-11-24 17:19 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-kernel@vger.kernel.org
In-Reply-To: <1416843200.17888.53.camel@edumazet-glaptop2.roam.corp.google.com>
Hi Eric,
Thanks for your reply
You are right, it seems a bug in the NIOS2 architecture port.
I will check how local_irq_disable()/local_irq_enable() is implemented
on this kind of architecture.
Regards,
Angelo
Il 24/11/2014 16:33, Eric Dumazet ha scritto:
> On Mon, 2014-11-24 at 14:29 +0100, Angelo Rizzi wrote:
>> Hi Daniel,
>> Here attached the patch file you required.
>> The problem i've found is on the declaration of 'struct softnet_data
>> *sd' in function 'net_tx_action'
>> What happens to me (i have an embedded system based on FPGA and a NIOS2
>> cpu) is that, due to compiler optimization, the content of
>> 'sd->completion_queue' is saved in a CPU register before interrupt
>> disabling (when the instruction 'if (sd->completion_queue) {' is
>> executed) and then the register contents is used for interrupt-disabled
>> assignment ('clist = sd->completion_queue') instead of re-read the
>> variable contents.
>> This seems to lead to a race condition when an interrupt modifies the
>> content of 'sd->completion_queue' between these two instructions.
>> What i have done to avoid this situation is to change the declaration of
>> 'struct softnet_data *sd' to 'volatile struct softnet_data *sd' and now
>> everything seems to be ok.
>> I hope this will help.
>>
>> Regards,
>> Angelo
>>
> Do not add volatile in the kernel, this is not how we solve this kind of
> problems. Documentation/memory-barriers.txt and
>
> Documentation/00-INDEX:476:volatile-considered-harmful.txt
> Documentation/00-INDEX:477: - Why the "volatile" type class should not be used
>
>
> I am surprised this patch is needed. Many other 'bugs' would need
> similar fixes.
>
> local_irq_disable() MUST have a memory barrier. This looks like a bug in
> one particular arch implementation.
>
>
> On x86 for example, native_irq_disable() is really :
>
> asm volatile("cli": : :"memory");
>
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index ac4836241a965a71952469ba054f87d8dfca2d32..fa73072e515aa07fa8ae1bc39174b7d59c7a31a5 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3406,7 +3406,7 @@ static void net_tx_action(struct softirq_action *h)
> struct sk_buff *clist;
>
> local_irq_disable();
> - clist = sd->completion_queue;
> + clist = ACCESS_ONCE(sd->completion_queue);
> sd->completion_queue = NULL;
> local_irq_enable();
>
>
>
>
^ permalink raw reply
* RE: [net-next 03/17] i40e: allow various base numbers in debugfs aq commands
From: Nelson, Shannon @ 2014-11-24 17:26 UTC (permalink / raw)
To: David Laight, Kirsher, Jeffrey T, davem@davemloft.net
Cc: netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1C9FA07E@AcuExch.aculab.com>
> -----Original Message-----
> From: David Laight [mailto:David.Laight@ACULAB.COM]
> Sent: Monday, November 24, 2014 8:51 AM
> To: Kirsher, Jeffrey T; davem@davemloft.net
> Cc: Nelson, Shannon; netdev@vger.kernel.org; nhorman@redhat.com;
> sassmann@redhat.com; jogreene@redhat.com
> Subject: RE: [net-next 03/17] i40e: allow various base numbers in
> debugfs aq commands
>
> From: Jeff Kirsher
> > From: Shannon Nelson <shannon.nelson@intel.com>
> >
> > Use the 'i' rather than the more restrictive 'x' or 'd' in the aq_cmd
> > arguments. This makes the user interface much more forgiving and user
> > friendly.
> >
> > Change-ID: I5dcd57b9befc047e06b74cf1152a25a3fa9e1309
> > Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > ---
> > drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
> > b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
> > index 3a3c237..16ac3f8 100644
> > --- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
> > @@ -1493,7 +1493,7 @@ static ssize_t i40e_dbg_command_write(struct
> file *filp,
> > if (!desc)
> > goto command_write_done;
> > cnt = sscanf(&cmd_buf[11],
> > - "%hx %hx %hx %hx %x %x %x %x %x %x",
> > + "%hi %hi %hi %hi %i %i %i %i %i %i",
>
> Isn't that an API change?
> Anything that used to specify "10" will now get 10 instead of 16.
>
> So if this has been in a release kernel you probably shouldn't change
> it.
>
> David
Thanks, David, for looking through our code.
If this were in any other part of the kernel, I would agree with you. However, this is in our debugfs module, which is not intended for general use. Following the original definition, there is no expectation of a stable ABI - of course, as discussed in http://lwn.net/Articles/309298/ this is a bit of a pipe dream, but the concept does remain. As it is, we have already removed a couple of commands, and will likely remove more in the near future as more features are exposed in ethtool and other more standard tools.
The other mitigating factors in my mind are that (a) this is still a very new device, only been in customer hands for a short time, and (b) this particular command is painfully obtuse. Probably not many have figured out that it is there or how to use it, and the input specs were inconsistent (note the %hd at the end of the second sscanf()). This patch gives the UI more consistency with standard UI concepts for the aspect of least-surprise, eg forces express base-16 and base-8 format, and it gets this fix in before others likely have run into it.
sln
^ permalink raw reply
* Re: qstats update in packet scheduling
From: Eric Dumazet @ 2014-11-24 17:31 UTC (permalink / raw)
To: Josh Clark; +Cc: netdev
In-Reply-To: <CAHmvzZQnBJbx3hfdvpXg0TZM-UooKxjM+-1HO6nSSpx4qJLcaw@mail.gmail.com>
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.
^ permalink raw reply
* Re: [PATCH] mdio-mux-gpio: Use GPIO descriptor interface and new gpiod_set_array function
From: David Miller @ 2014-11-24 18:06 UTC (permalink / raw)
To: imr; +Cc: f.fainelli, netdev, david.daney, linux-gpio, linus.walleij,
acourbot
In-Reply-To: <1671914.Rot4bT9ZsP@pcimr>
From: Rojhalat Ibrahim <imr@rtschenk.de>
Date: Mon, 24 Nov 2014 09:35:02 +0100
> On Friday 21 November 2014 15:13:01 David Miller wrote:
>> From: Rojhalat Ibrahim <imr@rtschenk.de>
>> Date: Thu, 20 Nov 2014 13:24:44 +0100
>>
>> > Convert mdio-mux-gpio to the GPIO descriptor interface and use the new
>> > gpiod_set_array function to set all output signals simultaneously.
>> >
>> > Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de>
>> > --
>> > This patch depends on the gpiod_set_array function, which is available in
>> > the linux-gpio devel tree.
>>
>> Then I really can't apply it to the networking GIT tree.
>>
>
> Then maybe you could ack the patch and then Linus Walleij could apply it to
> the GPIO tree, right?
Yep, I can do that:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: GRE with GRO very slow when forwarding starting with 3.14.24
From: Tom Herbert @ 2014-11-24 18:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Wolfgang Walter, Linux Netdev List, Alexander Duyck
In-Reply-To: <1416847696.17888.64.camel@edumazet-glaptop2.roam.corp.google.com>
On Mon, Nov 24, 2014 at 8:48 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> On Mon, 2014-11-24 at 17:13 +0100, Wolfgang Walter wrote:
> > Hello,
> >
> > starting with 3.14.24 GRE with GRO on is very slow. To be more specific:
> >
> > yyyy <--> GRO_endpoint <-_> .... <--> |eth0<->GRO-endpoint | eth1 |<-> xxxx
> >
> > routing (IPv4) between xxxx and yyyy is very slow when GRO is enabled on eth0
> > and/or eth1 starting with stable kernel 3.14.24
> >
> > Regards,
>
>
> tcpdump might help, but I presume GSO is no longer working properly on
> egress.
>
Inner mac header is probably not being set in GRO->GSO GRE path.
Please try this also:
diff --git a/net/ipv4/gre_offload.c b/net/ipv4/gre_offload.c
index bb5947b..51973dd 100644
--- a/net/ipv4/gre_offload.c
+++ b/net/ipv4/gre_offload.c
@@ -247,6 +247,9 @@ static int gre_gro_complete(struct sk_buff *skb, int nhoff)
err = ptype->callbacks.gro_complete(skb, nhoff + grehlen);
rcu_read_unlock();
+
+ skb_set_inner_mac_header(skb, nhoff + grehlen);
+
return err;
}
> Can you try to revert :
>
> commit abe640984aa492652232b65d3579361cf6d461f5
> Author: Tom Herbert <therbert@google.com>
> Date: Thu Oct 30 08:40:56 2014 -0700
>
> gre: Use inner mac length when computing tunnel length
>
> [ Upstream commit 14051f0452a2c26a3f4791e6ad6a435e8f1945ff ]
>
> Currently, skb_inner_network_header is used but this does not account
> for Ethernet header for ETH_P_TEB. Use skb_inner_mac_header which
> handles TEB and also should work with IP encapsulation in which case
> inner mac and inner network headers are the same.
>
> Tested: Ran TCP_STREAM over GRE, worked as expected.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> Acked-by: Alexander Duyck <alexander.h.duyck@redhat.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> diff --git a/net/ipv4/gre_offload.c b/net/ipv4/gre_offload.c
> index 2d24f293f977..8c8493ea6b1c 100644
> --- a/net/ipv4/gre_offload.c
> +++ b/net/ipv4/gre_offload.c
> @@ -50,7 +50,7 @@ static struct sk_buff *gre_gso_segment(struct sk_buff *skb,
>
> greh = (struct gre_base_hdr *)skb_transport_header(skb);
>
> - ghl = skb_inner_network_header(skb) - skb_transport_header(skb);
> + ghl = skb_inner_mac_header(skb) - skb_transport_header(skb);
> if (unlikely(ghl < sizeof(*greh)))
> goto out;
>
>
^ permalink raw reply related
* 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
* [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
* [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-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 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 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 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 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
* 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
* 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: 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-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: [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
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