[ovs-dev] skb_gso_segment() bad offloads warnings fixed?

[Jesse Gross]

On Thu, May 23, 2013 at 4:49 AM, Rajahalme, Jarno (NSN - FI/Espoo)
<jarno.rajahalme at nsn.com> wrote:
> From 0aa52d88bdf6bc22fed80beb175a6dfe420dfabd Mon Sep 17 00:00:00 2001
> From: Cong Wang <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>
> Cc: David S. Miller <davem at davemloft.net>
> Signed-off-by: Cong Wang <amwang at redhat.com>
> Signed-off-by: David S. Miller <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>
> ---
>
> ...
>
> 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.

The upstream commit is not really right - the check should depend on
the origin of the packet, not the location in the networking stack
processing it. Most of the time these are somewhat the same but
obviously when bridging, received packets commonly go through the
transmit path. In the OVS tunnel code, we know that we are doing
bridging so I used the looser check.