Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S943052AbcJ0Wfb (ORCPT ); Thu, 27 Oct 2016 18:35:31 -0400 Received: from mail-qk0-f196.google.com ([209.85.220.196]:34901 "EHLO mail-qk0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934322AbcJ0Wf3 (ORCPT ); Thu, 27 Oct 2016 18:35:29 -0400 MIME-Version: 1.0 In-Reply-To: <1477301332-23954-6-git-send-email-jkbs@redhat.com> References: <1477301332-23954-1-git-send-email-jkbs@redhat.com> <1477301332-23954-6-git-send-email-jkbs@redhat.com> From: Tom Herbert Date: Thu, 27 Oct 2016 15:35:27 -0700 Message-ID: Subject: Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet To: Jakub Sitnicki Cc: Linux Kernel Network Developers , LKML , "David S. Miller" , Alexey Kuznetsov , James Morris , Hideaki YOSHIFUJI , Patrick McHardy Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2527 Lines: 69 On Mon, Oct 24, 2016 at 2:28 AM, Jakub Sitnicki wrote: > Same as for the transmit path, let's do our best to ensure that received > ICMP errors that may be subject to forwarding will be routed the same > path as flow that triggered the error, if it was going in the opposite > direction. > Unfortunately our ability to do this is generally quite limited. This patch will select the route for multipath, but I don't believe sets the same link in LAG and definitely can't help switches doing ECMP to route the ICMP packet in the same way as the flow would be. Did you see a problem that warrants solving this case? Tom > Signed-off-by: Jakub Sitnicki > --- > net/ipv6/route.c | 26 ++++++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > > diff --git a/net/ipv6/route.c b/net/ipv6/route.c > index 1184c2b..c0f38ea 100644 > --- a/net/ipv6/route.c > +++ b/net/ipv6/route.c > @@ -1150,6 +1150,30 @@ struct dst_entry *ip6_route_input_lookup(struct net *net, > } > EXPORT_SYMBOL_GPL(ip6_route_input_lookup); > > +static u32 ip6_multipath_icmp_hash(const struct sk_buff *skb) > +{ > + const struct icmp6hdr *icmph = icmp6_hdr(skb); > + const struct ipv6hdr *inner_iph; > + struct ipv6hdr _inner_iph; > + > + if (icmph->icmp6_type != ICMPV6_DEST_UNREACH && > + icmph->icmp6_type != ICMPV6_PKT_TOOBIG && > + icmph->icmp6_type != ICMPV6_TIME_EXCEED && > + icmph->icmp6_type != ICMPV6_PARAMPROB) > + goto standard_hash; > + > + inner_iph = skb_header_pointer( > + skb, skb_transport_offset(skb) + sizeof(*icmph), > + sizeof(_inner_iph), &_inner_iph); > + if (!inner_iph) > + goto standard_hash; > + > + return icmpv6_multipath_hash(inner_iph); > + > +standard_hash: > + return 0; /* compute it later, if needed */ > +} > + > void ip6_route_input(struct sk_buff *skb) > { > const struct ipv6hdr *iph = ipv6_hdr(skb); > @@ -1168,6 +1192,8 @@ void ip6_route_input(struct sk_buff *skb) > tun_info = skb_tunnel_info(skb); > if (tun_info && !(tun_info->mode & IP_TUNNEL_INFO_TX)) > fl6.flowi6_tun_key.tun_id = tun_info->key.tun_id; > + if (unlikely(fl6.flowi6_proto == IPPROTO_ICMPV6)) > + fl6.mp_hash = ip6_multipath_icmp_hash(skb); I will point out that this is only > skb_dst_drop(skb); > skb_dst_set(skb, ip6_route_input_lookup(net, skb->dev, &fl6, flags)); > } > -- > 2.7.4 >