* Re: [PATCH net_test_tools] route_bench: Fix bug in DST_ITERATE option
From: David Miller @ 2014-11-24 21:09 UTC (permalink / raw)
To: subramanian.vijay; +Cc: netdev
In-Reply-To: <1416816819-17310-1-git-send-email-subramanian.vijay@gmail.com>
From: Vijay Subramanian <subramanian.vijay@gmail.com>
Date: Mon, 24 Nov 2014 00:13:39 -0800
> While setting option for dst_addr_stride, flags should be set for
> FLAG_DST_ITERATE not FLAG_SRC_ITERATE.
>
> Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
This does not apply to the 'net' tree.
^ permalink raw reply
* Re: [PATCH v2] Add support of Cavium Liquidio ethernet adapters
From: David Miller @ 2014-11-24 21:08 UTC (permalink / raw)
To: f.fainelli
Cc: rvatsavayi, netdev, derek.chickles, satananda.burla,
felix.manlunas, raghu.vatsavayi
In-Reply-To: <54739C92.5070309@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 24 Nov 2014 13:01:06 -0800
> On 11/23/2014 07:19 PM, Raghu Vatsavayi wrote:
>> +if LIQUIDIO
>> +
>> +config LIQUIDIO_NAPI
>> + bool "Enable NAPI for LiquidIO"
>> + default y
>> + ---help---
>> + NAPI is a new driver API designed to reduce CPU and interrupt load
>> + when the driver is receiving lots of packets from the card. You
>> + would only disable this feature in very specific instances, like
>> + an application that very rapidly sets up and tears down connections.
>> +
>> + If in doubt, say Y.
>
> You probably do not want to offer a non-NAPI variant, pretty much all
> drivers have NAPI built-in now.
+1.
>> +config LIQUIDIO_DEBUG
>> + int "Debug level for LiquidIO"
>> + range 0 4
>> + default 0
>
> This should be moved to dynamic_debug/ethtools' msglvl control knob.
+1
^ permalink raw reply
* Re: [PATCH 00/17] netfilter/ipvs updates for net-next
From: David Miller @ 2014-11-24 21:01 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1416835674-11871-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 24 Nov 2014 14:27:37 +0100
> The following patchset contains Netfilter updates for your net-next
> tree, this includes the NAT redirection support for nf_tables, the
> cgroup support for nft meta and conntrack zone support for the connlimit
> match. Coming after those, a bunch of sparse warning fixes, missing
> netns bits and cleanups. More specifically, they are:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
Pulled, thanks Pablo.
^ permalink raw reply
* Re: [PATCH v2] Add support of Cavium Liquidio ethernet adapters
From: Florian Fainelli @ 2014-11-24 21:01 UTC (permalink / raw)
To: Raghu Vatsavayi, davem
Cc: netdev, Derek Chickles, Satanand Burla, Felix Manlunas,
Raghu Vatsavayi
In-Reply-To: <1416799190-23789-1-git-send-email-rvatsavayi@caviumnetworks.com>
On 11/23/2014 07:19 PM, Raghu Vatsavayi wrote:
> +if LIQUIDIO
> +
> +config LIQUIDIO_NAPI
> + bool "Enable NAPI for LiquidIO"
> + default y
> + ---help---
> + NAPI is a new driver API designed to reduce CPU and interrupt load
> + when the driver is receiving lots of packets from the card. You
> + would only disable this feature in very specific instances, like
> + an application that very rapidly sets up and tears down connections.
> +
> + If in doubt, say Y.
You probably do not want to offer a non-NAPI variant, pretty much all
drivers have NAPI built-in now.
> +
> +config LIQUIDIO_DEBUG
> + int "Debug level for LiquidIO"
> + range 0 4
> + default 0
> + ---help---
> + Enables more extensive debug output. This may negatively
> + affect performance, so use values > 0 with caution.
> + 0 disables extra debug
> + 1 enables general messages
> + 2 enables register access messages
> + 3 enables debug messages
> + 4 enables flow messages
> +
> + If in doubt, say 0.
This should be moved to dynamic_debug/ethtools' msglvl control knob.
--
Florian
^ permalink raw reply
* Re: [PATCH v2] Add support of Cavium Liquidio ethernet adapters
From: Daniel Borkmann @ 2014-11-24 20:52 UTC (permalink / raw)
To: Raghu Vatsavayi
Cc: davem, netdev, Derek Chickles, Satanand Burla, Felix Manlunas,
Raghu Vatsavayi
In-Reply-To: <1416799190-23789-1-git-send-email-rvatsavayi@caviumnetworks.com>
On 11/24/2014 04:19 AM, Raghu Vatsavayi wrote:
> Following patch adds support for Cavium Liquidio ethernet adapter.
> LiquidIO adapters are pci express based 10Gig server adapters.
>
> Signed-off-by: Derek Chickles <derek.chickles@caviumnetworks.com>
> Signed-off-by: Satanand Burla <satananda.burla@caviumnetworks.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@caviumnetworks.com>
> Signed-off-by: Raghu Vatsavayi <raghu.vatsavayi@caviumnetworks.com>
Please implement BQL in your 10G driver.
Additionally, you might want to consider xmit_more on top of BQL.
If you don't know what BQL is, have a look at the intro here:
http://lwn.net/Articles/454390/
^ permalink raw reply
* Re: [RFC PATCH 0/4] switch device: offload policy attributes
From: Scott Feldman @ 2014-11-24 20:48 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jiří Pírko, Jamal Hadi Salim, Benjamin LaHaise,
Thomas Graf, john.fastabend, stephen, John Linville, nhorman,
Nicolas Dichtel, vyasevic, Florian Fainelli, buytenh, Aviad Raveh,
Netdev, David S. Miller, shrijeet, Andy Gospodarek
In-Reply-To: <547346EB.7060302@cumulusnetworks.com>
On Mon, Nov 24, 2014 at 4:55 AM, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
> On 11/24/14, 2:18 AM, Scott Feldman wrote:
>>
>> Hi Roopa,
>>
>> I have a patch pending against Jiri's v2 that's uses existing
>> ndo_bridge_setlink/getlink to push policy settings down to port driver
>> for controlling HW offload. I had to make a few tweaks, but for the
>> most part setlink/getlink already has the master/self semantics so
>> users can set policy flags on bridge's SW version of the port (master)
>> or on the offloaded version of the port (self).
>> I added the new
>> hwmode option "swdev" to the existing "vepa"|"veb" choices. When you
>> specify hwmode, SELF is set and the port driver's setlink get's
>> called. Did you look at setlink/getlink? It looks like the kernel
>> and iproute2 where going down this route of using setlink/getlink for
>> SELF policy, so I'm wondering if we need more?
>
> If i understand you correctly, this will mean the port driver implements the
> setlink/getlink with the bridge port flags and attributes. And, it also
> means
> the port driver will parse the netlink msg instead of the bridge driver
> parsing all attributes and then calling offloads.
Yes, exactly, the port driver parses/fills bridge_setlink/getlink
netlink msg to set/get port settings. It's basically a passthru for
rtnl_bridge_setlink/getlink handling RTM_GETLNK/RTM_SETLINK on
PF_BRIDGE.
> But, in cases where we want bridge port flags and attributes set both in hw
> and sw,
> the user (iproute2) will have to set both MASTER and SELF flags, and the
> netlink parsing will now happen in two places, the bridge driver and the
> bridge port
> driver ?
Yes, that's correct. That seems to be the intent of the current
design based on the existing code. I had to do minor changes to get
brport flags passed back up in getlink, but for the most part the
kernel code and iproute2 code where already setup to support this dual
master/self model. As an example, let's consider the flags
IFLA_BRPORT_LEARNING. User can set learning on/off on bridge's port
(master) and can independently set learning on/off on port driver
(self) in HW. So for typical swdev setups, the port driver would
default to learning ON and the bridge would default to learning ON.
The user would probably want to turn learning OFF on the bridge, but
all combinations of ON/OFF are available. A better example is
IFLA_BRPORT_FLOOD. If we had a single flag that applied to both
master and self, we'd run into trouble in the flooding ON case. We
don't want both the HW and bridge driver flooding as this would result
in duplicate egress pkts. If we turn flooding OFF, then neither HW or
SW flood and our bridge is broken. So we want SW bridge (master)
flooding OFF and port driver (self) have flooding ON, for the
optimized HW-offload case.
> For bridge stp state updates, the bridge driver will call the ports->setlink
> ndo op ?
No, we added a new ndo op to communicate STP state changes to port
driver. STP state transitions don't really fit into the
setlink/getlink model, although you reminded me there was a request
for a policy flag to turn STP pushes down to port driver ON/OFF.
> (We should probably rename the ndo_bridge_setlink to ndo_setlink)
The name seems correct as they're specific to RTM_GETLNK/SETLNK for PF_BRIDGE.
>>
>> On FDB entries, using master/self semantics that exist, it's clear
>> which are owned by offloaded device and which are owned by bridge.
>> The one missing annotation was a flag indicating FDB entry in bridge
>> was synced from device. And a policy flag to turn on/off syncing from
>> the device. The policy flag is just another IFLA_BRPORT flags passed
>> with setlink/getlink.
>>
>> The setlink/getlink patch will go out in v3 once I finish testing it
>> and push it to Jiri. Hopefully tomorrow.
>
>
> In my patches, I used newlink..., but in most cases all attributes set via
> newlink can be
> used with setlink and hence getlink. So, i think we are close here.
>
> But, Oh wait, i am talking about rtnl_link_ops
> ->newlink/changelink/getlink/dellink. I did not
> realize there was a parallel ndo op to this. But thats probably because,
> rtnl_link_ops can be
> used only for logical devices. But, i see bridge driver implementing both
> the
> rtnl_link_ops changelink and ndo op setlink. hmm..seems like a lot of
> duplication.
> Will look closely some more.
>
>
> Coming back to my series, i was trying to get a common set of flags for all
> netdevs
> (bridge, bond, vxlans so far), and hence the common flag in 'struct
> ifiinfomsg'.
>
> But, I am all for using existing infrastructure if it fits well.
Jiri updated his net-next-rocker tree with my latest but hasn't pushed
out v3 yet. You can see for bridging at least we now have the policy
flag support for master/self without much heavy lifting in kernel or
iproute2 code. It seems like the right move at this time, with low
chance of regressions or breaking backward compat.
> For the fdb offloads, the NTF_SELF and NTF_MASTER is in 'struct
> ndmsg->ndm_flags', which is also
> what i was proposing. So, ack there.
Ya, for FDB, the master/self model works slick and support is already
there so we should use it.
> For the bridge netdev, using the flag in IFLA_BRIDGE_FLAGS, is also ok.
Agreed.
> I will look at your patches when they are out.
v3 is imminent. You can pull net-next-rocker now to look it over.
-scott
^ permalink raw reply
* Re: [PATCH net-next v4] ipvlan: Initial check-in of the IPVLAN driver.
From: David Miller @ 2014-11-24 20:29 UTC (permalink / raw)
To: maheshb; +Cc: netdev, edumazet, maze, chavey, thockin, brandon.philips, xemul
In-Reply-To: <1416812866-13401-1-git-send-email-maheshb@google.com>
From: Mahesh Bandewar <maheshb@google.com>
Date: Sun, 23 Nov 2014 23:07:46 -0800
> This driver is very similar to the macvlan driver except that it
> uses L3 on the frame to determine the logical interface while
> functioning as packet dispatcher. It inherits L2 of the master
> device hence the packets on wire will have the same L2 for all
> the packets originating from all virtual devices off of the same
> master device.
>
> This driver was developed keeping the namespace use-case in
> mind. Hence most of the examples given here take that as the
> base setup where main-device belongs to the default-ns and
> virtual devices are assigned to the additional namespaces.
...
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 26/41] vhost: virtio 1.0 endian-ness support
From: Michael S. Tsirkin @ 2014-11-24 20:28 UTC (permalink / raw)
To: Cedric Le Goater
Cc: kvm, rusty, netdev, linux-kernel, virtualization, pbonzini,
David Miller
In-Reply-To: <5473408A.2090308@fr.ibm.com>
On Mon, Nov 24, 2014 at 03:28:26PM +0100, Cedric Le Goater wrote:
> Hi Michael,
>
> Do you have a tree from where I could pull these patches ?
>
> Thanks,
>
> C.
Yes - vhost-next that linux-next includes.
--
MST
^ permalink raw reply
* Re: [PATCH] 8139too: The maximum MTU should allow for VLAN headers
From: David Miller @ 2014-11-24 20:27 UTC (permalink / raw)
To: albeu; +Cc: netdev, ben, ebiederm, bhelgaas, benoit.taine, linux-kernel
In-Reply-To: <1416744476-7372-1-git-send-email-albeu@free.fr>
From: Alban Bedel <albeu@free.fr>
Date: Sun, 23 Nov 2014 13:07:54 +0100
> As pointed out by Ben Hutchings drivers that allow using VLAN have to
> provide enough headroom for the VLAN tags.
>
> Signed-off-by: Alban Bedel <albeu@free.fr>
Applied to net-next, but I shouldn't have to guess around about what
tree your patch is for.
In the future you must specify explicitly what tree your patch is
targetted at by saying either "[PATCH net] " or "[PATCH net-next] "
in your subject line.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: fec: init maximum receive buffer size for ring1 and ring2
From: David Miller @ 2014-11-24 20:22 UTC (permalink / raw)
To: b38611; +Cc: netdev, bhutchings, stephen, festevam
In-Reply-To: <1416734586-26634-1-git-send-email-b38611@freescale.com>
From: Fugang Duan <b38611@freescale.com>
Date: Sun, 23 Nov 2014 17:23:06 +0800
> i.MX6SX fec support three rx ring1, the current driver lost to init
> ring1 and ring2 maximum receive buffer size, that cause receving
> frame date length error. The driver reports "rcv is not +last" error
> log in user case.
>
> Signed-off-by: Fugang Duan <B38611@freescale.com>
This patch does not apply to the 'net' tree, although it does
apply cleanly to the net-next tree.
Determining which tree a patch is for is not my job, it is your's.
Therefore you must always explicitly state what tree your patch
is intended to be added to, by starting your Subject line
with "[PATCH net] " or "[PATCH net-next] ".
I've applied this, but next time I will just ask you to properly
submit the patch instead.
^ permalink raw reply
* Re: [fuse-devel] [PATCH 4/6] fs/fuse: support compiling out splice
From: Greg KH @ 2014-11-24 20:22 UTC (permalink / raw)
To: josh
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: <20141124201450.GA18776@cloud>
On Mon, Nov 24, 2014 at 12:14:50PM -0800, josh@joshtriplett.org wrote:
> > 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.
Yes, I would prefer that, but I'm not the fuse maintainer.
thanks,
greg k-h
^ permalink raw reply
* Re: qstats update in packet scheduling
From: Eric Dumazet @ 2014-11-24 20:21 UTC (permalink / raw)
To: Josh Clark; +Cc: Dave Taht, netdev
In-Reply-To: <CAHmvzZTF76DwdyBF9og2v9Vumx5v0BhHR584uX54o5R+T+iUMw@mail.gmail.com>
On Mon, 2014-11-24 at 14:14 -0500, Josh Clark wrote:
> At the moment, I'm using standard RED (from /net/sched/sch_red.c) with
> some printks to output qstats.
printk are slowing down the kernel and might interfere with normal
behavior. Don't use them.
> Are you saying that when I set this up, I need to use the -s flag in
> tc to maintain those statistics?
stats are maintained by the kernel no matter what.
tc -s qdisc actually display them.
For instance, red_dump() copies the backlog from child qdisc.
static int red_dump(struct Qdisc *sch, struct sk_buff *skb)
{
...
sch->qstats.backlog = q->qdisc->qstats.backlog;
...
}
This backlog is probably not 0 !
^ permalink raw reply
* Re: qstats update in packet scheduling
From: Eric Dumazet @ 2014-11-24 20:20 UTC (permalink / raw)
To: Dave Taht; +Cc: Josh Clark, netdev
In-Reply-To: <CAA93jw4URTCK_O5mrJB14qAraubqj4Y-pvWMFX7ts=BWSgd-Og@mail.gmail.com>
On Mon, 2014-11-24 at 11:01 -0800, Dave Taht 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...
Hardly a matter, if you send _steady_ 12Mbit on a 10Mbit link, the
bottleneck should land on RED, BQL or not.
^ permalink raw reply
* 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
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