All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Florian Westphal <fw@strlen.de>
Cc: Tobias Brunner <tobias@strongswan.org>,
	netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Marcelo Ricardo Leitner <mleitner@redhat.com>
Subject: Re: Problems with fragments since gso skb forwarding changes in virtual environment
Date: Tue, 8 Apr 2014 17:36:19 +0200	[thread overview]
Message-ID: <20140408153619.GE31953@breakpoint.cc> (raw)
In-Reply-To: <20140408143318.GD31953@breakpoint.cc>

Florian Westphal <fw@strlen.de> wrote:

[ cc'd Eric ]

> Thanks for clarifying. In this case there is another problem as well as
> no fragments should be generated in the forwarding path if the outgoing mtu
> is not reduced.
> 
> Most likely a problem with udp gso + skb_gso_network_seglen().

Indeed, the problem is here:

unsigned int skb_gso_transport_seglen(const struct sk_buff *skb)
{
       const struct skb_shared_info *shinfo = skb_shinfo(skb);
       unsigned int hdr_len;

       if (likely(shinfo->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6)))
               hdr_len = tcp_hdrlen(skb);
       else
               hdr_len = sizeof(struct udphdr);
       return hdr_len + shinfo->gso_size;
}

For large GSO UDP packet received via virtio shinfo->gso_size is 1480 (mtu 1500).

Thus skb_gso_transport_seglen() claims transport seglen of 1488 which makes fwd
path think we're trying to send 1508 byte segments.

I am not familiar with UFO; setting hdr_len = 0 in else clause makes things
work for me.  I'll see if the sizeof(struct udphdr) is bogus for ufo or if ->gso_size
is wrong.

      reply	other threads:[~2014-04-08 15:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-07 16:04 Problems with fragments since gso skb forwarding changes in virtual environment Tobias Brunner
2014-04-07 23:46 ` Florian Westphal
2014-04-08  0:05   ` David Miller
2014-04-08  0:26     ` Florian Westphal
2014-04-08 12:24   ` Tobias Brunner
2014-04-08 14:33     ` Florian Westphal
2014-04-08 15:36       ` Florian Westphal [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140408153619.GE31953@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=mleitner@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=tobias@strongswan.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.