[ovs-dev] skb_gso_segment() bad offloads warnings fixed?
Rajahalme, Jarno (NSN - FI/Espoo)
jarno.rajahalme at nsn.com
Thu May 23 11:49:44 UTC 2013
>From 0aa52d88bdf6bc22fed80beb175a6dfe420dfabd Mon Sep 17 00:00:00 2001
From: Cong Wang <amwang at redhat.com<mailto:amwang at redhat.com>>
Date: Wed, 6 Feb 2013 14:40:36 -0800
Subject: [PATCH] datapath: adjust skb_gso_segment() for calling in rx path
skb_gso_segment() is almost always called in tx path,
except for openvswitch. It calls this function when
it receives the packet and tries to queue it to user-space.
In this special case, the ->ip_summed check inside
skb_gso_segment() is no longer true, as ->ip_summed value
has different meanings on rx path.
This patch adjusts skb_gso_segment() so that we can at least
avoid such warnings on checksum.
Cc: Jesse Gross <jesse at nicira.com<mailto:jesse at nicira.com>>
Cc: David S. Miller <davem at davemloft.net<mailto:davem at davemloft.net>>
Signed-off-by: Cong Wang <amwang at redhat.com<mailto:amwang at redhat.com>>
Signed-off-by: David S. Miller <davem at davemloft.net<mailto:davem at davemloft.net>>
[jesse: backport to kernels before 3.9 and add to tunnel.c]
Signed-off-by: Jesse Gross <jesse at nicira.com<mailto:jesse at nicira.com>>
---
...
diff --git a/datapath/tunnel.c b/datapath/tunnel.c
index 6193891..7c2560f 100644
--- a/datapath/tunnel.c
+++ b/datapath/tunnel.c
@@ -435,7 +435,7 @@ static struct sk_buff *handle_offloads(struct sk_buff *skb,
if (skb_is_gso(skb)) {
struct sk_buff *nskb;
- nskb = skb_gso_segment(skb, 0);
+ nskb = __skb_gso_segment(skb, 0, false);
if (IS_ERR(nskb)) {
kfree_skb(skb);
err = PTR_ERR(nskb);
--
1.7.9.5
What is the logic of using bool tx_path = false on this call in tunnel.c, as this is called on ovs_tnl_send() which is on the tx path?
Is it so that this avoids the (skb->ip_summed != CHECKSUM_PARTIAL) comparison that leads to skb_warn_bad_offload(skb)?
If this is the case, how likely is the new comparison (skb->ip_summed == CHECKSUM_NONE) in Linux 3.9 to resolve the problem with these warnings?
We have a case in which an OpenStack (grizzly) controller node is filling the disk with these kernel warnings and it would be nice to have this resolved. I guess turning off GSO on the nic involved should work as an interim solution, but it would be nice to understand what is going on here.
Jarno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20130523/e8ef405b/attachment-0003.html>
More information about the dev
mailing list