* Re: [RFC] GRO scalability
From: Eric Dumazet @ 2012-10-08 18:28 UTC (permalink / raw)
To: Rick Jones; +Cc: Herbert Xu, David Miller, netdev, Jesse Gross
In-Reply-To: <5073199F.6040408@hp.com>
On Mon, 2012-10-08 at 11:21 -0700, Rick Jones wrote:
> Did I then mis-interpret:
>
> > 2) Use a LRU list to eventually be able to 'flush' too old packets,
> > even if the napi never completes. Each time we process a new packet,
> > being a GRO candidate or not, we increment a napi->sequence, and we
> > flush the oldest packet in gro_lru_list if its own sequence is too
> > old.
>
> in your initial RFC email? Because I took that as flushing a given
> packet if N packets have come through since that packet was queued to
> await coalescing.
Yes, this was refined in the patch I sent.
Currently using jiffies, but my plan is trying to use get_cycles() or
ktime_get(), after some experiments, allowing cycles/ns resolution.
(One ktime_get() per napi batch seems OK)
^ permalink raw reply
* [PATCH v2] skge: Add DMA mask quirk for Marvell 88E8001 on ASUS P5NSLI motherboard
From: Jan Ceuleers @ 2012-10-08 18:34 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Graham Gower, Stephen Hemminger
In-Reply-To: <1349715275-12730-1-git-send-email-jan.ceuleers@computer.org>
From: Graham Gower <graham.gower@gmail.com>
Marvell 88E8001 on an ASUS P5NSLI motherboard is unable to send/receive
packets on a system with >4gb ram unless a 32bit DMA mask is used.
This issue has been around for years and a fix was sent 3.5 years ago, but
there was some debate as to whether it should instead be fixed as a PCI quirk.
http://www.spinics.net/lists/netdev/msg88670.html
However, 18 months later a similar workaround was introduced for another
chipset exhibiting the same problem.
http://www.spinics.net/lists/netdev/msg142287.html
Signed-off-by: Graham Gower <graham.gower@gmail.com>
Signed-off-by: Jan Ceuleers <jan.ceuleers@computer.org>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
---
I am resubmitting Graham's v4 patch hoping that doing so will avoid further
frustration while still getting this fix into the tree.
I have not tested this; I don't have the hardware. It compiles though.
v2: Fixed whitespace error
drivers/net/ethernet/marvell/skge.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/marvell/skge.c b/drivers/net/ethernet/marvell/skge.c
index 5a30bf8..05b3c83 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -4153,6 +4153,13 @@ static struct dmi_system_id skge_32bit_dma_boards[] = {
DMI_MATCH(DMI_BOARD_NAME, "nForce"),
},
},
+ {
+ .ident = "ASUS P5NSLI",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
+ DMI_MATCH(DMI_BOARD_NAME, "P5NSLI")
+ },
+ },
{}
};
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2] vlan: don't deliver frames for unknown vlans to protocols
From: David Miller @ 2012-10-08 18:42 UTC (permalink / raw)
To: florz; +Cc: kaber, eric.dumazet, netdev, linux-kernel, jpirko
In-Reply-To: <20121008015158.GE25895@florz.florz.dyndns.org>
From: Florian Zumbiehl <florz@florz.de>
Date: Mon, 8 Oct 2012 03:51:58 +0200
> This version completely avoids any new state that could need to be spilled
> to RAM, and instead re-checks existence and non-zeroness of the tag. What
> do you think?
At a high level it looks fine and doesn't have the problems mentioned
earlier.
But I wonder if it breaks things, since you do the assignment so late
we no longer handle the case where the VLAN device's MAC address
matches the packet MAC address and the top-level device's does not.
That's handled by logic in vlan_do_receive() which checks for
PACKET_OTHERHOST.
But you're going to unconditionally set PACKET_OTHERHOST, overriding
any decision that code makes.
This turns out to be a really non-trivial area and it's going to take
some time to get this right and audit the change appropriately.
^ permalink raw reply
* Re: [GIT PULL nf-next] IPVS for 3.7 #2
From: Jesper Dangaard Brouer @ 2012-10-08 18:44 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: David Miller, Simon Horman, lvs-devel, netdev, netfilter-devel,
Wensong Zhang, Julian Anastasov, Hans Schillstrom,
Hans Schillstrom
In-Reply-To: <1348800904-23902-1-git-send-email-horms@verge.net.au>
Hey Pablo,
These changes were intended for 3.7, but just checked you git tree...
and it looks like you didn't pull in Simon's changes, and thus they have
not hit DaveM's tree for the merge window :-(
--Jesper
On Fri, 2012-09-28 at 11:54 +0900, Simon Horman wrote:
> Hi Pablo,
>
> please consider the following enhancements to IPVS for inclusion in 3.7.
>
> ----------------------------------------------------------------
> The following changes since commit 82c93fcc2e1737fede2752520f1bf8f4de6304d8:
>
> x86: bpf_jit_comp: add XOR instruction for BPF JIT (2012-09-24 16:54:35 -0400)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next.git master
>
> for you to fetch changes up to 92eec78d25aee6bbc9bd295f51c022ddfa80cdd9:
>
> ipvs: SIP fragment handling (2012-09-28 11:37:16 +0900)
>
> ----------------------------------------------------------------
> Jesper Dangaard Brouer (7):
> ipvs: Trivial changes, use compressed IPv6 address in output
> ipvs: IPv6 extend ICMPv6 handling for future types
> ipvs: Use config macro IS_ENABLED()
> ipvs: Fix faulty IPv6 extension header handling in IPVS
> ipvs: Complete IPv6 fragment handling for IPVS
> ipvs: API change to avoid rescan of IPv6 exthdr
> ipvs: SIP fragment handling
>
> include/net/ip_vs.h | 194 +++++++++++----
> net/netfilter/ipvs/Kconfig | 7 +-
> net/netfilter/ipvs/ip_vs_conn.c | 15 +-
> net/netfilter/ipvs/ip_vs_core.c | 404 +++++++++++++++++--------------
> net/netfilter/ipvs/ip_vs_dh.c | 2 +-
> net/netfilter/ipvs/ip_vs_lblc.c | 2 +-
> net/netfilter/ipvs/ip_vs_lblcr.c | 2 +-
> net/netfilter/ipvs/ip_vs_pe_sip.c | 18 +-
> net/netfilter/ipvs/ip_vs_proto.c | 6 +-
> net/netfilter/ipvs/ip_vs_proto_ah_esp.c | 9 +-
> net/netfilter/ipvs/ip_vs_proto_sctp.c | 42 ++--
> net/netfilter/ipvs/ip_vs_proto_tcp.c | 40 ++-
> net/netfilter/ipvs/ip_vs_proto_udp.c | 41 ++--
> net/netfilter/ipvs/ip_vs_sched.c | 2 +-
> net/netfilter/ipvs/ip_vs_sh.c | 2 +-
> net/netfilter/ipvs/ip_vs_xmit.c | 73 +++---
> net/netfilter/xt_ipvs.c | 4 +-
> 17 files changed, 501 insertions(+), 362 deletions(-)
^ permalink raw reply
* Re: [PATCH 0/3] ipv4: pmtu fixes
From: David Miller @ 2012-10-08 18:47 UTC (permalink / raw)
To: steffen.klassert; +Cc: netdev
In-Reply-To: <20121008084642.GB15622@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Mon, 8 Oct 2012 10:46:42 +0200
> This patchset fixes some issues that came with the routing cache removal.
>
> 1) IPsec and others (udp, ipvs) may cache output routes, these routes
> need to be invalidated on pmtu events in the same way e.g. tcp socket
> cached routes are invalidated. With this we always invalidate or update
> (if we already use a nh exeption route) the old route on pmtu events.
>
> This has the drawback that we may needlessly invalidate an uncached route,
> but this fixes all the users that cache routes and pmtu events are rare, so
> this should not be a real issue.
>
> 2) We create nh exeptions if a user (e.g. tracepath) tries to do pmtu
> dicsovery with packets bigger than the output device mtu. The device mtu
> is not learned and does not expire, so don't create an exeption route.
>
> 3) We report cached pmtu values to userspace even if they are expired.
> Fix this by checking for expiration before we report.
All applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH] pch_gbe: Fix build error by selecting all the possible dependencies.
From: David Miller @ 2012-10-08 18:48 UTC (permalink / raw)
To: haicheng.lee; +Cc: haicheng.li, linux-kernel, netdev, fengguang.wu
In-Reply-To: <1349695107-19524-1-git-send-email-haicheng.lee@gmail.com>
This didn't make it to any mailing list, so nobody can review it.
^ permalink raw reply
* Re: [PATCH] cxgb4: Address various sparse warnings
From: David Miller @ 2012-10-08 18:48 UTC (permalink / raw)
To: vipul; +Cc: netdev, divy, dm, leedom, felix, jay
In-Reply-To: <1349701183-25093-1-git-send-email-vipul@chelsio.com>
From: Vipul Pandya <vipul@chelsio.com>
Date: Mon, 8 Oct 2012 18:29:43 +0530
> This patch fixes type assignment issues, function definition and symbol
> shadowing which triggered sparse warnings.
>
> Signed-off-by: Jay Hernandez <jay@chelsio.com>
> Signed-off-by: Vipul Pandya <vipul@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] skge: Add DMA mask quirk for Marvell 88E8001 on ASUS P5NSLI motherboard
From: David Miller @ 2012-10-08 18:49 UTC (permalink / raw)
To: jan.ceuleers; +Cc: netdev, graham.gower, shemminger
In-Reply-To: <1349721290-16374-1-git-send-email-jan.ceuleers@computer.org>
From: Jan Ceuleers <jan.ceuleers@computer.org>
Date: Mon, 8 Oct 2012 20:34:50 +0200
> From: Graham Gower <graham.gower@gmail.com>
>
> Marvell 88E8001 on an ASUS P5NSLI motherboard is unable to send/receive
> packets on a system with >4gb ram unless a 32bit DMA mask is used.
>
> This issue has been around for years and a fix was sent 3.5 years ago, but
> there was some debate as to whether it should instead be fixed as a PCI quirk.
> http://www.spinics.net/lists/netdev/msg88670.html
>
> However, 18 months later a similar workaround was introduced for another
> chipset exhibiting the same problem.
> http://www.spinics.net/lists/netdev/msg142287.html
>
> Signed-off-by: Graham Gower <graham.gower@gmail.com>
> Signed-off-by: Jan Ceuleers <jan.ceuleers@computer.org>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] net: gro: selective flush of packets
From: David Miller @ 2012-10-08 18:52 UTC (permalink / raw)
To: eric.dumazet; +Cc: herbert, netdev, jesse, therbert, ycheng
In-Reply-To: <1349546929.21172.1598.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 06 Oct 2012 20:08:49 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Current GRO can hold packets in gro_list for almost unlimited
> time, in case napi->poll() handler consumes its budget over and over.
>
> In this case, napi_complete()/napi_gro_flush() are not called.
>
> Another problem is that gro_list is flushed in non friendly way :
> We scan the list and complete packets in the reverse order.
> (youngest packets first, oldest packets last)
> This defeats priorities that sender could have cooked.
>
> Since GRO currently only store TCP packets, we dont really notice the
> bug because of retransmits, but this behavior can add unexpected
> latencies, particularly on mice flows clamped by elephant flows.
>
> This patch makes sure no packet can stay more than 1 ms in queue, and
> only in stress situations.
>
> It also complete packets in the right order to minimize latencies.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* [RFC] napi: limit GRO latency
From: Stephen Hemminger @ 2012-10-08 18:58 UTC (permalink / raw)
To: Eric Dumazet, David Miller; +Cc: Rick Jones, Herbert Xu, netdev, Jesse Gross
In-Reply-To: <1349719006.21172.3537.camel@edumazet-glaptop>
Limit the latency of pending GRO in NAPI processing to 2*HZ.
When the system is under heavy network load, NAPI will go into
poll mode via soft irq, and only stay in the loop for
two jiffies. If this occurs, process the GRO pending list
to make sure and not delay outstanding TCP frames for too long.
Rearrange the exit path to get rid of unnecessary goto logic.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/core/dev.c 2012-10-08 09:21:27.466049785 -0700
+++ b/net/core/dev.c 2012-10-08 11:56:41.714618745 -0700
@@ -3937,8 +3937,16 @@ static void net_rx_action(struct softirq
* Allow this to run for 2 jiffies since which will allow
* an average latency of 1.5/HZ.
*/
- if (unlikely(budget <= 0 || time_after(jiffies, time_limit)))
- goto softnet_break;
+ if (unlikely(budget <= 0 || time_after(jiffies, time_limit))) {
+ /* Cleanup all pending GRO */
+
+ list_for_each_entry(n, &sd->poll_list, poll_list)
+ napi_gro_flush(n);
+
+ sd->time_squeeze++;
+ __raise_softirq_irqoff(NET_RX_SOFTIRQ);
+ break;
+ }
local_irq_enable();
@@ -3987,7 +3995,6 @@ static void net_rx_action(struct softirq
netpoll_poll_unlock(have);
}
-out:
net_rps_action_and_irq_enable(sd);
#ifdef CONFIG_NET_DMA
@@ -3997,13 +4004,6 @@ out:
*/
dma_issue_pending_all();
#endif
-
- return;
-
-softnet_break:
- sd->time_squeeze++;
- __raise_softirq_irqoff(NET_RX_SOFTIRQ);
- goto out;
}
static gifconf_func_t *gifconf_list[NPROTO];
^ permalink raw reply
* Re: [RFC] napi: limit GRO latency
From: David Miller @ 2012-10-08 19:10 UTC (permalink / raw)
To: shemminger; +Cc: eric.dumazet, rick.jones2, herbert, netdev, jesse
In-Reply-To: <20121008115835.3a3bfed6@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 8 Oct 2012 11:58:35 -0700
> Limit the latency of pending GRO in NAPI processing to 2*HZ.
> When the system is under heavy network load, NAPI will go into
> poll mode via soft irq, and only stay in the loop for
> two jiffies. If this occurs, process the GRO pending list
> to make sure and not delay outstanding TCP frames for too long.
>
> Rearrange the exit path to get rid of unnecessary goto logic.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Did you see Eric's patch I just applied which limits it to 1ms?
^ permalink raw reply
* Re: [RFC] napi: limit GRO latency
From: Stephen Hemminger @ 2012-10-08 19:12 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, rick.jones2, herbert, netdev, jesse
In-Reply-To: <20121008.151035.1665672334154033755.davem@davemloft.net>
On Mon, 08 Oct 2012 15:10:35 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Mon, 8 Oct 2012 11:58:35 -0700
>
> > Limit the latency of pending GRO in NAPI processing to 2*HZ.
> > When the system is under heavy network load, NAPI will go into
> > poll mode via soft irq, and only stay in the loop for
> > two jiffies. If this occurs, process the GRO pending list
> > to make sure and not delay outstanding TCP frames for too long.
> >
> > Rearrange the exit path to get rid of unnecessary goto logic.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> Did you see Eric's patch I just applied which limits it to 1ms?
Think this is a different problem.
After leaving softirq, it may be a long time until
ksoftirqd is run which is a different problem.
^ permalink raw reply
* Re: [PATCH net 1/6] ipv4: fix sending of redirects
From: David Miller @ 2012-10-08 19:16 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <1349609168-9848-2-git-send-email-ja@ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Sun, 7 Oct 2012 14:26:03 +0300
> @@ -322,7 +322,8 @@ int fib_validate_source(struct sk_buff *skb, __be32 src, __be32 dst,
> {
> int r = secpath_exists(skb) ? 0 : IN_DEV_RPFILTER(idev);
>
> - if (!r && !fib_num_tclassid_users(dev_net(dev))) {
> + if (!r && !fib_num_tclassid_users(dev_net(dev)) &&
> + dev->ifindex != oif) {
> *itag = 0;
> return 0;
> }
Hmmm, won't this cause the slow path to be taken for locally
destined traffic?
> + rt->rt_gateway ? : ip_hdr(skb)->daddr);
Please use the rt_nexthop() helper.
> + __be32 gw = rt->rt_gateway ? : ip_hdr(skb)->daddr;
Likewise.
^ permalink raw reply
* Re: [PATCH net 3/6] ipv4: add check if nh_pcpu_rth_output is allocated
From: David Miller @ 2012-10-08 19:17 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <1349609168-9848-4-git-send-email-ja@ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Sun, 7 Oct 2012 14:26:05 +0300
> Avoid NULL ptr dereference and caching if
> nh_pcpu_rth_output is not allocated.
>
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
Ugh.
Checking for alloc_percpu() failures in fib_create_info() is 1,000
times better than doing stuff like this in the fast path.
^ permalink raw reply
* Re: [PATCH v2] vlan: don't deliver frames for unknown vlans to protocols
From: Florian Zumbiehl @ 2012-10-08 19:19 UTC (permalink / raw)
To: David Miller; +Cc: kaber, eric.dumazet, netdev, linux-kernel, jpirko
In-Reply-To: <20121008.144230.1404596032615788891.davem@davemloft.net>
Hi,
> But I wonder if it breaks things, since you do the assignment so late
> we no longer handle the case where the VLAN device's MAC address
> matches the packet MAC address and the top-level device's does not.
>
> That's handled by logic in vlan_do_receive() which checks for
> PACKET_OTHERHOST.
>
> But you're going to unconditionally set PACKET_OTHERHOST, overriding
> any decision that code makes.
I don't think that that's actually the case. If vlan_do_receive() reaches
the MAC address check (that is, there is a vlan device for the tag), it
will either clear skb->vlan_tci and return true (which also causes goto
another_round), or return false with a NULL skb, which causes goto out.
The only way to reach the new check without another_round and with a
non-zero tag is the first return false, which happens if there is no device
for the tag, in which case setting PACKET_OTHERHOST should be the right
thing to do (in particular, a non-existent vlan device won't have the
frame's MAC address). I am assuming that rx_handlers don't modify the
frame unless they return RX_HANDLER_ANOTHER.
> This turns out to be a really non-trivial area and it's going to take
> some time to get this right and audit the change appropriately.
I wouldn't want to disagree with that ;-)
Florian
^ permalink raw reply
* [PATCH] net/ethernet/jme: disable ASPM
From: Kevin Baradon @ 2012-10-08 19:02 UTC (permalink / raw)
Cc: Kevin Baradon, Guo-Fu Tseng, Matthew Garrett, netdev
Based on patch from Matthew Garrett <mjg@redhat.com> (https://lkml.org/lkml/2011/11/11/168).
http://driveragent.com/archive/30421/7-0-14 indicates that ASPM is
disabled on the 250 and 260. Duplicate for sanity.
Fixes random RX engine hangs I experienced with JMC250 on Clevo W270HU.
Signed-off-by: Kevin Baradon <kevin.baradon@gmail.com>
Cc: Guo-Fu Tseng <cooldavid@cooldavid.org>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: netdev@vger.kernel.org
---
drivers/net/ethernet/jme.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/jme.c b/drivers/net/ethernet/jme.c
index c911d88..373df5a 100644
--- a/drivers/net/ethernet/jme.c
+++ b/drivers/net/ethernet/jme.c
@@ -27,6 +27,7 @@
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/pci.h>
+#include <linux/pci-aspm.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
#include <linux/ethtool.h>
@@ -2973,6 +2974,9 @@ jme_init_one(struct pci_dev *pdev,
/*
* set up PCI device basics
*/
+ pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1 |
+ PCIE_LINK_STATE_CLKPM);
+
rc = pci_enable_device(pdev);
if (rc) {
pr_err("Cannot enable PCI device\n");
--
1.7.10.4
^ permalink raw reply related
* Re: [RFC] napi: limit GRO latency
From: Eric Dumazet @ 2012-10-08 19:21 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Miller, Rick Jones, Herbert Xu, netdev, Jesse Gross
In-Reply-To: <20121008115835.3a3bfed6@nehalam.linuxnetplumber.net>
On Mon, 2012-10-08 at 11:58 -0700, Stephen Hemminger wrote:
> Limit the latency of pending GRO in NAPI processing to 2*HZ.
> When the system is under heavy network load, NAPI will go into
> poll mode via soft irq, and only stay in the loop for
> two jiffies. If this occurs, process the GRO pending list
> to make sure and not delay outstanding TCP frames for too long.
>
> Rearrange the exit path to get rid of unnecessary goto logic.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
>
> --- a/net/core/dev.c 2012-10-08 09:21:27.466049785 -0700
> +++ b/net/core/dev.c 2012-10-08 11:56:41.714618745 -0700
> @@ -3937,8 +3937,16 @@ static void net_rx_action(struct softirq
> * Allow this to run for 2 jiffies since which will allow
> * an average latency of 1.5/HZ.
> */
> - if (unlikely(budget <= 0 || time_after(jiffies, time_limit)))
> - goto softnet_break;
> + if (unlikely(budget <= 0 || time_after(jiffies, time_limit))) {
> + /* Cleanup all pending GRO */
> +
> + list_for_each_entry(n, &sd->poll_list, poll_list)
> + napi_gro_flush(n);
> +
> + sd->time_squeeze++;
> + __raise_softirq_irqoff(NET_RX_SOFTIRQ);
> + break;
> + }
>
Hmm, I really dont think its a good idea.
I am working in making GRO storing more packets, so any kind of flushes
like that will completely defeat GRO intent.
^ permalink raw reply
* Re: [PATCH v2] vlan: don't deliver frames for unknown vlans to protocols
From: David Miller @ 2012-10-08 19:22 UTC (permalink / raw)
To: florz; +Cc: kaber, eric.dumazet, netdev, linux-kernel, jpirko
In-Reply-To: <20121008191944.GD25288@florz.florz.dyndns.org>
From: Florian Zumbiehl <florz@florz.de>
Date: Mon, 8 Oct 2012 21:19:44 +0200
> The only way to reach the new check without another_round and with a
> non-zero tag is the first return false, which happens if there is no device
> for the tag, in which case setting PACKET_OTHERHOST should be the right
> thing to do (in particular, a non-existent vlan device won't have the
> frame's MAC address). I am assuming that rx_handlers don't modify the
> frame unless they return RX_HANDLER_ANOTHER.
Indeed, you're right.
Patch applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] net/ethernet/jme: disable ASPM
From: David Miller @ 2012-10-08 19:24 UTC (permalink / raw)
To: kevin.baradon; +Cc: cooldavid, mjg, netdev
In-Reply-To: <1349722956-14159-1-git-send-email-kevin.baradon@gmail.com>
From: Kevin Baradon <kevin.baradon@gmail.com>
Date: Mon, 8 Oct 2012 21:02:36 +0200
> Based on patch from Matthew Garrett <mjg@redhat.com> (https://lkml.org/lkml/2011/11/11/168).
>
> http://driveragent.com/archive/30421/7-0-14 indicates that ASPM is
> disabled on the 250 and 260. Duplicate for sanity.
>
> Fixes random RX engine hangs I experienced with JMC250 on Clevo W270HU.
>
> Signed-off-by: Kevin Baradon <kevin.baradon@gmail.com>
This should be a PCI quirk shouldn't it?
Also:
> + pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1 |
> + PCIE_LINK_STATE_CLKPM);
This is terrible formatting, you must line up the "PCIE_LINK_STATE_CLKPM" on
the second line with the very first column after the openning parenthesis
on the first line.
^ permalink raw reply
* Re: [RFC] napi: limit GRO latency
From: Eric Dumazet @ 2012-10-08 19:30 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, rick.jones2, herbert, netdev, jesse
In-Reply-To: <20121008121248.783e6dc4@nehalam.linuxnetplumber.net>
On Mon, 2012-10-08 at 12:12 -0700, Stephen Hemminger wrote:
> On Mon, 08 Oct 2012 15:10:35 -0400 (EDT)
> David Miller <davem@davemloft.net> wrote:
>
> > From: Stephen Hemminger <shemminger@vyatta.com>
> > Date: Mon, 8 Oct 2012 11:58:35 -0700
> >
> > > Limit the latency of pending GRO in NAPI processing to 2*HZ.
> > > When the system is under heavy network load, NAPI will go into
> > > poll mode via soft irq, and only stay in the loop for
> > > two jiffies. If this occurs, process the GRO pending list
> > > to make sure and not delay outstanding TCP frames for too long.
> > >
> > > Rearrange the exit path to get rid of unnecessary goto logic.
> > >
> > > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >
> > Did you see Eric's patch I just applied which limits it to 1ms?
>
> Think this is a different problem.
> After leaving softirq, it may be a long time until
> ksoftirqd is run which is a different problem.
System is under stress, you dont want to increase load at this point,
but increase bandwidth.
Really try this on a 40Gbe link and see how bad it is.
On a server, we probably dedicate one or several cpus only to run NAPI,
so yes we hit net_rx_action() break, but we'll reenter it a few us
later.
^ permalink raw reply
* Re: [PATCH] net/ethernet/jme: disable ASPM
From: Matthew Garrett @ 2012-10-08 19:33 UTC (permalink / raw)
To: David Miller; +Cc: kevin.baradon, cooldavid, netdev
In-Reply-To: <20121008.152426.1524908667081347879.davem@davemloft.net>
On Mon, Oct 08, 2012 at 03:24:26PM -0400, David Miller wrote:
> This should be a PCI quirk shouldn't it?
No, it's a driver-level policy decision.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* [PATCH] ipv6: gro: fix PV6_GRO_CB(skb)->proto problem
From: Eric Dumazet @ 2012-10-08 19:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Herbert Xu
From: Eric Dumazet <edumazet@google.com>
It seems IPV6_GRO_CB(skb)->proto can be destroyed in skb_gro_receive()
if a new skb is allocated (to serve as an anchor for frag_list)
We copy NAPI_GRO_CB() only (not the IPV6 specific part) in :
*NAPI_GRO_CB(nskb) = *NAPI_GRO_CB(p);
So we leave IPV6_GRO_CB(nskb)->proto to 0 (fresh skb allocation) instead
of IPPROTO_TCP (6)
ipv6_gro_complete() isnt able to call ops->gro_complete()
[ tcp6_gro_complete() ]
Fix this by moving proto in NAPI_GRO_CB() and getting rid of
IPV6_GRO_CB
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
---
include/linux/netdevice.h | 3 +++
net/ipv6/af_inet6.c | 11 ++---------
2 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 0a36fff..4b9035c 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1513,6 +1513,9 @@ struct napi_gro_cb {
/* jiffies when first packet was created/queued */
unsigned long age;
+
+ /* Used in ipv6_gro_receive() */
+ int proto;
};
#define NAPI_GRO_CB(skb) ((struct napi_gro_cb *)(skb)->cb)
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index f757e3b..a974247 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -822,13 +822,6 @@ out:
return segs;
}
-struct ipv6_gro_cb {
- struct napi_gro_cb napi;
- int proto;
-};
-
-#define IPV6_GRO_CB(skb) ((struct ipv6_gro_cb *)(skb)->cb)
-
static struct sk_buff **ipv6_gro_receive(struct sk_buff **head,
struct sk_buff *skb)
{
@@ -874,7 +867,7 @@ static struct sk_buff **ipv6_gro_receive(struct sk_buff **head,
iph = ipv6_hdr(skb);
}
- IPV6_GRO_CB(skb)->proto = proto;
+ NAPI_GRO_CB(skb)->proto = proto;
flush--;
nlen = skb_network_header_len(skb);
@@ -930,7 +923,7 @@ static int ipv6_gro_complete(struct sk_buff *skb)
sizeof(*iph));
rcu_read_lock();
- ops = rcu_dereference(inet6_protos[IPV6_GRO_CB(skb)->proto]);
+ ops = rcu_dereference(inet6_protos[NAPI_GRO_CB(skb)->proto]);
if (WARN_ON(!ops || !ops->gro_complete))
goto out_unlock;
^ permalink raw reply related
* Re: [PATCH] net/ethernet/jme: disable ASPM
From: David Miller @ 2012-10-08 19:39 UTC (permalink / raw)
To: mjg59; +Cc: kevin.baradon, cooldavid, netdev
In-Reply-To: <20121008193316.GA13684@srcf.ucam.org>
From: Matthew Garrett <mjg59@srcf.ucam.org>
Date: Mon, 8 Oct 2012 20:33:16 +0100
> On Mon, Oct 08, 2012 at 03:24:26PM -0400, David Miller wrote:
>
>> This should be a PCI quirk shouldn't it?
>
> No, it's a driver-level policy decision.
Then at a bare minimum this change should be using one of the ASPM
helpers provided by drivers/pci/pcie/aspm.c such as
pci_disable_link_state().
^ permalink raw reply
* Re: [RFC] napi: limit GRO latency
From: Stephen Hemminger @ 2012-10-08 19:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, rick.jones2, herbert, netdev, jesse
In-Reply-To: <1349724612.21172.3643.camel@edumazet-glaptop>
On Mon, 08 Oct 2012 21:30:12 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> System is under stress, you dont want to increase load at this point,
> but increase bandwidth.
>
> Really try this on a 40Gbe link and see how bad it is.
Not everybody has 40Gbe hardware just lying around available for testing :-)
^ permalink raw reply
* Re: [PATCH] ipv6: gro: fix PV6_GRO_CB(skb)->proto problem
From: David Miller @ 2012-10-08 19:41 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, herbert
In-Reply-To: <1349725130.21172.3663.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 08 Oct 2012 21:38:50 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> It seems IPV6_GRO_CB(skb)->proto can be destroyed in skb_gro_receive()
> if a new skb is allocated (to serve as an anchor for frag_list)
>
> We copy NAPI_GRO_CB() only (not the IPV6 specific part) in :
>
> *NAPI_GRO_CB(nskb) = *NAPI_GRO_CB(p);
>
> So we leave IPV6_GRO_CB(nskb)->proto to 0 (fresh skb allocation) instead
> of IPPROTO_TCP (6)
>
> ipv6_gro_complete() isnt able to call ops->gro_complete()
> [ tcp6_gro_complete() ]
>
> Fix this by moving proto in NAPI_GRO_CB() and getting rid of
> IPV6_GRO_CB
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
Applied and queued up for -stable, thanks Eric.
^ 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