From: Shmulik Ladkani <shmulik.ladkani@ravellosystems.com>
To: Florian Westphal <fw@strlen.de>,
Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
shmulik.ladkani@gmail.com, netdev@vger.kernel.org,
Alexander Duyck <alexander.duyck@gmail.com>,
Tom Herbert <tom@herbertland.com>
Subject: Re: [PATCH] net: ip_finish_output_gso: If skb_gso_network_seglen exceeds MTU, do segmentation even for non IPSKB_FORWARDED skbs
Date: Wed, 13 Jul 2016 17:00:38 +0300 [thread overview]
Message-ID: <20160713170038.1d02eb2b@halley> (raw)
In-Reply-To: <20160712085656.79f1c5fc@halley>
Hi Florian, Hannes,
On Tue, 12 Jul 2016 08:56:56 +0300 Shmulik Ladkani <shmulik.ladkani@ravellosystems.com> wrote:
> On Sat, 9 Jul 2016 15:22:30 +0200 Florian Westphal <fw@strlen.de> wrote:
> > >
> > > > What about setting IPCB FORWARD flag in iptunnel_xmit if
> > > > skb->skb_iif != 0... instead?
>
> I've came up with a suggestion that does not abuse IPSKB_FORWARDED,
> while properly addressing the use case (and similar ones), without
> introducing the cost of entering 'skb_gso_validate_mtu' in the local
> case.
>
> How about:
>
> @@ -220,12 +220,15 @@ static int ip_finish_output_gso(struct net *net, struct sock *sk,
> struct sk_buff *skb, unsigned int mtu)
> {
> netdev_features_t features;
> + int local_trusted_gso;
> struct sk_buff *segs;
> int ret = 0;
>
> - /* common case: locally created skb or seglen is <= mtu */
> - if (((IPCB(skb)->flags & IPSKB_FORWARDED) == 0) ||
> - skb_gso_validate_mtu(skb, mtu))
> + local_trusted_gso = (IPCB(skb)->flags & IPSKB_FORWARDED) == 0 &&
> + !(skb_shinfo(skb)->gso_type & SKB_GSO_DODGY);
> + /* common case: locally created skb from a trusted gso source or
> + * seglen is <= mtu */
> + if (local_trusted_gso || skb_gso_validate_mtu(skb, mtu))
> return ip_finish_output2(net, sk, skb);
>
> /* Slowpath - GSO segment length is exceeding the dst MTU.
>
> This well addresses the usecase where we have gso-skb arriving from an
> untrusted source, thus its gso_size is out of our control (e.g. tun/tap,
> macvtap, af_packet, xen-netfront...).
>
> Locally "gso trusted" skbs (the common case) will NOT suffer the
> additional (possibly costy) call to 'skb_gso_validate_mtu'.
>
> Also, if IPSKB_FORWARDED is true, behavior stays exactly the same.
Any commnets regarding the latest suggestion above?
I'd like to post it as v2 - if it is in the right direction.
It handles the problem of gso_size values which are not in host's
control, it addresses the usecase described, and has a benefit of not
overloading IPSKB_FORWARDED with a new semantic that might be hard to
maintain.
PS:
Also, if we'd like to pinpoint it even further, we can:
local_trusted_gso = (IPCB(skb)->flags & IPSKB_FORWARDED) == 0 &&
(!sk || !(skb_shinfo(skb)->gso_type & SKB_GSO_DODGY));
Which ensures only the following conditions go to the expensive
skb_gso_validate_mtu:
1. IPSKB_FORWARDED is on
2. IPSKB_FORWARDED is off, but sk exists and gso_size is untrusted.
Meaning: we have a packet arriving from higher layers (sk is set)
with a gso_size out of host's control.
This fine-tuining leaves standard l2 bridging case (e.g 2x taps bridged)
of a gso skb unaffected, as sk would be NULL.
Many thanks,
Shmulik
next prev parent reply other threads:[~2016-07-13 14:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-05 12:35 [PATCH] net: ip_finish_output_gso: If skb_gso_network_seglen exceeds MTU, do segmentation even for non IPSKB_FORWARDED skbs Shmulik Ladkani
2016-07-05 13:03 ` Florian Westphal
2016-07-05 14:05 ` Shmulik Ladkani
2016-07-09 3:12 ` David Miller
2016-07-09 9:06 ` Florian Westphal
2016-07-09 9:00 ` Florian Westphal
2016-07-09 12:30 ` Shmulik Ladkani
2016-07-09 13:22 ` Florian Westphal
2016-07-10 7:51 ` Shmulik Ladkani
2016-07-11 8:15 ` Florian Westphal
2016-07-11 13:32 ` Hannes Frederic Sowa
2016-07-12 5:56 ` Shmulik Ladkani
2016-07-13 14:00 ` Shmulik Ladkani [this message]
2016-07-14 13:12 ` Hannes Frederic Sowa
2016-07-14 14:13 ` Shmulik Ladkani
2016-07-14 23:32 ` Hannes Frederic Sowa
2016-07-10 20:14 ` Shmulik Ladkani
2016-07-11 8:13 ` Florian Westphal
2016-07-09 15:10 ` Hannes Frederic Sowa
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=20160713170038.1d02eb2b@halley \
--to=shmulik.ladkani@ravellosystems.com \
--cc=alexander.duyck@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=hannes@stressinduktion.org \
--cc=netdev@vger.kernel.org \
--cc=shmulik.ladkani@gmail.com \
--cc=tom@herbertland.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).