* [PATCH] ipv4: fix error handling in icmp_protocol.
From: Li Wei @ 2013-02-22 8:18 UTC (permalink / raw)
To: davem; +Cc: netdev, lw
Now we handle icmp errors in each transport protocol's err_handler,
for icmp protocols, that is ping_err. Since this handler only care
of those icmp errors triggered by echo request, errors triggered
by echo reply(which sent by kernel) are sliently ignored.
So wrap ping_err() with icmp_err() to deal with those icmp errors.
Signed-off-by: Li Wei <lw@cn.fujitsu.com>
---
include/net/icmp.h | 1 +
net/ipv4/af_inet.c | 2 +-
net/ipv4/icmp.c | 23 +++++++++++++++++++++++
3 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/include/net/icmp.h b/include/net/icmp.h
index 9ac2524..081439f 100644
--- a/include/net/icmp.h
+++ b/include/net/icmp.h
@@ -41,6 +41,7 @@ struct net;
extern void icmp_send(struct sk_buff *skb_in, int type, int code, __be32 info);
extern int icmp_rcv(struct sk_buff *skb);
+extern void icmp_err(struct sk_buff *, u32 info);
extern int icmp_init(void);
extern void icmp_out_count(struct net *net, unsigned char type);
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index e225a4e..334b461 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1572,7 +1572,7 @@ static const struct net_offload udp_offload = {
static const struct net_protocol icmp_protocol = {
.handler = icmp_rcv,
- .err_handler = ping_err,
+ .err_handler = icmp_err,
.no_policy = 1,
.netns_ok = 1,
};
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 17ff9fd..3ac5dff 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -934,6 +934,29 @@ error:
goto drop;
}
+void icmp_err(struct sk_buff *skb, u32 info)
+{
+ struct iphdr *iph = (struct iphdr *)skb->data;
+ struct icmphdr *icmph = (struct icmphdr *)(skb->data+(iph->ihl<<2));
+ int type = icmp_hdr(skb)->type;
+ int code = icmp_hdr(skb)->code;
+ struct net *net = dev_net(skb->dev);
+
+ /*
+ * Use ping_err to handle all icmp errors except those
+ * triggered by ICMP_ECHOREPLY which sent from kernel.
+ */
+ if (icmph->type != ICMP_ECHOREPLY) {
+ ping_err(skb, info);
+ return;
+ }
+
+ if (type == ICMP_DEST_UNREACH && code == ICMP_FRAG_NEEDED)
+ ipv4_update_pmtu(skb, net, info, 0, 0, IPPROTO_ICMP, 0);
+ else if (type == ICMP_REDIRECT)
+ ipv4_redirect(skb, net, 0, 0, IPPROTO_ICMP, 0);
+}
+
/*
* This table is the definition of how we handle ICMP.
*/
--
1.8.0.2
^ permalink raw reply related
* FROM COCA COLA OFFICE
From: FROM COCA COLA OFFICE @ 2013-02-22 7:51 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 43 bytes --]
Contact the claim agent immediately .
[-- Attachment #2: COCA COLA.JPG --]
[-- Type: image/jpeg, Size: 277990 bytes --]
[-- Attachment #3: COCA COLA (2).JPG --]
[-- Type: image/jpeg, Size: 142686 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] ip_gre: allow CSUM capable devices to handle packets
From: pravin @ 2013-02-22 7:19 UTC (permalink / raw)
To: Dmitry Kravkov; +Cc: davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <CANvJab2S07fUPT3kJKM=NsCPuO-moJhtxhNExiWnxS-kFOkQ2Q@mail.gmail.com>
On Thu, Feb 21, 2013 at 3:46 PM, pravin <pravin.shelar@gmail.com> wrote:
> On Thu, Feb 21, 2013 at 2:26 PM, Dmitry Kravkov <dmitry@broadcom.com> wrote:
>> On Tue, 2013-02-19 at 15:03 -0800, pravin wrote:
>>> On Tue, Feb 19, 2013 at 11:20 AM, Dmitry Kravkov <dmitry@broadcom.com> wrote:
>>> >
>>> >> -----Original Message-----
>>> >> From: pravin [mailto:pravin.shelar@gmail.com]
>>> >> Sent: Tuesday, February 19, 2013 8:28 PM
>>> >> To: Dmitry Kravkov
>>> >> Cc: davem@davemloft.net; netdev@vger.kernel.org
>>> >> Subject: Re: [PATCH net-next v2 1/2] ip_gre: allow CSUM capable devices to
>>> >> handle packets
>>> >>
>>> >> On Mon, Feb 18, 2013 at 11:50 AM, Dmitry Kravkov <dmitry@broadcom.com>
>>> >> wrote:
>>> >> > If device is not able to handle checksumming it will
>>> >> > be handled in dev_xmit
>>> >> >
>>> >> > Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
>>> >> > ---
>>> >> > Changes from v1: fixed email address
>>> >> >
>>> >> > net/ipv4/ip_gre.c | 7 ++-----
>>> >> > 1 files changed, 2 insertions(+), 5 deletions(-)
>>> >> >
>>> >> > diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
>>> >> > index a56f118..cdc31ac 100644
>>> >> > --- a/net/ipv4/ip_gre.c
>>> >> > +++ b/net/ipv4/ip_gre.c
>>> >> > @@ -745,12 +745,9 @@ static struct sk_buff *handle_offloads(struct sk_buff
>>> >> *skb)
>>> >> > goto error;
>>> >> > skb_shinfo(skb)->gso_type |= SKB_GSO_GRE;
>>> >> > return skb;
>>> >> > - } else if (skb->ip_summed == CHECKSUM_PARTIAL) {
>>> >> > - err = skb_checksum_help(skb);
>>> >> > - if (unlikely(err))
>>> >> > - goto error;
>>> >> > }
>>> >> > - skb->ip_summed = CHECKSUM_NONE;
>>> >> > + if (skb->ip_summed != CHECKSUM_PARTIAL)
>>> >> > + skb->ip_summed = CHECKSUM_NONE;
>>> >> >
>>> >> > return skb;
>>> >> >
>>> >> > --
>>> >> > 1.7.7.2
>>> >> >
>>> >> >
>>> >>
>>> >> This patch breaks GRE tunnel with GRE_CSUM. since GRE_CSUM need
>>> >> complete IP packet to checksum entire GRE payload.
>>> >
>>> > Testing for o_flags&GRE_CSUM does not look too hurt here, since it will be used in ipgre_tunnel_xmit() later on
>>> > This is the only problematic case, right?
>>> >
>>>
>>> It does not work for me. I have GRE device with csum on. Ping works
>>> fine but Netperf is not working.
>>> Looking at code, I am not sure how tcp will work if inner packet TCP
>>> checksum is calculated after GRE_CSUM calculation.
>>
>>
>> Fixes handling when CSUM or SEQ flags are set - via skb_checksum_help()
>> ---
>> Tested with each mode (separately)
>>
>> net/ipv4/ip_gre.c | 14 +++++++++++---
>> 1 files changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
>> index 5ef4da7..0de54cd 100644
>> --- a/net/ipv4/ip_gre.c
>> +++ b/net/ipv4/ip_gre.c
>> @@ -735,7 +735,8 @@ drop:
>> return 0;
>> }
>>
>> -static struct sk_buff *handle_offloads(struct sk_buff *skb)
>> +static struct sk_buff *handle_offloads(struct ip_tunnel *tunnel,
>> + struct sk_buff *skb)
>> {
>> int err;
>>
>> @@ -745,8 +746,15 @@ static struct sk_buff *handle_offloads(struct
>> sk_buff *skb)
>> goto error;
>> skb_shinfo(skb)->gso_type |= SKB_GSO_GRE;
>> return skb;
>> + } else if (tunnel->parms.o_flags&(GRE_SEQ|GRE_CSUM) &&
>> + skb->ip_summed == CHECKSUM_PARTIAL) {
>> + err = skb_checksum_help(skb);
>> + if (unlikely(err))
>> + goto error;
>> }
one more thing, there is no need to do csum for GRE_SEQ case.
>> - if (skb->ip_summed != CHECKSUM_PARTIAL)
>> +
>> + if (skb->ip_summed != CHECKSUM_PARTIAL ||
>> + tunnel->parms.o_flags&(GRE_SEQ|GRE_CSUM))
>> skb->ip_summed = CHECKSUM_NONE;
>>
> We can simplify this by dropping check of o_flags.
>
>> return skb;
>> @@ -776,7 +784,7 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff
>> *skb, struct net_device *dev
>> int err;
>> int pkt_len;
>>
>> - skb = handle_offloads(skb);
>> + skb = handle_offloads(tunnel, skb);
>> if (IS_ERR(skb)) {
>> dev->stats.tx_dropped++;
>> return NETDEV_TX_OK;
>> --
>> 1.7.7.2
>>
>>
>>> Thanks,
>>> Pravin.
>>>
>>
>>
>>
^ permalink raw reply
* Re: [PATCH net-next] IP_GRE: Fix IP-Identification.
From: pravin @ 2013-02-22 7:17 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Pravin Shelar, netdev, edumazet, jesse
In-Reply-To: <1361513185.3683.1.camel@edumazet-glaptop>
On Thu, Feb 21, 2013 at 10:06 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2013-02-21 at 19:42 -0800, Pravin Shelar wrote:
>
>> Without this patch GRE-GSO generates ip fragments with id 0,2,3,4...
>> for every GSO packet, which is not correct. This patch fixes it.
>> --
>
> I guess my question was more : Why dont we inherit ID from the inner
> packet ?
>
Its good idea. But we still need to get counter from dst if inner
packet is not ipv4.
> ip_select_ident_more() is a performance killer, as all cpus are going to
> access a shared counter in the dst.
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH ipsec-next] xfrm: allow to avoid copying DSCP during encapsulation
From: Steffen Klassert @ 2013-02-22 6:06 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: herbert, davem, netdev
In-Reply-To: <1361201559-31972-1-git-send-email-nicolas.dichtel@6wind.com>
On Mon, Feb 18, 2013 at 04:32:39PM +0100, Nicolas Dichtel wrote:
> By default, DSCP is copying during encapsulation.
> Copying the DSCP in IPsec tunneling may be a bit dangerous because packets with
> different DSCP may get reordered relative to each other in the network and then
> dropped by the remote IPsec GW if the reordering becomes too big compared to the
> replay window.
>
> It is possible to avoid this copy with netfilter rules, but it's very convenient
> to be able to configure it for each SA directly.
>
> This patch adds a toogle for this purpose. By default, it's not set to maintain
> backward compatibility.
>
> Field flags in struct xfrm_usersa_info is full, hence I add a new attribute.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
> include/net/xfrm.h | 1 +
> include/uapi/linux/xfrm.h | 3 +++
> net/ipv4/xfrm4_mode_tunnel.c | 8 ++++++--
> net/ipv6/xfrm6_mode_tunnel.c | 7 +++++--
> net/xfrm/xfrm_user.c | 13 +++++++++++++
> 5 files changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/include/net/xfrm.h b/include/net/xfrm.h
> index 30f3e5b..c5f12da 100644
> --- a/include/net/xfrm.h
> +++ b/include/net/xfrm.h
> @@ -162,6 +162,7 @@ struct xfrm_state {
> xfrm_address_t saddr;
> int header_len;
> int trailer_len;
> + u32 extra_flags;
> } props;
Please ensure that your new extra_flags are copied whenever needed.
Right now we would loose them when we clone a state with
xfrm_state_clone().
>
> struct xfrm_lifetime_cfg lft;
> diff --git a/include/uapi/linux/xfrm.h b/include/uapi/linux/xfrm.h
> index 28e493b..f07f422 100644
> --- a/include/uapi/linux/xfrm.h
> +++ b/include/uapi/linux/xfrm.h
> @@ -297,6 +297,7 @@ enum xfrm_attr_type_t {
> XFRMA_MARK, /* struct xfrm_mark */
> XFRMA_TFCPAD, /* __u32 */
> XFRMA_REPLAY_ESN_VAL, /* struct xfrm_replay_esn */
> + XFRMA_SA_EXTRA_FLAGS, /* __u32 */
> __XFRMA_MAX
>
> #define XFRMA_MAX (__XFRMA_MAX - 1)
> @@ -367,6 +368,8 @@ struct xfrm_usersa_info {
> #define XFRM_STATE_ESN 128
> };
>
> +#define XFRM_STATE_EXTRA_FLAGS_DONT_ENCAP_DSCP 1
Can we have a shorter name for this flag, please?
^ permalink raw reply
* Re: [PATCH net-next] IP_GRE: Fix IP-Identification.
From: Eric Dumazet @ 2013-02-22 6:06 UTC (permalink / raw)
To: Pravin Shelar; +Cc: netdev, edumazet, jesse
In-Reply-To: <CALnjE+qOTnzdEjuGheRBhVC9piHdVKornV4Fv=ZubKS6ZAF6gQ@mail.gmail.com>
On Thu, 2013-02-21 at 19:42 -0800, Pravin Shelar wrote:
> Without this patch GRE-GSO generates ip fragments with id 0,2,3,4...
> for every GSO packet, which is not correct. This patch fixes it.
> --
I guess my question was more : Why dont we inherit ID from the inner
packet ?
ip_select_ident_more() is a performance killer, as all cpus are going to
access a shared counter in the dst.
^ permalink raw reply
* Re: [PATCH ipsec] af_key: initialize satype in key_notify_policy_flush()
From: Steffen Klassert @ 2013-02-22 5:56 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: herbert, davem, netdev
In-Reply-To: <1361201060-31732-1-git-send-email-nicolas.dichtel@6wind.com>
On Mon, Feb 18, 2013 at 04:24:20PM +0100, Nicolas Dichtel wrote:
> This field was left uninitialized. Some user daemons perform check against this
> field.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied, thanks!
^ permalink raw reply
* [Patch] openvswitch: fix the calculation of checksum for vlan header
From: Cong Wang @ 2013-02-22 5:25 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Jesse Gross, Cong Wang
From: Cong Wang <amwang@redhat.com>
In vlan_insert_tag(), we insert a 4-byte VLAN header _after_
mac header:
memmove(skb->data, skb->data + VLAN_HLEN, 2 * ETH_ALEN);
...
veth->h_vlan_proto = htons(ETH_P_8021Q);
...
veth->h_vlan_TCI = htons(vlan_tci);
so after it, we should recompute the checksum to include these 4 bytes.
skb->data still points to the mac header, therefore VLAN header is at
(2 * ETH_ALEN = 12) bytes after it, not (ETH_HLEN = 14) bytes.
This can also be observed via tcpdump:
0x0000: ffff ffff ffff 5254 005d 6f6e 8100 000a
0x0010: 0806 0001 0800 0604 0001 5254 005d 6f6e
0x0020: c0a8 026e 0000 0000 0000 c0a8 0282
Cc: David S. Miller <davem@davemloft.net>
Cc: Jesse Gross <jesse@nicira.com>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index ac2defe..a0e202c 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -115,7 +115,7 @@ static int push_vlan(struct sk_buff *skb, const struct ovs_action_push_vlan *vla
if (skb->ip_summed == CHECKSUM_COMPLETE)
skb->csum = csum_add(skb->csum, csum_partial(skb->data
- + ETH_HLEN, VLAN_HLEN, 0));
+ + (2 * ETH_ALEN), VLAN_HLEN, 0));
}
__vlan_hwaccel_put_tag(skb, ntohs(vlan->vlan_tci) & ~VLAN_TAG_PRESENT);
^ permalink raw reply related
* Re: [GIT] Networking
From: Mark Lord @ 2013-02-22 3:54 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Linus Torvalds, David Miller, Andrew Morton, Network Development,
Linux Kernel Mailing List
In-Reply-To: <CAP=VYLoW2KfdWen6x0p+Kv_DbsDj=mHMdAZB5Mx_RkFZ7jk6fg@mail.gmail.com>
On 13-02-21 09:26 PM, Paul Gortmaker wrote:
> On Thu, Feb 21, 2013 at 9:37 AM, Mark Lord <kernel@start.ca> wrote:
>> On 13-02-20 10:05 PM, Linus Torvalds wrote:
>>> On Wed, Feb 20, 2013 at 2:09 PM, David Miller <davem@davemloft.net> wrote:
..
>>> Nooo.... You killed the 3c501 and 3c503 drivers! Snif.
>>>
>>> I wonder if they still worked..
>>
>> I hope they're not really dead, because we still use them in several machines here
>> as secondary interfaces for test rigs and whatnot.
..
> Did you actually look at the drivers deleted?
..
Finally got to one of the boxes here to check.
And you're right, I was confusing drivers.
I always seem to get the 3c509 (ISA) stuff confused with the 3c59x (PCI).
Our boxes here have the 3c59x (PCI) cards.
R.I.P. 3c50x. :)
^ permalink raw reply
* Re: [PATCH net-next] IP_GRE: Fix IP-Identification.
From: Pravin Shelar @ 2013-02-22 3:42 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, edumazet, jesse
In-Reply-To: <1361500507.32484.8.camel@edumazet-glaptop>
On Thu, Feb 21, 2013 at 6:35 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2013-02-21 at 18:18 -0800, Pravin B Shelar wrote:
>> Use ip_select_ident_more() to generate and account ids for all
>> segments that can be used for segments of a gso packet.
>>
>> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
>
> I am not sure it makes any sense to do that.
>
> Why is it needed ?
>
Without this patch GRE-GSO generates ip fragments with id 0,2,3,4...
for every GSO packet, which is not correct. This patch fixes it.
^ permalink raw reply
* Re: [PATCH net-next] IP_GRE: Fix IP-Identification.
From: Eric Dumazet @ 2013-02-22 2:35 UTC (permalink / raw)
To: Pravin B Shelar; +Cc: netdev, edumazet, jesse
In-Reply-To: <1361499519-1715-1-git-send-email-pshelar@nicira.com>
On Thu, 2013-02-21 at 18:18 -0800, Pravin B Shelar wrote:
> Use ip_select_ident_more() to generate and account ids for all
> segments that can be used for segments of a gso packet.
>
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
I am not sure it makes any sense to do that.
Why is it needed ?
^ permalink raw reply
* Re: BCM5709 hang and state dump...
From: Daniel J Blueman @ 2013-02-22 2:33 UTC (permalink / raw)
To: Michael Chan; +Cc: Eilon Greenstein, Steffen Persvold, netdev
In-Reply-To: <1361483951.2240.44.camel@LTIRV-MCHAN1.corp.ad.broadcom.com>
Hi Michael,
Thanks for your reply.
We'll probably be able to reproduce it next week and collect the output
with your debug patches if useful.
Thanks again,
Daniel
On 22/02/2013 05:59, Michael Chan wrote:
> On Thu, 2013-02-21 at 13:26 +0800, Daniel J Blueman wrote:
>> Hi Michael/Eilon,
>>
>> On a large system with 552 cores, 1.5TB memory and linux 3.7, under some
>> particular workloads, we've seem the Broadcom 5709 network controller
>> hang [1]. It's running boot code 6.2.0 and NCSI code 2.0.11.
>>
>> We suspect completion timeouts may be occurring due to possible starvation.
>>
>> Is there anything significant/indicative from the state dumped?
>
> The firmware state seems to be ok, although we see some MSIX interrupts
> being asserted internally which is a sign that they don't get serviced.
>
> Is this easily reproducible? Can we send you some debug patches to dump
> more data?
>
> Thanks.
>
>>
>> Many thanks,
>> Daniel
>>
>> --- [1]
>>
>> bnx2: Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v2.2.3 (June
>> 27, 2012)
>> bnx2 0000:01:00.0 eth0: Broadcom NetXtreme II BCM5709 1000Base-T (C0)
>> PCI Express found at mem fc000000, IRQ 44, node addr e4:1f:13:80:70:03
>> bnx2 0000:01:00.1: enabling device (0140 -> 0142)
>> bnx2 0000:01:00.0: irq 72 for MSI/MSI-X
>> bnx2 0000:01:00.0: irq 73 for MSI/MSI-X
>> bnx2 0000:01:00.0: irq 74 for MSI/MSI-X
>> bnx2 0000:01:00.0: irq 75 for MSI/MSI-X
>> bnx2 0000:01:00.0: irq 76 for MSI/MSI-X
>> bnx2 0000:01:00.0: irq 77 for MSI/MSI-X
>> bnx2 0000:01:00.0: irq 78 for MSI/MSI-X
>> bnx2 0000:01:00.0: irq 79 for MSI/MSI-X
>> bnx2 0000:01:00.0 eth0: using MSIX
>> bnx2 0000:01:00.0 eth0: NIC Copper Link is Up, 1000 Mbps full duplex
>>
>> <an hour later>
>>
>> bnx2 0000:01:00.0 eth0: <--- start FTQ dump --->
>> bnx2 0000:01:00.0 eth0: RV2P_PFTQ_CTL 00010000
>> bnx2 0000:01:00.0 eth0: RV2P_TFTQ_CTL 00020000
>> bnx2 0000:01:00.0 eth0: RV2P_MFTQ_CTL 00004000
>> bnx2 0000:01:00.0 eth0: TBDR_FTQ_CTL 00004000
>> bnx2 0000:01:00.0 eth0: TDMA_FTQ_CTL 00010000
>> bnx2 0000:01:00.0 eth0: TXP_FTQ_CTL 00010000
>> bnx2 0000:01:00.0 eth0: TXP_FTQ_CTL 00010000
>> bnx2 0000:01:00.0 eth0: TPAT_FTQ_CTL 00010000
>> bnx2 0000:01:00.0 eth0: RXP_CFTQ_CTL 00008000
>> bnx2 0000:01:00.0 eth0: RXP_FTQ_CTL 00100000
>> bnx2 0000:01:00.0 eth0: COM_COMXQ_FTQ_CTL 00010000
>> bnx2 0000:01:00.0 eth0: COM_COMTQ_FTQ_CTL 00020000
>> bnx2 0000:01:00.0 eth0: COM_COMQ_FTQ_CTL 00010000
>> bnx2 0000:01:00.0 eth0: CP_CPQ_FTQ_CTL 00004000
>> bnx2 0000:01:00.0 eth0: CPU states:
>> bnx2 0000:01:00.0 eth0: 045000 mode b84c state 80001000 evt_mask 500 pc
>> 8001284 pc 8001284 instr 8e260000
>> bnx2 0000:01:00.0 eth0: 085000 mode b84c state 80005000 evt_mask 500 pc
>> 8000a4c pc 8000a5c instr 38420001
>> bnx2 0000:01:00.0 eth0: 0c5000 mode b84c state 80001000 evt_mask 500 pc
>> 8004c20 pc 8004c10 instr 32050003
>> bnx2 0000:01:00.0 eth0: 105000 mode b8cc state 80008000 evt_mask 500 pc
>> 8000aa0 pc 8000aa0 instr 8c420020
>> bnx2 0000:01:00.0 eth0: 145000 mode b880 state 80000000 evt_mask 500 pc
>> 800d978 pc 8009c18 instr afbf001c
>> bnx2 0000:01:00.0 eth0: 185000 mode b8cc state 80000000 evt_mask 500 pc
>> 8000cb0 pc 8000c58 instr 8ce800e8
>> bnx2 0000:01:00.0 eth0: <--- end FTQ dump --->
>> bnx2 0000:01:00.0 eth0: <--- start TBDC dump --->
>> bnx2 0000:01:00.0 eth0: TBDC free cnt: 32
>> bnx2 0000:01:00.0 eth0: LINE CID BIDX CMD VALIDS
>> bnx2 0000:01:00.0 eth0: 00 001180 0f40 00 [0]
>> bnx2 0000:01:00.0 eth0: 01 001180 0f48 00 [0]
>> bnx2 0000:01:00.0 eth0: 02 1db680 af58 f6 [0]
>> bnx2 0000:01:00.0 eth0: 03 0ddd00 fb58 fd [0]
>> bnx2 0000:01:00.0 eth0: 04 1fff80 ffc8 ef [0]
>> bnx2 0000:01:00.0 eth0: 05 1e9f80 9fa8 cf [0]
>> bnx2 0000:01:00.0 eth0: 06 1d7380 77e8 ff [0]
>> bnx2 0000:01:00.0 eth0: 07 1ddf00 7bb0 fb [0]
>> bnx2 0000:01:00.0 eth0: 08 1edb80 ff78 6f [0]
>> bnx2 0000:01:00.0 eth0: 09 1e9e80 ee58 9e [0]
>> bnx2 0000:01:00.0 eth0: 0a 17f780 fff8 74 [0]
>> bnx2 0000:01:00.0 eth0: 0b 1d7e00 6db8 fd [0]
>> bnx2 0000:01:00.0 eth0: 0c 1f7780 bff0 cf [0]
>> bnx2 0000:01:00.0 eth0: 0d 1bff80 bff8 ff [0]
>> bnx2 0000:01:00.0 eth0: 0e 17ff80 3de0 fe [0]
>> bnx2 0000:01:00.0 eth0: 0f 1ff780 98f0 ff [0]
>> bnx2 0000:01:00.0 eth0: 10 1f7f80 ffd8 ee [0]
>> bnx2 0000:01:00.0 eth0: 11 0e7780 eaa8 7f [0]
>> bnx2 0000:01:00.0 eth0: 12 1f9980 fde8 f7 [0]
>> bnx2 0000:01:00.0 eth0: 13 07ef80 ffc8 77 [0]
>> bnx2 0000:01:00.0 eth0: 14 1fbf80 57e8 bf [0]
>> bnx2 0000:01:00.0 eth0: 15 0fae80 df68 5b [0]
>> bnx2 0000:01:00.0 eth0: 16 0fff80 7ff8 be [0]
>> bnx2 0000:01:00.0 eth0: 17 1f7680 fed8 c6 [0]
>> bnx2 0000:01:00.0 eth0: 18 03e380 fe70 7b [0]
>> bnx2 0000:01:00.0 eth0: 19 0bcd80 7db8 7f [0]
>> bnx2 0000:01:00.0 eth0: 1a 0cb580 bbf0 ef [0]
>> bnx2 0000:01:00.0 eth0: 1b 0dfd80 dbf8 fb [0]
>> bnx2 0000:01:00.0 eth0: 1c 0bff80 7ff8 f3 [0]
>> bnx2 0000:01:00.0 eth0: 1d 0dfb80 f9f8 ec [0]
>> bnx2 0000:01:00.0 eth0: 1e 1e6e80 9be8 f7 [0]
>> bnx2 0000:01:00.0 eth0: 1f 1faf80 db78 52 [0]
>> bnx2 0000:01:00.0 eth0: <--- end TBDC dump --->
>> bnx2 0000:01:00.0 eth0: DEBUG: intr_sem[0] PCI_CMD[00100546]
>> bnx2 0000:01:00.0 eth0: DEBUG: PCI_PM[19002008] PCI_MISC_CFG[92000088]
>> bnx2 0000:01:00.0 eth0: DEBUG: EMAC_TX_STATUS[00000008]
>> EMAC_RX_STATUS[00000000]
>> bnx2 0000:01:00.0 eth0: DEBUG: RPM_MGMT_PKT_CTRL[40000088]
>> bnx2 0000:01:00.0 eth0: DEBUG: HC_STATS_INTERRUPT_STATUS[010600f9]
>> bnx2 0000:01:00.0 eth0: DEBUG: PBA[00000000]
>> bnx2 0000:01:00.0 eth0: <--- start MCP states dump --->
>> bnx2 0000:01:00.0 eth0: DEBUG: MCP_STATE_P0[0003610e] MCP_STATE_P1[0003610e]
>> bnx2 0000:01:00.0 eth0: DEBUG: MCP mode[0000b880] state[80000000]
>> evt_mask[00000500]
>> bnx2 0000:01:00.0 eth0: DEBUG: pc[0800d31c] pc[0800b46c] instr[a023f35c]
>> bnx2 0000:01:00.0 eth0: DEBUG: shmem states:
>> bnx2 0000:01:00.0 eth0: DEBUG: drv_mb[01030003] fw_mb[00000003]
>> link_status[8000006f]
>> bnx2 0000:01:00.0 eth0: DEBUG: dev_info_signature[44564903]
>> reset_type[01005254]
>> bnx2 0000:01:00.0 eth0: DEBUG: 000001c0: 01005254 42530083 0003610e 00000000
>> bnx2 0000:01:00.0 eth0: DEBUG: 000003cc: 44444444 44444444 44444444 00000a14
>> bnx2 0000:01:00.0 eth0: DEBUG: 000003dc: 0004ffff 00000000 00000000 00000000
>> bnx2 0000:01:00.0 eth0: DEBUG: 000003ec: 00000000 00000000 00000000 00000000
>> bnx2 0000:01:00.0 eth0: DEBUG: 0x3fc[0000ffff]
>> bnx2 0000:01:00.0 eth0: <--- end MCP states dump --->
>> bnx2 0000:01:00.0 eth0: NIC Copper Link is Down
--
Daniel J Blueman
Principal Software Engineer, Numascale Asia
^ permalink raw reply
* Re: [GIT] Networking
From: Paul Gortmaker @ 2013-02-22 2:26 UTC (permalink / raw)
To: Mark Lord
Cc: Linus Torvalds, David Miller, Andrew Morton, Network Development,
Linux Kernel Mailing List
In-Reply-To: <5126313E.2060608@start.ca>
On Thu, Feb 21, 2013 at 9:37 AM, Mark Lord <kernel@start.ca> wrote:
> On 13-02-20 10:05 PM, Linus Torvalds wrote:
>> On Wed, Feb 20, 2013 at 2:09 PM, David Miller <davem@davemloft.net> wrote:
>>>
>>> 15) Orphan and delete a bunch of pre-historic networking drivers from
>>> Paul Gortmaker.
>>
>> Nooo.... You killed the 3c501 and 3c503 drivers! Snif.
>>
>> I wonder if they still worked..
>
> I hope they're not really dead, because we still use them in several machines here
> as secondary interfaces for test rigs and whatnot.
>
> It's a tad early to be nuking support for such widespread devices.
Hi Mark,
Did you actually look at the drivers deleted? This was not a blanket
delete of _all_ ISA drivers, and I seriously doubt that you are using the
3c501 or 3c503 drivers. To be clear, it was a very selective removal of
drivers from the early 1990's, and so the common ISA drivers for the
widespread devices (like 3c509, and 8390 shared memory implementations)
continue to exist in mainline today.
Someday we will delete them, but it was not done here at this point in
time, so I hope people do not get confused on that.
Paul.
--
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net-next] IP_GRE: Fix IP-Identification.
From: Pravin B Shelar @ 2013-02-22 2:18 UTC (permalink / raw)
To: netdev; +Cc: edumazet, jesse, Pravin B Shelar
Use ip_select_ident_more() to generate and account ids for all
segments that can be used for segments of a gso packet.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
---
net/ipv4/af_inet.c | 6 ++++--
net/ipv4/ip_gre.c | 4 +++-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index e225a4e..2992f37 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1327,8 +1327,10 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb,
if (skb->next != NULL)
iph->frag_off |= htons(IP_MF);
offset += (skb->len - skb->mac_len - iph->ihl * 4);
- } else
- iph->id = htons(id++);
+ } else {
+ if (!(iph->frag_off & htons(IP_DF)))
+ iph->id = htons(id++);
+ }
iph->tot_len = htons(skb->len - skb->mac_len);
iph->check = 0;
iph->check = ip_fast_csum(skb_network_header(skb), iph->ihl);
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 5ef4da7..3c6f2e2 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -970,7 +970,9 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
iph->daddr = fl4.daddr;
iph->saddr = fl4.saddr;
iph->ttl = ttl;
- iph->id = 0;
+
+ ip_select_ident_more(iph, &rt->dst, NULL,
+ (skb_shinfo(skb)->gso_segs ?: 1) - 1);
if (ttl == 0) {
if (skb->protocol == htons(ETH_P_IP))
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] net: fec: Ensure that initialization is done prior to request_irq()
From: Frank Li @ 2013-02-22 1:44 UTC (permalink / raw)
To: Jim Baxter, Fabio Estevam; +Cc: netdev
In-Reply-To: <loom.20130222T020618-678@post.gmane.org>
This bug should be fixed in
http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git;a=commit;h=365cc174648cd7e9b11e522c3d5b07ccf3c60d99
2013/2/22 Jim Baxter <jim_baxter@mentor.com>:
> here is a divide by zero error.
>
> If I enable these 3 kernel hacking options;
> CONFIG_DEBUG_SPINLOCK: -- Spinlock and rw-lock debugging: basic checks
> CONFIG_DEBUG_LOCK_ALLOC: -- Lock debugging: detect incorrect freeing of live
> locks
> CONFIG_PROVE_LOCKING: -- Lock debugging: prove locking correctness
^ permalink raw reply
* Re: [PATCH] net: fec: Ensure that initialization is done prior to request_irq()
From: Jim Baxter @ 2013-02-22 1:13 UTC (permalink / raw)
To: netdev
In-Reply-To: <20130221.153812.2039434956437238374.davem@davemloft.net>
David Miller <davem <at> davemloft.net> writes:
>
> From: Fabio Estevam <festevam <at> gmail.com>
> Date: Thu, 21 Feb 2013 17:29:46 -0300
>
> > On Thu, Feb 21, 2013 at 5:27 PM, David Miller <davem <at> davemloft.net>
wrote:
> >
> >> Looks good, did you test this yourself or should we wait for others to
> >> test it out?
> >
> > Yes, I tested it myself. I was the one who reported this bug and this
> > fixes the problem.
>
> Perfect, applied to 'net', thanks!
>
There is a divide by zero error.
If I enable these 3 kernel hacking options;
CONFIG_DEBUG_SPINLOCK: -- Spinlock and rw-lock debugging: basic checks
CONFIG_DEBUG_LOCK_ALLOC: -- Lock debugging: detect incorrect freeing of live
locks
CONFIG_PROVE_LOCKING: -- Lock debugging: prove locking correctness
I get this error:
[ 17.895723] Division by zero in kernel.
[ 17.899571] Backtrace:
[ 17.902094] [<80012564>] (dump_backtrace+0x0/0x10c) from [<8056deec>]
(dump_stack+0x18/0x1c)
[ 17.910539] r6:bfba8500 r5:8075c950 r4:bfba8000 r3:bfbd0000
[ 17.916284] [<8056ded4>] (dump_stack+0x0/0x1c) from [<80012688>]
(__div0+0x18/0x20)
[ 17.923968] [<80012670>] (__div0+0x0/0x20) from [<802829c4>] (Ldiv0+0x8/0x10)
[ 17.931140] [<80398534>] (fec_ptp_start_cyclecounter+0x0/0x110) from
[<80394f64>] (fec_restart+0x6c8/0x754)
[ 17.940898] [<8039489c>] (fec_restart+0x0/0x754) from [<803969a0>]
(fec_enet_adjust_link+0xdc/0x108)
[ 17.950046] [<803968c4>] (fec_enet_adjust_link+0x0/0x108) from [<80390bc4>]
(phy_state_machine+0x178/0x534)
[ 17.959791] r8:00000000 r7:00000000 r6:bf80da5c r5:bf80da04 r4:bf80d800
r3:00000001
[ 17.967750] [<80390a4c>] (phy_state_machine+0x0/0x534) from [<8003be40>]
(process_one_work+0x1c0/0x464)
[ 17.977147] r8:00000000 r7:8150a300 r6:815071c0 r5:bf850c00 r4:bf80da04
r3:bfbd0000
[ 17.985097] [<8003bc80>] (process_one_work+0x0/0x464) from [<8003ea64>]
(worker_thread+0x134/0x3f0)
[ 17.994165] [<8003e930>] (worker_thread+0x0/0x3f0) from [<8004420c>]
(kthread+0xac/0xb8)
[ 18.002271] [<80044160>] (kthread+0x0/0xb8) from [<8000ebf0>]
(ret_from_fork+0x14/0x24)
[ 18.010280] r7:00000000 r6:00000000 r5:80044160 r4:bf875e10
^ permalink raw reply
* Re: [PATCH] ipv6: use a stronger hash for tcp
From: David Miller @ 2013-02-22 0:48 UTC (permalink / raw)
To: andi; +Cc: eric.dumazet, netdev, ncardwell, ycheng
In-Reply-To: <m2fw0pxm6b.fsf@firstfloor.org>
From: Andi Kleen <andi@firstfloor.org>
Date: Thu, 21 Feb 2013 15:49:16 -0800
> murmur3
Two multiplies per mix(), no thanks. We might as well use a universal
hash like the one we use for ARP hashing, which incurs only one
multiply.
jhash() is definitely going to perform much better than murmur3 on a
wide range of cpus.
jhash() is just a series of simple shifts and additions to mix the
data (which every cpu can do cheaply), whereas murmur3 is jhash()'s
overhead plus two multiplies per mix pass.
For our purposes, therefore, Jenkins is still superior.
> cityhash
And cityhash uses the two multiply mix() function from murmur3, thus
has the same problem.
These hashes actually look quite terrible for kernel hash table hashes.
^ permalink raw reply
* Re: [PATCHv2 vringh 1/3] remoteproc: Add support for vringh (Host vrings)
From: Rusty Russell @ 2013-02-22 0:42 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: Dmitry Tarnyagin, Sjur Brændeland, Linus Walleij, Ido Yariv,
linux-kernel@vger.kernel.org, Erwan Yvin, virtualization, netdev,
David S. Miller, Sjur Brændeland
In-Reply-To: <CAK=WgbYt6mQeJ+4kCFsfGppfaq3JcS6OedNE+ZGd4itfR1hU4A@mail.gmail.com>
Ohad Ben-Cohen <ohad@wizery.com> writes:
> On Thu, Feb 21, 2013 at 8:37 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>> Hmm... I clearly jumped the gun, assuming consensus was already reached.
>> I have put these patches *back* into pending-rebases, and they will not
>> be merged this merge window.
>
> Thanks.
>
> What do you think about creating some virtio-level wrappers for the
> vringh handlers?
>
> I don't think we're going to stop with caif as the only vringh user,
> and it could be nice if we follow the virtio spirit of decoupling the
> drivers from the low level implementation. It sure did prove itself
> when the remoteproc use cases started showing up, and it's neat.
The problem space is a bit different. My immediate concern is getting
vhost (and thus vhost_net/blk) to use vringh: I wanted to unify the
in-userspace and in-kernelspace ring implementations. We don't have
that issue in virtqueue.c.
vhost is (will be) the higher abstraction for in-userspace rings,
perhaps we want an equivalent for in-kernelspace rings. I'm happy to
look at patches, but I don't immediately see what it would look like...
Thanks,
Rusty.
^ permalink raw reply
* Re: [PATCH v6 00/46] CPU hotplug: stop_machine()-free CPU hotplug
From: Rusty Russell @ 2013-02-22 0:31 UTC (permalink / raw)
To: Srivatsa S. Bhat, tglx, peterz, tj, oleg, paulmck, mingo, akpm,
namhyung
Cc: rostedt, wangyun, xiaoguangrong, rjw, sbw, fweisbec, linux,
nikunj, srivatsa.bhat, linux-pm, linux-arch, linux-arm-kernel,
linuxppc-dev, netdev, linux-doc, linux-kernel, walken,
vincent.guittot
In-Reply-To: <20130218123714.26245.61816.stgit@srivatsabhat.in.ibm.com>
"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com> writes:
> Hi,
>
> This patchset removes CPU hotplug's dependence on stop_machine() from the CPU
> offline path and provides an alternative (set of APIs) to preempt_disable() to
> prevent CPUs from going offline, which can be invoked from atomic context.
> The motivation behind the removal of stop_machine() is to avoid its ill-effects
> and thus improve the design of CPU hotplug. (More description regarding this
> is available in the patches).
If you're doing a v7, please put your benchmark results somewhere!
The obvious place is in the 44/46.
Thanks,
Rusty.
^ permalink raw reply
* Hello dear,
From: Alice Efuna @ 2013-02-22 0:14 UTC (permalink / raw)
Hello dear,
I am miss Alice Efuna 24years and single, hope am not offending you by
expressing my feelings of having a friendship or relationship with you, can you
please write to me back with my email below for more communication and exchange
of pictures to know more about each other for a better unions-hip.
Thanks,
Yours Alice.
^ permalink raw reply
* Re: [PATCH] ipv6: use a stronger hash for tcp
From: Hannes Frederic Sowa @ 2013-02-22 0:14 UTC (permalink / raw)
To: Andi Kleen; +Cc: David Miller, eric.dumazet, netdev, ncardwell, ycheng
In-Reply-To: <m2fw0pxm6b.fsf@firstfloor.org>
On Thu, Feb 21, 2013 at 03:49:16PM -0800, Andi Kleen wrote:
> David Miller <davem@davemloft.net> writes:
> >
> > I bet we can consolidate this slightly, to make it less
> > expensive yet not give up much in terms of protection. Two
> > jhash3word()'s is quite a lot.
>
> jhash is not really the state of the art for general hashing anymore,
> murmur3 or cityhash are generally considered faster/possibly better.
murmur3 and cityhash are broken in terms of collision resistance. I have
not heard anything about jenkins being affected (but have not searched
either). SipHash is a relativly new hash function specifically designed
to protect against hashdos, but I fear it could be more expansive for very
small inputs: https://131002.net/siphash/
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] ip_gre: propogate target device GSO capability to the tunnel device
From: pravin @ 2013-02-21 23:53 UTC (permalink / raw)
To: Dmitry Kravkov; +Cc: davem, netdev
In-Reply-To: <1361485805.21950.6.camel@lb-tlvb-dmitry>
On Thu, Feb 21, 2013 at 2:30 PM, Dmitry Kravkov <dmitry@broadcom.com> wrote:
> On Tue, 2013-02-19 at 10:39 -0800, pravin wrote:
>> On Mon, Feb 18, 2013 at 11:50 AM, Dmitry Kravkov <dmitry@broadcom.com> wrote:
>> >
>> > Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
>> > ---
>> > Changes from v1: fixed email address
>> >
>> >
>> > net/ipv4/ip_gre.c | 10 ++++++++--
>> > 1 files changed, 8 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
>> > index cdc31ac..31bc941 100644
>> > --- a/net/ipv4/ip_gre.c
>> > +++ b/net/ipv4/ip_gre.c
>> > @@ -1103,8 +1103,14 @@ static int ipgre_tunnel_bind_dev(struct net_device *dev)
>> > tunnel->hlen = addend;
>> > /* TCP offload with GRE SEQ is not supported. */
>> > if (!(tunnel->parms.o_flags & GRE_SEQ)) {
>> > - dev->features |= NETIF_F_GSO_SOFTWARE;
>> > - dev->hw_features |= NETIF_F_GSO_SOFTWARE;
>> > + /* device supports enc gso offload*/
>> > + if (tdev->hw_enc_features & NETIF_F_GRE_GSO) {
>> > + dev->features |= NETIF_F_TSO;
>> > + dev->hw_features |= NETIF_F_TSO;
>> > + } else {
>> > + dev->features |= NETIF_F_GSO_SOFTWARE;
>> > + dev->hw_features |= NETIF_F_GSO_SOFTWARE;
>> > + }
>> > }
>>
>> I am not sure about this change, Are you trying to limit GRE TSO to
>> just IPV4 in case of GRE offload in hardware?
>
>
> This mostly reverts previous patch, but also disables GSO when CSUM is
> set.
>
> ---
> net/ipv4/ip_gre.c | 14 ++++----------
> 1 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index 0de54cd..aae2d4b 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -1107,16 +1107,10 @@ static int ipgre_tunnel_bind_dev(struct
> net_device *dev)
> mtu = 68;
>
> tunnel->hlen = addend;
> - /* TCP offload with GRE SEQ is not supported. */
> - if (!(tunnel->parms.o_flags & GRE_SEQ)) {
> - /* device supports enc gso offload*/
> - if (tdev->hw_enc_features & NETIF_F_GRE_GSO) {
> - dev->features |= NETIF_F_TSO;
> - dev->hw_features |= NETIF_F_TSO;
> - } else {
> - dev->features |= NETIF_F_GSO_SOFTWARE;
> - dev->hw_features |= NETIF_F_GSO_SOFTWARE;
> - }
> + /* TCP offload with GRE SEQ or CSUM is not supported. */
> + if (!(tunnel->parms.o_flags & (GRE_SEQ|GRE_CSUM))) {
> + dev->features |= NETIF_F_GSO_SOFTWARE;
> + dev->hw_features |= NETIF_F_GSO_SOFTWARE;
> }
>
> return mtu;
This narrows down definition of NETIF_F_GRE_GSO. Is it required for
hardware offload?
> --
> 1.7.7.2
>
>
>> >
>> > return mtu;
>> > --
>> > 1.7.7.2
>> >
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe netdev" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
>
^ permalink raw reply
* Re: [PATCH] ipv6: use a stronger hash for tcp
From: Andi Kleen @ 2013-02-21 23:49 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev, ncardwell, ycheng
In-Reply-To: <20130221.181822.1234155083700257175.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
>
> I bet we can consolidate this slightly, to make it less
> expensive yet not give up much in terms of protection. Two
> jhash3word()'s is quite a lot.
jhash is not really the state of the art for general hashing anymore,
murmur3 or cityhash are generally considered faster/possibly better.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] ip_gre: allow CSUM capable devices to handle packets
From: pravin @ 2013-02-21 23:46 UTC (permalink / raw)
To: Dmitry Kravkov; +Cc: davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <1361485562.21950.3.camel@lb-tlvb-dmitry>
On Thu, Feb 21, 2013 at 2:26 PM, Dmitry Kravkov <dmitry@broadcom.com> wrote:
> On Tue, 2013-02-19 at 15:03 -0800, pravin wrote:
>> On Tue, Feb 19, 2013 at 11:20 AM, Dmitry Kravkov <dmitry@broadcom.com> wrote:
>> >
>> >> -----Original Message-----
>> >> From: pravin [mailto:pravin.shelar@gmail.com]
>> >> Sent: Tuesday, February 19, 2013 8:28 PM
>> >> To: Dmitry Kravkov
>> >> Cc: davem@davemloft.net; netdev@vger.kernel.org
>> >> Subject: Re: [PATCH net-next v2 1/2] ip_gre: allow CSUM capable devices to
>> >> handle packets
>> >>
>> >> On Mon, Feb 18, 2013 at 11:50 AM, Dmitry Kravkov <dmitry@broadcom.com>
>> >> wrote:
>> >> > If device is not able to handle checksumming it will
>> >> > be handled in dev_xmit
>> >> >
>> >> > Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
>> >> > ---
>> >> > Changes from v1: fixed email address
>> >> >
>> >> > net/ipv4/ip_gre.c | 7 ++-----
>> >> > 1 files changed, 2 insertions(+), 5 deletions(-)
>> >> >
>> >> > diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
>> >> > index a56f118..cdc31ac 100644
>> >> > --- a/net/ipv4/ip_gre.c
>> >> > +++ b/net/ipv4/ip_gre.c
>> >> > @@ -745,12 +745,9 @@ static struct sk_buff *handle_offloads(struct sk_buff
>> >> *skb)
>> >> > goto error;
>> >> > skb_shinfo(skb)->gso_type |= SKB_GSO_GRE;
>> >> > return skb;
>> >> > - } else if (skb->ip_summed == CHECKSUM_PARTIAL) {
>> >> > - err = skb_checksum_help(skb);
>> >> > - if (unlikely(err))
>> >> > - goto error;
>> >> > }
>> >> > - skb->ip_summed = CHECKSUM_NONE;
>> >> > + if (skb->ip_summed != CHECKSUM_PARTIAL)
>> >> > + skb->ip_summed = CHECKSUM_NONE;
>> >> >
>> >> > return skb;
>> >> >
>> >> > --
>> >> > 1.7.7.2
>> >> >
>> >> >
>> >>
>> >> This patch breaks GRE tunnel with GRE_CSUM. since GRE_CSUM need
>> >> complete IP packet to checksum entire GRE payload.
>> >
>> > Testing for o_flags&GRE_CSUM does not look too hurt here, since it will be used in ipgre_tunnel_xmit() later on
>> > This is the only problematic case, right?
>> >
>>
>> It does not work for me. I have GRE device with csum on. Ping works
>> fine but Netperf is not working.
>> Looking at code, I am not sure how tcp will work if inner packet TCP
>> checksum is calculated after GRE_CSUM calculation.
>
>
> Fixes handling when CSUM or SEQ flags are set - via skb_checksum_help()
> ---
> Tested with each mode (separately)
>
> net/ipv4/ip_gre.c | 14 +++++++++++---
> 1 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index 5ef4da7..0de54cd 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -735,7 +735,8 @@ drop:
> return 0;
> }
>
> -static struct sk_buff *handle_offloads(struct sk_buff *skb)
> +static struct sk_buff *handle_offloads(struct ip_tunnel *tunnel,
> + struct sk_buff *skb)
> {
> int err;
>
> @@ -745,8 +746,15 @@ static struct sk_buff *handle_offloads(struct
> sk_buff *skb)
> goto error;
> skb_shinfo(skb)->gso_type |= SKB_GSO_GRE;
> return skb;
> + } else if (tunnel->parms.o_flags&(GRE_SEQ|GRE_CSUM) &&
> + skb->ip_summed == CHECKSUM_PARTIAL) {
> + err = skb_checksum_help(skb);
> + if (unlikely(err))
> + goto error;
> }
> - if (skb->ip_summed != CHECKSUM_PARTIAL)
> +
> + if (skb->ip_summed != CHECKSUM_PARTIAL ||
> + tunnel->parms.o_flags&(GRE_SEQ|GRE_CSUM))
> skb->ip_summed = CHECKSUM_NONE;
>
We can simplify this by dropping check of o_flags.
> return skb;
> @@ -776,7 +784,7 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff
> *skb, struct net_device *dev
> int err;
> int pkt_len;
>
> - skb = handle_offloads(skb);
> + skb = handle_offloads(tunnel, skb);
> if (IS_ERR(skb)) {
> dev->stats.tx_dropped++;
> return NETDEV_TX_OK;
> --
> 1.7.7.2
>
>
>> Thanks,
>> Pravin.
>>
>
>
>
^ permalink raw reply
* Re: [net PATCH 0/3] qlcnic: bug fixes
From: David Miller @ 2013-02-21 23:18 UTC (permalink / raw)
To: jitendra.kalsaria; +Cc: netdev, sony.chacko, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1361480988-12829-1-git-send-email-jitendra.kalsaria@qlogic.com>
From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Date: Thu, 21 Feb 2013 16:09:45 -0500
> Please apply to net.
Series applied, thanks.
^ 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