* HELLO !!!
From: William Lee Cheng @ 2012-11-08 15:53 UTC (permalink / raw)
Dear Friend,
Greetings to you, I have a business proposal for you that will be
beneficial to the both of us.This proposal has to do with funds transfer.
In confirmation of your acceptance,I would need you to provide me with
your full names, current house and mailing address,date of birth telephone
and fax numbers so as to be very confident that I am dealing with the
right person.(This is very important).
Once I have received confirmation from you with the required information,
I shall then send you further details about this transaction and how it
will be executed. I look forward to hearing from you soonest and hope that
this marks the beginning of a successful and long lasting business
relationship with you. My profound greetings to you and your family.
Best regards,
William Lee Cheng.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* Re: [PATCH] ethtool: Support et131x registers in -d
From: Ben Hutchings @ 2012-11-08 19:25 UTC (permalink / raw)
To: Mark Einon; +Cc: netdev
In-Reply-To: <1351634243-10265-1-git-send-email-mark.einon@gmail.com>
On Tue, 2012-10-30 at 21:57 +0000, Mark Einon wrote:
> The et131x register set contains useful details of RX/TX queues for
> the device. This dumps them with the -d option.
>
> Signed-off-by: Mark Einon <mark.einon@gmail.com>
Applied, thanks. However:
[...]
> --- /dev/null
> +++ b/et131x.c
> @@ -0,0 +1,120 @@
> +#include <stdio.h>
> +#include <string.h>
> +#include "internal.h"
> +
> +int et131x_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
> +{
> + u32 *reg = (u32 *)regs->data;
> +
> + fprintf(stdout, "PHY Registers\n");
[...]
In case you need to change the dump format later, it might be worth
adding a version check here. But if you're confident that you'll only
ever append to the dump format, this should be fine for now.
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
* question on netdev_completed_queue()
From: Oliver Neukum @ 2012-11-08 19:38 UTC (permalink / raw)
To: netdev
Hi,
is this function to be called whenever a driver is done with transmitting
data, whether the transmission be successful or not?
Regards
Oliver
^ permalink raw reply
* Re: [PATCH v2 0/2] Fix CDC_EEM with 802.1Q VLAN and 1500 MTU
From: David Miller @ 2012-11-08 19:58 UTC (permalink / raw)
To: balbi-l0cyMroinI0
Cc: iancoolidge-Re5JQEeQqe8AvxtiuMwx3w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20121108133736.GA19533-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
From: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
Date: Thu, 8 Nov 2012 15:37:36 +0200
> Hi,
>
> On Wed, Nov 07, 2012 at 09:27:52PM -0500, David Miller wrote:
>> From: Ian Coolidge <iancoolidge-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Date: Wed, 7 Nov 2012 16:39:17 -0800
>>
>> > cdc_eem USB host driver and gadget driver both are broken in 1500 MTU
>> > case while using 802.1Q VLANs. In both cases, this is due to the
>> > assumption of standard Ethernet frame length.
>> >
>> > v2: rebase against Dave Miller's 'net/master' tree
>> >
>> > Ian Coolidge (2):
>> > usb: gadget: g_ether: fix frame size check for 802.1Q
>> > net: usb: cdc_eem: Fix rx skb allocation for 802.1Q VLANs
>>
>> Applied, thanks.
>
> did you take both ?
Yes.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ipv6: fix two typos in a comment in xfrm6_init()
From: David Miller @ 2012-11-08 19:59 UTC (permalink / raw)
To: steffen.klassert; +Cc: roy.qing.li, netdev
In-Reply-To: <20121108141936.GC22290@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Thu, 8 Nov 2012 15:19:36 +0100
> On Thu, Nov 08, 2012 at 04:38:08PM +0800, roy.qing.li@gmail.com wrote:
>> From: Li RongQing <roy.qing.li@gmail.com>
>>
>> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
>> ---
>> net/ipv6/xfrm6_policy.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c
>> index f3ed8ca..93832e8 100644
>> --- a/net/ipv6/xfrm6_policy.c
>> +++ b/net/ipv6/xfrm6_policy.c
>> @@ -332,10 +332,10 @@ int __init xfrm6_init(void)
>> /*
>> * We need a good default value for the xfrm6 gc threshold.
>> * In ipv4 we set it to the route hash table size * 8, which
>> - * is half the size of the maximaum route cache for ipv4. It
>> + * is half the size of the maximum route cache for ipv4.
>
> The routing cache is removed, so this comment is obsolete. But it reminds
> me that we set the gc threshold to ip_rt_max_size/2 in ipv4. With the
> routing cache removal patch, ip_rt_max_size was set to INT_MAX. So the gc
> starts to remove entries when a threshold of INT_MAX/2 is reached.
>
> cat /proc/sys/net/ipv4/xfrm4_gc_thresh
> 1073741823
>
> I guess this was not intentional.
Do you mean for IPSEC routes? For non-IPSEC routes on ipv4 there
is nothing to garbage collect.
^ permalink raw reply
* [PATCH net-next] ipip: add GSO support
From: Eric Dumazet @ 2012-11-08 19:59 UTC (permalink / raw)
To: David Miller
Cc: netdev, Maciej Żenczykowski, Tom Herbert, Willem de Bruijn
From: Eric Dumazet <edumazet@google.com>
In commit 6b78f16e4b (gre: add GSO support) we added GSO support to GRE
tunnels.
This patch does the same for IPIP tunnels.
Performance of single TCP flow over an IPIP tunnel is increased by 40%
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Maciej Żenczykowski <maze@google.com>
Cc: Tom Herbert <therbert@google.com>
Cc: Willem de Bruijn <willemb@google.com>
---
net/ipv4/ipip.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index e15b452..cc49cc1 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -479,6 +479,10 @@ static netdev_tx_t ipip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
if (skb->protocol != htons(ETH_P_IP))
goto tx_error;
+ if (skb->ip_summed == CHECKSUM_PARTIAL &&
+ skb_checksum_help(skb))
+ goto tx_error;
+
if (tos & 1)
tos = old_iph->tos;
@@ -773,6 +777,11 @@ static void ipip_dev_free(struct net_device *dev)
free_netdev(dev);
}
+#define IPIP_FEATURES (NETIF_F_SG | \
+ NETIF_F_FRAGLIST | \
+ NETIF_F_HIGHDMA | \
+ NETIF_F_HW_CSUM)
+
static void ipip_tunnel_setup(struct net_device *dev)
{
dev->netdev_ops = &ipip_netdev_ops;
@@ -787,6 +796,9 @@ static void ipip_tunnel_setup(struct net_device *dev)
dev->features |= NETIF_F_NETNS_LOCAL;
dev->features |= NETIF_F_LLTX;
dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
+
+ dev->features |= IPIP_FEATURES;
+ dev->hw_features |= IPIP_FEATURES;
}
static int ipip_tunnel_init(struct net_device *dev)
^ permalink raw reply related
* Re: [PATCH] qmi_wwan/cdc_ether: add Dell Wireless 5800 (Novatel E362) USB IDs
From: Bjørn Mork @ 2012-11-08 20:00 UTC (permalink / raw)
To: Dan Williams; +Cc: Aleksander Morgado, netdev, linux-usb
In-Reply-To: <1352398471.22225.18.camel@dcbw.foobar.com>
Dan Williams <dcbw@redhat.com> writes:
> The Dell Wireless 5800 appears to be a Novatel E362 rebrand.
>
> Signed-off-by: Dan Williams <dcbw@redhat.com>
> Cc: stable@vger.kernel.org
Acked-by: Bjørn Mork <bjorn@mork.no>
^ permalink raw reply
* Re: [PATCH net-next] sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name
From: David Miller @ 2012-11-08 20:02 UTC (permalink / raw)
To: brian.haley; +Cc: bhutchings, xemul, eric.dumazet, netdev
In-Reply-To: <509BD162.1000205@hp.com>
From: Brian Haley <brian.haley@hp.com>
Date: Thu, 08 Nov 2012 08:36:02 -0700
> I noticed this isn't in patchwork anymore.
I want all the races resolved, and in any event the thing to do
when something isn't in patchwork IS TO RESUBMIT IT!
Every time you ask me stuff like this you take up more of my already
low amount of time.
Today I'm again without internet access other than my cell phone, so
everything you can do TO REDUCE my overhead would be greatly
appreciated.
^ permalink raw reply
* essentially offline...
From: David Miller @ 2012-11-08 20:09 UTC (permalink / raw)
To: netdev; +Cc: netfilter-devel, linux-wireless
Once again I am without any real internet access both at home (Time
Warner major Manhattan outage since this morning) and at the office
(Verizon still largely out in Lower Manhattan).
So I'm not going to be resonsive until one of these two outages are
resolved. I cannot even call Time Warner customer support, I get "all
circuits are busy" so they're obviously getting bombed with calls.
Want to help? There are two ways:
1) Don't do anything that makes more overhead for me.
Don't ask about patch status, that's what the heck patchwork
is for. If you're patch isn't there and active and you think
it needs to bee considered seriously, REPOST it, DON'T ASK ME
about a patch I already moved out of my TODO list. That's more
work for me.
And, this should go without saying %100 of the time, DO NOT
send me private email. It is never appropriate, I don't care
what excuse you come up with. Just simply don't do it.
2) Don't be a jackass and avoid reviewing patches that you can
actually provide feedback on.
That is what makes my backlog something that is actually
manageable, when everyone else dutifully reviews patches that get
posted so that I have something to immediately work against when I
get to reviewing that patch myself.
One great example is the gianfar patch posted the other day.
Nobody is going to review that and I know absolutely nothing
about gianfar hardware, whether that is the correct fix, etc.
So it'll either just rot there, or I'll have to guess if it's
correct.
But this is exactly what breaks down my productivity, when
people who are knowledgable don't review patches like that one.
Thanks.
^ permalink raw reply
* [PATCH] vmxnet3: convert BUG_ON(true) into a simple BUG()
From: Sasha Levin @ 2012-11-08 20:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Sasha Levin, Shreyas Bhatewara, VMware, Inc., netdev
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 0ae1bcc..7e9622f 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -1922,7 +1922,7 @@ vmxnet3_free_irqs(struct vmxnet3_adapter *adapter)
free_irq(adapter->pdev->irq, adapter->netdev);
break;
default:
- BUG_ON(true);
+ BUG();
}
}
--
1.7.10.4
^ permalink raw reply related
* 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
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;
as well as URLs for NNTP newsgroup(s).