* RE: 82571EB: Detected Hardware Unit Hang
From: Dave, Tushar N @ 2012-11-08 20:35 UTC (permalink / raw)
To: Joe Jin, e1000-devel@lists.sf.net
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Mary Mcgrath
In-Reply-To: <509B5038.8090304@oracle.com>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>On Behalf Of Joe Jin
>Sent: Wednesday, November 07, 2012 10:25 PM
>To: e1000-devel@lists.sf.net
>Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Mary Mcgrath
>Subject: 82571EB: Detected Hardware Unit Hang
>
>Hi list,
>
>IHAC reported "82571EB Detected Hardware Unit Hang" on HP ProLiant DL360
>G6, and have to reboot the server to recover:
>
>e1000e 0000:06:00.1: eth3: Detected Hardware Unit Hang:
> TDH <1a>
> TDT <1a>
> next_to_use <1a>
> next_to_clean <18>
>buffer_info[next_to_clean]:
> time_stamp <10047a74e>
> next_to_watch <18>
> jiffies <10047a88c>
> next_to_watch.status <1>
>MAC Status <80383>
>PHY Status <792d>
>PHY 1000BASE-T Status <3800>
>PHY Extended Status <3000>
>PCI Status <10>
>
>With newer kernel 2.0.0.1 the issue still reproducible.
>
>Device info:
>06:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
>Controller (Copper) (rev 06)
>06:00.1 0200: 8086:10bc (rev 06)
>
>I compared lspci output before and after the issue, different as below:
> 06:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
>Controller (Copper) (rev 06)
> Subsystem: Hewlett-Packard Company NC364T PCI Express Quad Port
>Gigabit Server Adapter
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
>Stepping- SERR- FastB2B- DisINTx-
>- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
><TAbort- <MAbort- >SERR- <PERR- INTx-
>+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>+<TAbort- <MAbort- >SERR- <PERR- INTx+
Are you sure this is not similar issue as before that you reported.
i.e.
On Mon, 2012-07-09 at 16:51 +0800, Joe Jin wrote:
> I'm seeing a Unit Hang even with the latest e1000e driver 2.0.0 when
> doing scp test. this issue is easy do reproduced on SUN FIRE X2270 M2,
> just copy a big file (>500M) from another server will hit it at once.
All devices in path from root complex to 82571, should have *same* max payload size otherwise it can cause hang.
Can you double check this?
-Tushar
^ permalink raw reply
* Re: question on netdev_completed_queue()
From: Ben Hutchings @ 2012-11-08 20:44 UTC (permalink / raw)
To: Oliver Neukum; +Cc: netdev
In-Reply-To: <1476426.QTHA7ibVHZ@linux-lqwf.site>
On Thu, 2012-11-08 at 20:38 +0100, Oliver Neukum wrote:
> Hi,
>
> is this function to be called whenever a driver is done with transmitting
> data, whether the transmission be successful or not?
Yes, BQL tracks number of packets and bytes in each queue and you have
to tell it about all insertions and removals from the queue. (Except
that if you flush the queue, you can use netdev_reset_queue() rather
than trying to counting the remaining packets and bytes.)
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: essentially offline...
From: Jan Ceuleers @ 2012-11-08 20:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev, netfilter-devel, linux-wireless
In-Reply-To: <20121108.150930.2104308040240146535.davem@davemloft.net>
On 11/08/2012 09:09 PM, David Miller wrote:
> 2) Don't be a jackass and avoid reviewing patches that you can
> actually provide feedback on.
David,
Nobody around here is intentionally being a jackass. Your use of the
word is offensive.
New York does that to people. I know: my wife used to live there for 6
years. She got a lot more sociable afterwards. The forces of nature
currently at work seem to be exacerbating this situation.
My recommendation (not related to any storms): get out of New York. It's
an exhilerating place to be, but it kills the soul.
Jan
^ permalink raw reply
* Re: essentially offline...
From: David Miller @ 2012-11-08 21:01 UTC (permalink / raw)
To: jan.ceuleers; +Cc: netdev, netfilter-devel, linux-wireless
In-Reply-To: <509C1BDD.6000405@computer.org>
From: Jan Ceuleers <jan.ceuleers@computer.org>
Date: Thu, 08 Nov 2012 21:53:49 +0100
> On 11/08/2012 09:09 PM, David Miller wrote:
>> 2) Don't be a jackass and avoid reviewing patches that you can
>> actually provide feedback on.
>
> David,
>
> Nobody around here is intentionally being a jackass. Your use of the
> word is offensive.
I used the work jackass just as frequently before I lived part time
in New York. Try again...
^ permalink raw reply
* Re: [rfc net-next v6 3/3] virtio-net: change the number of queues through ethtool
From: Ben Hutchings @ 2012-11-08 21:13 UTC (permalink / raw)
To: Jason Wang
Cc: krkumar2, kvm, mst, netdev, linux-kernel, virtualization, davem
In-Reply-To: <1351591403-23065-4-git-send-email-jasowang@redhat.com>
On Tue, 2012-10-30 at 18:03 +0800, Jason Wang wrote:
> This patch implement the {set|get}_channels method of ethool to allow user to
> change the number of queues dymaically when the device is running. This would
> let the user to tune the device for specific applications.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/net/virtio_net.c | 43 +++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 43 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 8cc43e5..66fc129 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1616,10 +1616,53 @@ static struct virtio_driver virtio_net_driver = {
> #endif
> };
>
> +/* TODO: Eliminate OOO packets during switching */
> +static int virtnet_set_channels(struct net_device *dev,
> + struct ethtool_channels *channels)
> +{
> + struct virtnet_info *vi = netdev_priv(dev);
> + u16 queue_pairs = channels->combined_count;
> +
> + /* Only two modes were support currently */
> + if (queue_pairs == 0)
> + return -EINVAL;
> + if (queue_pairs != vi->total_queue_pairs - 1 && queue_pairs != 1)
> + return -EINVAL;
You should also check that all of the other counts are == 0.
> + vi->num_queue_pairs = queue_pairs > 1 ? queue_pairs + 1 : 1;
This doesn't make sense. You're setting vi->num_queue_pairs to be
combined_count + 1...
> + BUG_ON(virtnet_set_queues(vi));
> +
> + netif_set_real_num_tx_queues(dev, vi->num_queue_pairs);
> + netif_set_real_num_rx_queues(dev, vi->num_queue_pairs);
> +
> + return 0;
> +}
> +
> +static void virtnet_get_channels(struct net_device *dev,
> + struct ethtool_channels *channels)
> +{
> + struct virtnet_info *vi = netdev_priv(dev);
> +
> + if (vi->total_queue_pairs != 1) {
> + channels->combined_count = vi->num_queue_pairs;
but here you report combined_count as being vi->num_queue_pairs. Do you
need to subtract 1 here?
Ben.
> + channels->max_combined = vi->total_queue_pairs - 1;
> + } else {
> + channels->combined_count = 1;
> + channels->max_combined = 1;
> + }
> +
> + channels->max_other = 0;
> + channels->rx_count = 0;
> + channels->tx_count = 0;
> + channels->other_count = 0;
> +}
> +
> static const struct ethtool_ops virtnet_ethtool_ops = {
> .get_drvinfo = virtnet_get_drvinfo,
> .get_link = ethtool_op_get_link,
> .get_ringparam = virtnet_get_ringparam,
> + .set_channels = virtnet_set_channels,
> + .get_channels = virtnet_get_channels,
> };
>
> static int __init init(void)
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH net-next 1/2] PPC: net: bpf_jit_comp: add XOR instruction for BPF JIT
From: Daniel Borkmann @ 2012-11-08 21:39 UTC (permalink / raw)
To: davem; +Cc: matt, benh, netdev
This patch is a follow-up for patch "filter: add XOR instruction for use
with X/K" that implements BPF PowerPC JIT parts for the BPF XOR operation.
Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
Cc: Matt Evans <matt@ozlabs.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Disclaimer: uncompiled and untested, since I don't have a PPC machine,
but it should (hopefully) integrate cleanly; impl. after PPC instruction
reference.
arch/powerpc/include/asm/ppc-opcode.h | 3 +++
arch/powerpc/net/bpf_jit.h | 6 ++++++
arch/powerpc/net/bpf_jit_comp.c | 11 +++++++++++
3 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
index 5f73ce6..42b1f43 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -168,9 +168,12 @@
#define PPC_INST_AND 0x7c000038
#define PPC_INST_ANDDOT 0x7c000039
#define PPC_INST_OR 0x7c000378
+#define PPC_INST_XOR 0x7c000278
#define PPC_INST_ANDI 0x70000000
#define PPC_INST_ORI 0x60000000
#define PPC_INST_ORIS 0x64000000
+#define PPC_INST_XORI 0x68000000
+#define PPC_INST_XORIS 0x6c000000
#define PPC_INST_NEG 0x7c0000d0
#define PPC_INST_BRANCH 0x48000000
#define PPC_INST_BRANCH_COND 0x40800000
diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
index 1fc8109..8a5dfaf 100644
--- a/arch/powerpc/net/bpf_jit.h
+++ b/arch/powerpc/net/bpf_jit.h
@@ -134,6 +134,12 @@ DECLARE_LOAD_FUNC(sk_load_byte_msh);
___PPC_RS(a) | IMM_L(i))
#define PPC_ORIS(d, a, i) EMIT(PPC_INST_ORIS | ___PPC_RA(d) | \
___PPC_RS(a) | IMM_L(i))
+#define PPC_XOR(d, a, b) EMIT(PPC_INST_XOR | ___PPC_RA(d) | \
+ ___PPC_RS(a) | ___PPC_RB(b))
+#define PPC_XORI(d, a, i) EMIT(PPC_INST_XORI | ___PPC_RA(d) | \
+ ___PPC_RS(a) | IMM_L(i))
+#define PPC_XORIS(d, a, i) EMIT(PPC_INST_XORIS | ___PPC_RA(d) | \
+ ___PPC_RS(a) | IMM_L(i))
#define PPC_SLW(d, a, s) EMIT(PPC_INST_SLW | ___PPC_RA(d) | \
___PPC_RS(a) | ___PPC_RB(s))
#define PPC_SRW(d, a, s) EMIT(PPC_INST_SRW | ___PPC_RA(d) | \
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index dd11306..b9434de 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -232,6 +232,17 @@ static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
if (K >= 65536)
PPC_ORIS(r_A, r_A, IMM_H(K));
break;
+ case BPF_S_ANC_ALU_XOR_X:
+ case BPF_S_ALU_XOR_X: /* A ^= X */
+ ctx->seen |= SEEN_XREG;
+ PPC_XOR(r_A, r_A, r_X);
+ break;
+ case BPF_S_ALU_XOR_K: /* A ^= K */
+ if (IMM_L(K))
+ PPC_XORI(r_A, r_A, IMM_L(K));
+ if (K >= 65536)
+ PPC_XORIS(r_A, r_A, IMM_H(K));
+ break;
case BPF_S_ALU_LSH_X: /* A <<= X; */
ctx->seen |= SEEN_XREG;
PPC_SLW(r_A, r_A, r_X);
^ permalink raw reply related
* [PATCH net-next 2/2] PPC: net: bpf_jit_comp: add VLAN instructions for BPF JIT
From: Daniel Borkmann @ 2012-11-08 21:41 UTC (permalink / raw)
To: davem; +Cc: matt, benh, netdev
This patch is a follow-up for patch "net: filter: add vlan tag access"
to support the new VLAN_TAG/VLAN_TAG_PRESENT accessors in BPF JIT.
Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
Cc: Matt Evans <matt@ozlabs.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Disclaimer: uncompiled and untested, since I don't have a PPC machine,
but it should (hopefully) integrate cleanly; impl. after PPC instruction
reference.
arch/powerpc/net/bpf_jit_comp.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index b9434de..e834f1e 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -13,6 +13,8 @@
#include <asm/cacheflush.h>
#include <linux/netdevice.h>
#include <linux/filter.h>
+#include <linux/if_vlan.h>
+
#include "bpf_jit.h"
#ifndef __BIG_ENDIAN
@@ -89,6 +91,8 @@ static void bpf_jit_build_prologue(struct sk_filter *fp, u32 *image,
case BPF_S_ANC_IFINDEX:
case BPF_S_ANC_MARK:
case BPF_S_ANC_RXHASH:
+ case BPF_S_ANC_VLAN_TAG:
+ case BPF_S_ANC_VLAN_TAG_PRESENT:
case BPF_S_ANC_CPU:
case BPF_S_ANC_QUEUE:
case BPF_S_LD_W_ABS:
@@ -382,6 +386,16 @@ static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
PPC_LWZ_OFFS(r_A, r_skb, offsetof(struct sk_buff,
rxhash));
break;
+ case BPF_S_ANC_VLAN_TAG:
+ case BPF_S_ANC_VLAN_TAG_PRESENT:
+ BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, vlan_tci) != 2);
+ PPC_LHZ_OFFS(r_A, r_skb, offsetof(struct sk_buff,
+ vlan_tci));
+ if (filter[i].code == BPF_S_ANC_VLAN_TAG)
+ PPC_ANDI(r_A, r_A, VLAN_VID_MASK);
+ else
+ PPC_ANDI(r_A, r_A, VLAN_TAG_PRESENT);
+ break;
case BPF_S_ANC_QUEUE:
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff,
queue_mapping) != 2);
^ permalink raw reply related
* linux-next: manual merge of the net-next tree with Linus' tree
From: Stephen Rothwell @ 2012-11-08 23:53 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Merav Sicron, Dmitry Kravkov,
Eilon Greenstein
[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c between commit
477864ddd365 ("bnx2x: Disable FCoE for 57840 since not yet supported by
FW") from Linus' tree and commit 55c11941e382 ("bnx2x: Support loading
cnic resources at run-time") from the net-next tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index bd1fd3d,0546cf4..0000000
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@@ -11899,22 -12065,10 +12066,20 @@@ static int __devinit bnx2x_init_one(str
/* calc qm_cid_count */
bp->qm_cid_count = bnx2x_set_qm_cid_count(bp);
- #ifdef BCM_CNIC
- /* disable FCOE L2 queue for E1x */
+ /* disable FCOE L2 queue for E1x*/
if (CHIP_IS_E1x(bp))
bp->flags |= NO_FCOE_FLAG;
+
+ /* disable FCOE for 57840 device, until FW supports it */
+ switch (ent->driver_data) {
+ case BCM57840_O:
+ case BCM57840_4_10:
+ case BCM57840_2_20:
+ case BCM57840_MFO:
+ case BCM57840_MF:
+ bp->flags |= NO_FCOE_FLAG;
+ }
- #endif
-
+
/* Set bp->num_queues for MSI-X mode*/
bnx2x_set_num_queues(bp);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 net-next] bonding: extend bond_arp_send_all to bridge devices
From: Jay Vosburgh @ 2012-11-09 0:58 UTC (permalink / raw)
To: Chris J Arges; +Cc: Andy Gospodarek, netdev, linux-kernel
In-Reply-To: <1352210205-24558-1-git-send-email-chris.j.arges@canonical.com>
Chris J Arges <chris.j.arges@canonical.com> wrote:
>ARP monitoring does not work when we have a network in the
>following configuration:
>
>eth0----+ +----bond0.100----br0-100---{+virtual machines
> | |
> +----bond0----+----br0---(fixed IP)->--{LAN arp_ip_target}
> | |
>eth1----+ +----bond0.200----br0-200---{+virtual machines
>
>This patch extends bond_arp_send_all to check if a device
>is also in a bridge.
I did some testing with this. The required network
configuration to show the problem is much simpler than this. I tested
with something of the form:
eth0 -> bond0 -> {bond0.123, br0} br0 is 10.0.9.1/16, arp_ip_target is
10.0.1.1
br0 has the only assigned IP address, and the arp_ip_target is
something on that same subnet. In this case, merely having 8021q loaded
would induce the problem, as that would add a VLAN (VID 0) to the bond
even without explicitly adding a VLAN to the bond.
The patch does resolve the immediate problem that with the VLAN,
the bond would not send the ARP queries out via eth0.
However, it misses one corner case, because the new test does
not validate that the bond is actually a port of the bridge that's found
via the route. In this case, a configuration like:
eth0 -> bond0 -> bond0.123 IP address 10.99.0.1/16, arp_ip_target 10.0.1.1
eth1 -> br0 IP address 10.0.9.1/16
would cause the bond to issue the ARP probe request for 10.0.1.1
on eth0, even though it really shouldn't (and currently wouldn't). If,
say, eth0 and eth1 are parallel subnets, it's possible that the host
with 10.0.1.1 (multihomed to both subnets) may answer on the "wrong"
subnet even if regular traffic routed via the correct subnet can't get
through for some reason.
I don't see an easy way to find out if device X is a port of
bridge Y, either, although we can easily check if the bond is a bridge
port (priv_flags & IFF_BRIDGE_PORT) before doing the new check. That
doesn't completely fix the problem, but does require that the bond be a
port of a different bridge to cause a misbehavior.
-J
>This is related to the following issues:
>http://launchpad.net/bugs/736226
>http://bugzilla.kernel.org/show_bug.cgi?id=31822
>
>Thanks to help from Andy Gospodarek <andy@greyhouse.net>.
>
>Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
>---
> drivers/net/bonding/bond_main.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index b2530b0..62931b0 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -2708,6 +2708,14 @@ static void bond_arp_send_all(struct bonding *bond, struct slave *slave)
> continue;
> }
>
>+ /* Check if the target is part of a bridge.
>+ */
>+ if (rt->dst.dev->priv_flags & IFF_EBRIDGE) {
>+ addr = bond_confirm_addr(rt->dst.dev, targets[i], 0);
>+ bond_arp_send(slave->dev, ARPOP_REQUEST, targets[i], addr, 0);
>+ continue;
>+ }
>+
> if (net_ratelimit()) {
> pr_warning("%s: no path to arp_ip_target %pI4 via rt.dev %s\n",
> bond->dev->name, &targets[i],
>--
>1.7.9.5
>
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: 82571EB: Detected Hardware Unit Hang
From: Joe Jin @ 2012-11-09 1:22 UTC (permalink / raw)
To: Dave, Tushar N
Cc: netdev@vger.kernel.org, e1000-devel@lists.sf.net,
linux-kernel@vger.kernel.org, Mary Mcgrath
In-Reply-To: <061C8A8601E8EE4CA8D8FD6990CEA89133487884@ORSMSX102.amr.corp.intel.com>
On 11/09/12 04:35, Dave, Tushar N wrote:
> Are you sure this is not similar issue as before that you reported.
> i.e.
Tushar,
Thanks for your quick response, I'll check with customer if they can modify the Max
payload size from BIOS, this time issue hit on HP's server.
Thanks again,
Joe
> On Mon, 2012-07-09 at 16:51 +0800, Joe Jin wrote:
>> > I'm seeing a Unit Hang even with the latest e1000e driver 2.0.0 when
>> > doing scp test. this issue is easy do reproduced on SUN FIRE X2270 M2,
>> > just copy a big file (>500M) from another server will hit it at once.
> All devices in path from root complex to 82571, should have *same* max payload size otherwise it can cause hang.
> Can you double check this?
>
--
Oracle <http://www.oracle.com>
Joe Jin | Software Development Senior Manager | +8610.6106.5624
ORACLE | Linux and Virtualization
No. 24 Zhongguancun Software Park, Haidian District | 100193 Beijing
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
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: [PATCH 4/9] net: openvswitch: use this_cpu_ptr per-cpu helper
From: Shan Wei @ 2012-11-09 1:39 UTC (permalink / raw)
To: Christoph Lameter
Cc: dev-yBygre7rU0TnMu66kgdUjQ, NetDev, Kernel-Maillist, David Miller
In-Reply-To: <0000013ae10817d9-c5215352-348f-4898-b618-bb89e8725ab1-000000-p/GC64/jrecnJqMo6gzdpkEOCMrvLtNR@public.gmane.org>
Christoph Lameter said, at 2012/11/9 1:18:
> On Thu, 8 Nov 2012, Shan Wei wrote:
>
>> Christoph Lameter said, at 2012/11/3 1:46:
>>>> u64_stats_update_begin(&stats->sync);
>>>> stats->tx_packets++;
>>>
>>> Use this_cpu_inc(vport->percpu_stats->packets) here?
>>
>> Lots of network drivers use u64_stats_sync infrastructure for statistics
>
> So they would all have an advantage from the patch.
I will try to do the optimizing next time in another patchset which not included
in this series patchset.
I will submit v3 version of this series after testing today.
Thanks
^ permalink raw reply
* [PATCH net-next 0/3 ] tunneling: Add support for hardware-offloaded encapsulation
From: Joseph Gasparakis @ 2012-11-09 2:18 UTC (permalink / raw)
To: davem, shemminger, chrisw; +Cc: Joseph Gasparakis, netdev, linux-kernel
The series contains updates to add in the NIC Rx and Tx checksumming support
for encapsulated packets.
The sk_buff needs to somehow have information of the inner packet, and adding
three fields for the inner mac, network and transport headers was the prefered
approach.
Not adding these fields would mean that the drivers would need to parse the
sk_buff data in hot-path, having a negative impact in the performance.
Adding in sk_buff a pointer to the skbuff of the inner packet made sense, but
would be a complicated change as assumptions needed to be made with regards to
helper functions such as skb_clone() skb_copy(). Also code for the existing
encapsulation protocols (such as VXLAN and IP GRE) had to be reworked, so the
decision was to have the simple approach of adding these three fields.
^ permalink raw reply
* [PATCH 1/3] net: Add support for hardware-offloaded encapsulation
From: Joseph Gasparakis @ 2012-11-09 2:18 UTC (permalink / raw)
To: davem, shemminger, chrisw
Cc: Joseph Gasparakis, netdev, linux-kernel, Peter P Waskiewicz Jr
In-Reply-To: <1352427483-4380-1-git-send-email-joseph.gasparakis@intel.com>
This patch adds support in the kernel for offloading in the NIC Tx and Rx checksumming for encapsulated packets (such as VXLAN and IP GRE)
Signed-off-by: Joseph Gasparakis <joseph.gasparakis@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
---
Documentation/networking/netdev-features.txt | 10 +++
include/linux/if_ether.h | 5 ++
include/linux/ip.h | 5 ++
include/linux/netdev_features.h | 3 +
include/linux/skbuff.h | 114 +++++++++++++++++++++++++++
include/linux/udp.h | 5 ++
net/core/ethtool.c | 2 +
net/core/skbuff.c | 17 ++++
8 files changed, 161 insertions(+)
diff --git a/Documentation/networking/netdev-features.txt b/Documentation/networking/netdev-features.txt
index 4164f5c..82695c0 100644
--- a/Documentation/networking/netdev-features.txt
+++ b/Documentation/networking/netdev-features.txt
@@ -165,3 +165,13 @@ This requests that the NIC receive all possible frames, including errored
frames (such as bad FCS, etc). This can be helpful when sniffing a link with
bad packets on it. Some NICs may receive more packets if also put into normal
PROMISC mdoe.
+
+* tx-enc-checksum-offload
+
+This feature implies that the NIC will be able to calculate the Tx checksums
+for both inner and outer packets in the case of vxlan and ipgre encapsulation.
+
+* rx-enc-checksum-offload
+
+This feature implies that the NIC will be able to verify the Rx checksums
+for both inner and outer packets in the case of vxlan and ipgre encapsulation.
diff --git a/include/linux/if_ether.h b/include/linux/if_ether.h
index 12b4d55..195376b 100644
--- a/include/linux/if_ether.h
+++ b/include/linux/if_ether.h
@@ -28,6 +28,11 @@ static inline struct ethhdr *eth_hdr(const struct sk_buff *skb)
return (struct ethhdr *)skb_mac_header(skb);
}
+static inline struct ethhdr *eth_inner_hdr(const struct sk_buff *skb)
+{
+ return (struct ethhdr *)skb_inner_mac_header(skb);
+}
+
int eth_header_parse(const struct sk_buff *skb, unsigned char *haddr);
int mac_pton(const char *s, u8 *mac);
diff --git a/include/linux/ip.h b/include/linux/ip.h
index 58b82a2..e084de7 100644
--- a/include/linux/ip.h
+++ b/include/linux/ip.h
@@ -25,6 +25,11 @@ static inline struct iphdr *ip_hdr(const struct sk_buff *skb)
return (struct iphdr *)skb_network_header(skb);
}
+static inline struct iphdr *ip_inner_hdr(const struct sk_buff *skb)
+{
+ return (struct iphdr *)skb_inner_network_header(skb);
+}
+
static inline struct iphdr *ipip_hdr(const struct sk_buff *skb)
{
return (struct iphdr *)skb_transport_header(skb);
diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index 5ac3212..6dd59a5 100644
--- a/include/linux/netdev_features.h
+++ b/include/linux/netdev_features.h
@@ -19,6 +19,7 @@ enum {
NETIF_F_IP_CSUM_BIT, /* Can checksum TCP/UDP over IPv4. */
__UNUSED_NETIF_F_1,
NETIF_F_HW_CSUM_BIT, /* Can checksum all the packets. */
+ NETIF_F_HW_CSUM_ENC_BIT, /* Can checksum all inner headers */
NETIF_F_IPV6_CSUM_BIT, /* Can checksum TCP/UDP over IPV6 */
NETIF_F_HIGHDMA_BIT, /* Can DMA to high memory. */
NETIF_F_FRAGLIST_BIT, /* Scatter/gather IO. */
@@ -52,6 +53,8 @@ enum {
NETIF_F_NTUPLE_BIT, /* N-tuple filters supported */
NETIF_F_RXHASH_BIT, /* Receive hashing offload */
NETIF_F_RXCSUM_BIT, /* Receive checksumming offload */
+ NETIF_F_RXCSUM_ENC_BIT, /* Receive checksuming offload */
+ /* for encapsulation */
NETIF_F_NOCACHE_COPY_BIT, /* Use no-cache copyfromuser */
NETIF_F_LOOPBACK_BIT, /* Enable loopback */
NETIF_F_RXFCS_BIT, /* Append FCS to skb pkt data */
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index f2af494..4b9b50b 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -379,6 +379,9 @@ typedef unsigned char *sk_buff_data_t;
* @transport_header: Transport layer header
* @network_header: Network layer header
* @mac_header: Link layer header
+ * @inner_transport_header: Inner transport layer header (encapsulation)
+ * @inner_network_header: Network layer header (encapsulation)
+ * @inner_mac_header: Link layer header (encapsulation)
* @tail: Tail pointer
* @end: End pointer
* @head: Head of buffer
@@ -489,6 +492,9 @@ struct sk_buff {
sk_buff_data_t transport_header;
sk_buff_data_t network_header;
sk_buff_data_t mac_header;
+ sk_buff_data_t inner_transport_header;
+ sk_buff_data_t inner_network_header;
+ sk_buff_data_t inner_mac_header;
/* These elements must be at the end, see alloc_skb() for details. */
sk_buff_data_t tail;
sk_buff_data_t end;
@@ -1441,6 +1447,63 @@ static inline void skb_reset_mac_len(struct sk_buff *skb)
}
#ifdef NET_SKBUFF_DATA_USES_OFFSET
+static inline unsigned char *skb_inner_transport_header(const struct sk_buff
+ *skb)
+{
+ return skb->head + skb->inner_transport_header;
+}
+
+static inline void skb_reset_inner_transport_header(struct sk_buff *skb)
+{
+ skb->inner_transport_header = skb->data - skb->head;
+}
+
+static inline void skb_set_inner_transport_header(struct sk_buff *skb,
+ const int offset)
+{
+ skb_reset_inner_transport_header(skb);
+ skb->inner_transport_header += offset;
+}
+
+static inline unsigned char *skb_inner_network_header(const struct sk_buff *skb)
+{
+ return skb->head + skb->inner_network_header;
+}
+
+static inline void skb_reset_inner_network_header(struct sk_buff *skb)
+{
+ skb->inner_network_header = skb->data - skb->head;
+}
+
+static inline void skb_set_inner_network_header(struct sk_buff *skb,
+ const int offset)
+{
+ skb_reset_inner_network_header(skb);
+ skb->inner_network_header += offset;
+}
+
+static inline unsigned char *skb_inner_mac_header(const struct sk_buff *skb)
+{
+ return skb->head + skb->inner_mac_header;
+}
+
+static inline int skb_inner_mac_header_was_set(const struct sk_buff *skb)
+{
+ return skb->inner_mac_header != ~0U;
+}
+
+static inline void skb_reset_inner_mac_header(struct sk_buff *skb)
+{
+ skb->inner_mac_header = skb->data - skb->head;
+}
+
+static inline void skb_set_inner_mac_header(struct sk_buff *skb,
+ const int offset)
+{
+ skb_reset_inner_mac_header(skb);
+ skb->inner_mac_header += offset;
+}
+
static inline unsigned char *skb_transport_header(const struct sk_buff *skb)
{
return skb->head + skb->transport_header;
@@ -1496,7 +1559,58 @@ static inline void skb_set_mac_header(struct sk_buff *skb, const int offset)
}
#else /* NET_SKBUFF_DATA_USES_OFFSET */
+static inline unsigned char *skb_inner_transport_header(const struct sk_buff
+ *skb)
+{
+ return skb->inner_transport_header;
+}
+
+static inline void skb_reset_inner_transport_header(struct sk_buff *skb)
+{
+ skb->inner_transport_header = skb->data;
+}
+
+static inline void skb_set_inner_transport_header(struct sk_buff *skb,
+ const int offset)
+{
+ skb->inner_transport_header = skb->data + offset;
+}
+
+static inline unsigned char *skb_inner_network_header(const struct sk_buff *skb)
+{
+ return skb->inner_network_header;
+}
+
+static inline void skb_reset_inner_network_header(struct sk_buff *skb)
+{
+ skb->inner_network_header = skb->data;
+}
+
+static inline void skb_set_inner_network_header(struct sk_buff *skb,
+ const int offset)
+{
+ skb->inner_network_header = skb->data + offset;
+}
+
+static inline unsigned char *skb_inner_mac_header(const struct sk_buff *skb)
+{
+ return skb->inner_mac_header;
+}
+
+static inline int skb_inner_mac_header_was_set(const struct sk_buff *skb)
+{
+ return skb->inner_mac_header != NULL;
+}
+static inline void skb_reset_mac_header(struct sk_buff *skb)
+{
+ skb->inner_mac_header = skb->data;
+}
+
+static inline void skb_set_mac_header(struct sk_buff *skb, const int offset)
+{
+ skb->inner_mac_header = skb->data + offset;
+}
static inline unsigned char *skb_transport_header(const struct sk_buff *skb)
{
return skb->transport_header;
diff --git a/include/linux/udp.h b/include/linux/udp.h
index 0b67d77..bd49c56 100644
--- a/include/linux/udp.h
+++ b/include/linux/udp.h
@@ -27,6 +27,11 @@ static inline struct udphdr *udp_hdr(const struct sk_buff *skb)
return (struct udphdr *)skb_transport_header(skb);
}
+static inline struct udphdr *udp_inner_hdr(const struct sk_buff *skb)
+{
+ return (struct udphdr *)skb_inner_transport_header(skb);
+}
+
#define UDP_HTABLE_SIZE_MIN (CONFIG_BASE_SMALL ? 128 : 256)
static inline int udp_hashfn(struct net *net, unsigned num, unsigned mask)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 4d64cc2..11f928d 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -58,6 +58,7 @@ static const char netdev_features_strings[NETDEV_FEATURE_COUNT][ETH_GSTRING_LEN]
[NETIF_F_IP_CSUM_BIT] = "tx-checksum-ipv4",
[NETIF_F_HW_CSUM_BIT] = "tx-checksum-ip-generic",
[NETIF_F_IPV6_CSUM_BIT] = "tx-checksum-ipv6",
+ [NETIF_F_HW_CSUM_ENC_BIT] = "tx-checksum-enc-offload",
[NETIF_F_HIGHDMA_BIT] = "highdma",
[NETIF_F_FRAGLIST_BIT] = "tx-scatter-gather-fraglist",
[NETIF_F_HW_VLAN_TX_BIT] = "tx-vlan-hw-insert",
@@ -84,6 +85,7 @@ static const char netdev_features_strings[NETDEV_FEATURE_COUNT][ETH_GSTRING_LEN]
[NETIF_F_NTUPLE_BIT] = "rx-ntuple-filter",
[NETIF_F_RXHASH_BIT] = "rx-hashing",
[NETIF_F_RXCSUM_BIT] = "rx-checksum",
+ [NETIF_F_RXCSUM_ENC_BIT] = "rx-enc-checksum-offload",
[NETIF_F_NOCACHE_COPY_BIT] = "tx-nocache-copy",
[NETIF_F_LOOPBACK_BIT] = "loopback",
[NETIF_F_RXFCS_BIT] = "rx-fcs",
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index d9addea..4be312b 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -259,6 +259,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
skb->end = skb->tail + size;
#ifdef NET_SKBUFF_DATA_USES_OFFSET
skb->mac_header = ~0U;
+ skb->inner_mac_header = ~0U;
#endif
/* make sure we initialize shinfo sequentially */
@@ -327,6 +328,7 @@ struct sk_buff *build_skb(void *data, unsigned int frag_size)
skb->end = skb->tail + size;
#ifdef NET_SKBUFF_DATA_USES_OFFSET
skb->mac_header = ~0U;
+ skb->inner_mac_header = ~0U;
#endif
/* make sure we initialize shinfo sequentially */
@@ -682,6 +684,9 @@ static void __copy_skb_header(struct sk_buff *new, const struct sk_buff *old)
new->transport_header = old->transport_header;
new->network_header = old->network_header;
new->mac_header = old->mac_header;
+ new->inner_transport_header = old->inner_transport_header;
+ new->inner_network_header = old->inner_transport_header;
+ new->inner_mac_header = old->inner_mac_header;
skb_dst_copy(new, old);
new->rxhash = old->rxhash;
new->ooo_okay = old->ooo_okay;
@@ -892,6 +897,10 @@ static void copy_skb_header(struct sk_buff *new, const struct sk_buff *old)
new->network_header += offset;
if (skb_mac_header_was_set(new))
new->mac_header += offset;
+ new->inner_transport_header += offset;
+ new->inner_network_header += offset;
+ if (skb_inner_mac_header_was_set(new))
+ new->inner_mac_header += offset;
#endif
skb_shinfo(new)->gso_size = skb_shinfo(old)->gso_size;
skb_shinfo(new)->gso_segs = skb_shinfo(old)->gso_segs;
@@ -1089,6 +1098,10 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
skb->network_header += off;
if (skb_mac_header_was_set(skb))
skb->mac_header += off;
+ skb->inner_transport_header += off;
+ skb->inner_network_header += off;
+ if (skb_inner_mac_header_was_set(skb))
+ skb->inner_mac_header += off;
/* Only adjust this if it actually is csum_start rather than csum */
if (skb->ip_summed == CHECKSUM_PARTIAL)
skb->csum_start += nhead;
@@ -1188,6 +1201,10 @@ struct sk_buff *skb_copy_expand(const struct sk_buff *skb,
n->network_header += off;
if (skb_mac_header_was_set(skb))
n->mac_header += off;
+ n->inner_transport_header += off;
+ n->inner_network_header += off;
+ if (skb_inner_mac_header_was_set(skb))
+ n->inner_mac_header += off;
#endif
return n;
--
1.7.11.7
^ permalink raw reply related
* [PATCH 2/3] vxlan: capture inner headers during encapsulation
From: Joseph Gasparakis @ 2012-11-09 2:18 UTC (permalink / raw)
To: davem, shemminger, chrisw
Cc: Joseph Gasparakis, netdev, linux-kernel, Peter P Waskiewicz Jr
In-Reply-To: <1352427483-4380-1-git-send-email-joseph.gasparakis@intel.com>
Populating the inner header pointers of skb for vxlan
Signed-off-by: Joseph Gasparakis <joseph.gasparakis@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
---
drivers/net/vxlan.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 030559d..14e6c8f 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -694,11 +694,23 @@ static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct net_device *dev)
__be16 df = 0;
__u8 tos, ttl;
int err;
+ unsigned int offset;
dst = vxlan_find_dst(vxlan, skb);
if (!dst)
goto drop;
+ offset = skb->data - skb->head;
+
+ skb_reset_inner_mac_header(skb);
+
+ if (skb->network_header)
+ skb_set_inner_network_header(skb, skb->network_header - offset);
+
+ if (skb->transport_header)
+ skb_set_inner_transport_header(skb, skb->transport_header -
+ offset);
+
/* Need space for new headers (invalidates iph ptr) */
if (skb_cow_head(skb, VXLAN_HEADROOM))
goto drop;
--
1.7.11.7
^ permalink raw reply related
* [PATCH 3/3] ipgre: capture inner headers during encapsulation
From: Joseph Gasparakis @ 2012-11-09 2:18 UTC (permalink / raw)
To: davem, shemminger, chrisw
Cc: Joseph Gasparakis, netdev, linux-kernel, Peter P Waskiewicz Jr
In-Reply-To: <1352427483-4380-1-git-send-email-joseph.gasparakis@intel.com>
Populating the inner header pointers of skb for ipgre
This patch has been compile-tested only.
Signed-off-by: Joseph Gasparakis <joseph.gasparakis@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
---
net/ipv4/ip_gre.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 7240f8e..ec3ebb1 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -766,6 +766,7 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
int gre_hlen;
__be32 dst;
int mtu;
+ unsigned int offset;
if (skb->ip_summed == CHECKSUM_PARTIAL &&
skb_checksum_help(skb))
@@ -902,6 +903,17 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
tunnel->err_count = 0;
}
+ offset = skb->data - skb->head;
+
+ skb_reset_inner_mac_header(skb);
+
+ if (skb->network_header)
+ skb_set_inner_network_header(skb, skb->network_header - offset);
+
+ if (skb->transport_header)
+ skb_set_inner_transport_header(skb, skb->transport_header -
+ offset);
+
max_headroom = LL_RESERVED_SPACE(tdev) + gre_hlen + rt->dst.header_len;
if (skb_headroom(skb) < max_headroom || skb_shared(skb)||
--
1.7.11.7
^ permalink raw reply related
* [PATCH 0/9 v3] use efficient this_cpu_* helper
From: Shan Wei @ 2012-11-09 2:20 UTC (permalink / raw)
To: cl, David Miller, NetDev, Kernel-Maillist, Shan Wei
this_cpu_ptr/this_cpu_read is faster than per_cpu_ptr(p, smp_processor_id())
and can reduce memory accesses.
The latter helper needs to find the offset for current cpu,
and needs more assembler instructions which objdump shows in following.
this_cpu_ptr relocates and address. this_cpu_read() relocates the address
and performs the fetch. If you want to operate on rda(defined as per_cpu)
then you can only use this_cpu_ptr. this_cpu_read() saves you more instructions
since it can do the relocation and the fetch in one instruction.
per_cpu_ptr(p, smp_processor_id())：
1e: 65 8b 04 25 00 00 00 00 mov %gs:0x0,%eax
26: 48 98 cltq
28: 31 f6 xor %esi,%esi
2a: 48 c7 c7 00 00 00 00 mov $0x0,%rdi
31: 48 8b 04 c5 00 00 00 00 mov 0x0(,%rax,8),%rax
39: c7 44 10 04 14 00 00 00 movl $0x14,0x4(%rax,%rdx,1)
this_cpu_ptr(p)
1e: 65 48 03 14 25 00 00 00 00 add %gs:0x0,%rdx
27: 31 f6 xor %esi,%esi
29: c7 42 04 14 00 00 00 movl $0x14,0x4(%rdx)
30: 48 c7 c7 00 00 00 00 mov $0x0,%rdi
Changelog V3:
1. use this_cpu_read directly read member of per-cpu variable,
so that droping the this_cpu_ptr operation.
2. for preemption off and bottom halves off case,
use __this_cpu_read instead of this_cpu_read.
Changelog V2:
1. Use this_cpu_read directly instead of ref to field of per-cpu variable.
2. Patch5 about ftrace is dropped from this series.
3. Add new patch9 to replace get_cpu;per_cpu_ptr;put_cpu with this_cpu_add opt.
4. For preemption disable case, use __this_cpu_read instead.
$ git diff --stat 7da716aee2532399e213a14f656d304098f67a11..
drivers/clocksource/arm_generic.c | 2 +-
kernel/padata.c | 5 ++---
kernel/rcutree.c | 2 +-
kernel/trace/blktrace.c | 2 +-
kernel/trace/trace.c | 5 +----
net/batman-adv/main.h | 4 +---
net/core/flow.c | 4 +---
net/openvswitch/datapath.c | 4 ++--
net/openvswitch/vport.c | 5 ++---
net/rds/ib_recv.c | 2 +-
net/xfrm/xfrm_ipcomp.c | 7 ++-----
11 files changed, 15 insertions(+), 27 deletions(-)
^ permalink raw reply
* gro vs vlan in myri10ge
From: Andrew Gallatin @ 2012-11-09 2:20 UTC (permalink / raw)
To: netdev
Hi,
I've wanted to convert myri10ge from LRO to GRO for quite a while.
The problem I'm facing is that the NIC cannot perform hardware vlan
tag offload, so GRO performance is far below LRO performance when
receiving vlan tagged TCP traffic.
If a vlan tagged frame is passed to lro_receive_frags(), inet_lro will
look at the encapsulated IPv4 frame and TCP aggregation will succeed.
However, it appears that GRO will not do this. When I patch the
driver to use GRO, and configure a vlan interface, I see high CPU
utilization and poor bandwidth when I'm receiving a netperf TCP stream
on the vlan interface. If I use LRO in an unpatched driver, then I
see good receive performance in the same scenario.
What is the best way to "fix" this?
Unless I'm just using GRO wrong, it seems that the simplest thing for
me to do is to claim NETIF_F_HW_VLAN_RX, but pop the tags in the
driver so as to allow myri10ge to pass up a non-encapsulated frame the
same way that (nearly?) every other 10GbE NIC does. I've got a quick
and dirty patch that confirms doing the vtag pop in the driver gives
me roughly the same performance with GRO as I used to have with LRO.
Is this (popping vlan tags in the driver) acceptable, or is it
too much of a layering violation?
Thanks,
Drew
^ permalink raw reply
* [PATCH v3 1/9] net: core: use this_cpu_ptr per-cpu helper
From: Shan Wei @ 2012-11-09 2:20 UTC (permalink / raw)
To: David Miller, timo.teras, steffen.klassert, NetDev,
Kernel-Maillist, cl, Shan Wei
From: Shan Wei <davidshan@tencent.com>
flush_tasklet is a struct, not a pointer in percpu var.
so use this_cpu_ptr to get the member pointer.
Signed-off-by: Shan Wei <davidshan@tencent.com>
---
net/core/flow.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/net/core/flow.c b/net/core/flow.c
index e318c7e..b0901ee 100644
--- a/net/core/flow.c
+++ b/net/core/flow.c
@@ -327,11 +327,9 @@ static void flow_cache_flush_tasklet(unsigned long data)
static void flow_cache_flush_per_cpu(void *data)
{
struct flow_flush_info *info = data;
- int cpu;
struct tasklet_struct *tasklet;
- cpu = smp_processor_id();
- tasklet = &per_cpu_ptr(info->cache->percpu, cpu)->flush_tasklet;
+ tasklet = this_cpu_ptr(&info->cache->percpu->flush_tasklet);
tasklet->data = (unsigned long)info;
tasklet_schedule(tasklet);
}
--
1.7.1
^ permalink raw reply related
* [PATCH v3 2/9] net: rds: use this_cpu_ptr per-cpu helper
From: Shan Wei @ 2012-11-09 2:20 UTC (permalink / raw)
To: venkat.x.venkatsubra, David Miller, rds-devel, NetDev,
Kernel-Maillist, cl, Shan Wei
From: Shan Wei <davidshan@tencent.com>
Signed-off-by: Shan Wei <davidshan@tencent.com>
Reviewed-by: Christoph Lameter <cl@linux.com>
---
no changes vs v2.
---
net/rds/ib_recv.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/rds/ib_recv.c b/net/rds/ib_recv.c
index 8d19491..a4a5064 100644
--- a/net/rds/ib_recv.c
+++ b/net/rds/ib_recv.c
@@ -423,7 +423,7 @@ static void rds_ib_recv_cache_put(struct list_head *new_item,
local_irq_save(flags);
- chp = per_cpu_ptr(cache->percpu, smp_processor_id());
+ chp = this_cpu_ptr(cache->percpu);
if (!chp->first)
INIT_LIST_HEAD(new_item);
else /* put on front */
--
1.7.1
^ permalink raw reply related
* [PATCH v3 3/9] net: xfrm: use __this_cpu_read per-cpu helper
From: Shan Wei @ 2012-11-09 2:20 UTC (permalink / raw)
To: steffen.klassert, David Miller, NetDev, Herbert Xu,
Kernel-Maillist, cl, Shan Wei
From: Shan Wei <davidshan@tencent.com>
Signed-off-by: Shan Wei <davidshan@tencent.com>
---
v3 fix compile warning:
net/xfrm/xfrm_ipcomp.c: In function 'ipcomp_alloc_tfms':
net/xfrm/xfrm_ipcomp.c:285: warning: assignment from incompatible pointer type
---
net/xfrm/xfrm_ipcomp.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/xfrm/xfrm_ipcomp.c b/net/xfrm/xfrm_ipcomp.c
index e5246fb..898c899 100644
--- a/net/xfrm/xfrm_ipcomp.c
+++ b/net/xfrm/xfrm_ipcomp.c
@@ -276,18 +276,15 @@ static struct crypto_comp * __percpu *ipcomp_alloc_tfms(const char *alg_name)
struct crypto_comp * __percpu *tfms;
int cpu;
- /* This can be any valid CPU ID so we don't need locking. */
- cpu = raw_smp_processor_id();
list_for_each_entry(pos, &ipcomp_tfms_list, list) {
struct crypto_comp *tfm;
- tfms = pos->tfms;
- tfm = *per_cpu_ptr(tfms, cpu);
+ tfm = (struct crypto_comp *) __this_cpu_read(pos->tfms);
if (!strcmp(crypto_comp_name(tfm), alg_name)) {
pos->users++;
- return tfms;
+ return pos->tfms;
}
}
--
1.7.1
^ permalink raw reply related
* [PATCH v3 4/9] net: openvswitch: use this_cpu_ptr per-cpu helper
From: Shan Wei @ 2012-11-09 2:21 UTC (permalink / raw)
To: jesse-l0M0P4e3n4LQT0dZR+AlfA, dev-yBygre7rU0TnMu66kgdUjQ, NetDev,
Kernel-Maillist, David Miller,
cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, Shan Wei
From: Shan Wei <davidshan-1Nz4purKYjRBDgjK7y7TUQ@public.gmane.org>
just use more faster this_cpu_ptr instead of per_cpu_ptr(p, smp_processor_id());
Signed-off-by: Shan Wei <davidshan-1Nz4purKYjRBDgjK7y7TUQ@public.gmane.org>
---
no changes vs v2.
---
net/openvswitch/datapath.c | 4 ++--
net/openvswitch/vport.c | 5 ++---
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 4c4b62c..77d16a5 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -208,7 +208,7 @@ void ovs_dp_process_received_packet(struct vport *p, struct sk_buff *skb)
int error;
int key_len;
- stats = per_cpu_ptr(dp->stats_percpu, smp_processor_id());
+ stats = this_cpu_ptr(dp->stats_percpu);
/* Extract flow from 'skb' into 'key'. */
error = ovs_flow_extract(skb, p->port_no, &key, &key_len);
@@ -282,7 +282,7 @@ int ovs_dp_upcall(struct datapath *dp, struct sk_buff *skb,
return 0;
err:
- stats = per_cpu_ptr(dp->stats_percpu, smp_processor_id());
+ stats = this_cpu_ptr(dp->stats_percpu);
u64_stats_update_begin(&stats->sync);
stats->n_lost++;
diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c
index 03779e8..70af0be 100644
--- a/net/openvswitch/vport.c
+++ b/net/openvswitch/vport.c
@@ -333,8 +333,7 @@ void ovs_vport_receive(struct vport *vport, struct sk_buff *skb)
{
struct vport_percpu_stats *stats;
- stats = per_cpu_ptr(vport->percpu_stats, smp_processor_id());
-
+ stats = this_cpu_ptr(vport->percpu_stats);
u64_stats_update_begin(&stats->sync);
stats->rx_packets++;
stats->rx_bytes += skb->len;
@@ -359,7 +358,7 @@ int ovs_vport_send(struct vport *vport, struct sk_buff *skb)
if (likely(sent)) {
struct vport_percpu_stats *stats;
- stats = per_cpu_ptr(vport->percpu_stats, smp_processor_id());
+ stats = this_cpu_ptr(vport->percpu_stats);
u64_stats_update_begin(&stats->sync);
stats->tx_packets++;
--
1.7.1
^ permalink raw reply related
* [PATCH v3 9/9] net: batman-adv: use per_cpu_add helper
From: Shan Wei @ 2012-11-09 2:22 UTC (permalink / raw)
To: lindner_marek-LWAfsSFWpa4, siwu-MaAgPAbsBIVS8oHt8HbXEIQuADTiUCJX,
ordex-GaUfNO9RBHfsrOwW+9ziJQ,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r, David Miller,
NetDev, Kernel-Maillist, Shan Wei, Christoph Lameter
From: Shan Wei <davidshan-1Nz4purKYjRBDgjK7y7TUQ@public.gmane.org>
this_cpu_add is an atomic operation.
and be more faster than per_cpu_ptr operation.
Signed-off-by: Shan Wei <davidshan-1Nz4purKYjRBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>
---
v3: change commit message.
---
net/batman-adv/main.h | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/net/batman-adv/main.h b/net/batman-adv/main.h
index 897ba6a..3aef5b2 100644
--- a/net/batman-adv/main.h
+++ b/net/batman-adv/main.h
@@ -263,9 +263,7 @@ static inline bool batadv_has_timed_out(unsigned long timestamp,
static inline void batadv_add_counter(struct batadv_priv *bat_priv, size_t idx,
size_t count)
{
- int cpu = get_cpu();
- per_cpu_ptr(bat_priv->bat_counters, cpu)[idx] += count;
- put_cpu();
+ this_cpu_add(bat_priv->bat_counters[idx], count);
}
#define batadv_inc_counter(b, i) batadv_add_counter(b, i, 1)
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next] ipv6: remove rt6i_peer_genid from rt6_info and its handler
From: David Miller @ 2012-11-09 2:30 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1352361393-4807-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Thu, 8 Nov 2012 15:56:33 +0800
> From: Li RongQing <roy.qing.li@gmail.com>
>
> 6431cbc25f(Create a mechanism for upward inetpeer propagation into routes)
> introduces these codes, but this mechanism is never enabled since
> rt6i_peer_genid always is zero whether it is not assigned or assigned by
> rt6_peer_genid(). After 5943634fc5 (ipv4: Maintain redirect and PMTU info
> in struct rtable again), the ipv4 related codes of this mechanism has been
> removed, I think we maybe able to remove them now.
>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/4 net-next] net: allow skb->head to be a page fragment
From: Li Yu @ 2012-11-09 2:31 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Netdev List
In-Reply-To: <1352381449.19779.13.camel@edumazet-glaptop>
于 2012年11月08日 21:30, Eric Dumazet 写道:
> On Thu, 2012-11-08 at 15:46 +0800, Li Yu wrote:
>
>> I think that all kmalloced() objects are continuous on both virtual
>> and physical address space, so such page fragment converting should be
>> safe until we use slab allocator to free them.
>>
>
> Its not safe at all. Good luck with coping with SLAB, SLUB, SLOB, and
> various debugging facilities on top of them.
>
The slab class API semantic should not change among them. the debugging
facilities should only add or modify metadata around user bytes too.
However, I also decided giving up use kmalloced() objects since it is
hard to free them safely them without some extra efforts after doing
page fragmentation on them.
I think that adding skb->frag_head indeed is a better choice, this means
I have to rework some NIC drivers :(
>> I ask this question since I am working on a patch to try to directly
>> forward the data from rx queue of a socket to tx queue of another
>> socket. We noticed that the splice itself still has visible costs when
>> forwarding small messages, and hope such direct forwarding optimization
>> can improve this, this idea comes from TCP friends.
>
> If not using splice, you directly transfert one skb coming from one
> side, to the other side, so you dont care skb->head being a frag or not.
>
> If messages are small, there is probably no hope trying to coalesce them
> (or else fixing the application would be much easier)
>
This patch is hoped that can work well for big messages too, so I
selected moving page fragment, and I think this should be easier a bit
because I can directly reuse tcp_sendpage() interface or just need a bit
of changes on it :)
If it can work well, I will send it out.
Thans very much for your time, :)
Yu
>
>
>
^ permalink raw reply
* Re: [PATCH] ipv6: fix two typos in a comment in xfrm6_init()
From: David Miller @ 2012-11-09 2:36 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1352363888-14068-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Thu, 8 Nov 2012 16:38:08 +0800
> From: Li RongQing <roy.qing.li@gmail.com>
>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
As Steffen stated, this comment is largely obsolete.
^ 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