netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Tue, 12 Jul 2016 08:56:56 +0300	[thread overview]
Message-ID: <20160712085656.79f1c5fc@halley> (raw)
In-Reply-To: <20160709132230.GD2067@breakpoint.cc>

On Sat, 9 Jul 2016 15:22:30 +0200 Florian Westphal <fw@strlen.de> wrote:
> Shmulik Ladkani <shmulik.ladkani@ravellosystems.com> wrote:
> > I'd appreciate any suggestion how to determine traffic is local OTHER
> > THAN testing IPSKB_FORWARDED; If we have such a way, there wouldn't be an
> > impact on local traffic.
> >   
> > > 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.

Regards,
Shmulik

  parent reply	other threads:[~2016-07-12  5:57 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 [this message]
2016-07-13 14:00             ` Shmulik Ladkani
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=20160712085656.79f1c5fc@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).