On Sat, 9 Jul 2016 15:22:30 +0200 Florian Westphal <[email protected]> wrote:
> Shmulik Ladkani <[email protected]> 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
