>From 0aa52d88bdf6bc22fed80beb175a6dfe420dfabd Mon Sep 17 00:00:00 2001 From: Cong Wang <amw...@redhat.com<mailto:amw...@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 <je...@nicira.com<mailto:je...@nicira.com>> Cc: David S. Miller <da...@davemloft.net<mailto:da...@davemloft.net>> Signed-off-by: Cong Wang <amw...@redhat.com<mailto:amw...@redhat.com>> Signed-off-by: David S. Miller <da...@davemloft.net<mailto:da...@davemloft.net>> [jesse: backport to kernels before 3.9 and add to tunnel.c] Signed-off-by: Jesse Gross <je...@nicira.com<mailto:je...@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
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
