From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5040BC43381 for ; Fri, 22 Feb 2019 10:26:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A153E20645 for ; Fri, 22 Feb 2019 10:26:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=cumulusnetworks.com header.i=@cumulusnetworks.com header.b="SQUtfubI" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726872AbfBVK0o (ORCPT ); Fri, 22 Feb 2019 05:26:44 -0500 Received: from mail-wm1-f67.google.com ([209.85.128.67]:54286 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726122AbfBVK0o (ORCPT ); Fri, 22 Feb 2019 05:26:44 -0500 Received: by mail-wm1-f67.google.com with SMTP id a62so1457896wmh.4 for ; Fri, 22 Feb 2019 02:26:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cumulusnetworks.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=lFpukBcBwB4+rgH+bE9tGRegnQ7JSyiryIDaNwbJkzI=; b=SQUtfubI1YPETZ2NOHXCT8iPm2N3wLk4KcoWLAiABBDJOB6TGnxkMVTGlZCXfa8CSe QRVHWCeTgbcVObBqrRhlTYfNStYScaViaW00g426VRDKu8Nxx9t/BfVxzPS9uZld1EYp /ZSZnj3fUhPkB9k8YUUw2346ySJsK+YeNlF0I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lFpukBcBwB4+rgH+bE9tGRegnQ7JSyiryIDaNwbJkzI=; b=RJQ66VOUKABMLx7MyBD3fCcgN9YQPCogOxoAqx49G2eRL308BhvwH87stBACpzniXm 9bRTsIbkYt/TYuQDn4EK7v7kIKyG531L39hUHcg9JQgkUGDSmYqPdbVb8hdHo1SFvhdI k1Vvf57zutJJ6rhiqG8i/pHv2Js8DZ+sGBRRUPEAlldQXRllwCVnwKQYhVzMIdHO2vaA sclCggB/mzp9EFFNQM284VV3Pav2Xgq8/J3+BvwFw4xy7L/pyGYdDkznzgEgDiNbH+vO BDqbXsRUIMN3QeuXc7cXm+/6FNfa5+r/Ue7pHmbR2vW1aSiJDAhQEPhywxGR7H1LJWph KNKg== X-Gm-Message-State: AHQUAuYD9D8qR34VFwPyxO/q40FD8aWbZZQrTE97MyOs3BaW+aFHkVmQ DXBReJ+4yg8F822O4v/vhg8+G+uzHcs= X-Google-Smtp-Source: AHgI3IYxviVpq7YQKr1HfOTNRTyUlVOhPerdWNULPaGDoF56IxZrrGojyu19KfK9u//WM6QqWtdzRw== X-Received: by 2002:a7b:c92b:: with SMTP id h11mr1950533wml.33.1550831201518; Fri, 22 Feb 2019 02:26:41 -0800 (PST) Received: from [192.168.0.107] (79-100-158-105.ip.btc-net.bg. [79.100.158.105]) by smtp.gmail.com with ESMTPSA id y5sm965290wmg.31.2019.02.22.02.26.40 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 22 Feb 2019 02:26:40 -0800 (PST) Subject: Re: [PATCH net-next v2] route: Add a new fib_multipath_hash_policy base on cpu id for tunnel packet To: wenxu@ucloud.cn, davem@davemloft.net Cc: netdev@vger.kernel.org References: <1550827209-23440-1-git-send-email-wenxu@ucloud.cn> From: Nikolay Aleksandrov Message-ID: Date: Fri, 22 Feb 2019 12:26:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <1550827209-23440-1-git-send-email-wenxu@ucloud.cn> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 22/02/2019 11:20, wenxu@ucloud.cn wrote: > From: wenxu > > Current fib_multipath_hash_policy can make hash based on the L3 or > L4. But it only work on the outer IP. So a specific tunnel always > has the same hash value. But a specific tunnel may contain so many > inner connections. However there is no good way for tunnel packet. > A specific tunnel route based on the percpu dst_cache. It will not > lookup route table for each packet. > > This patch provide a based cpu id hash policy. The different > connection run on different cpu and there will be different hash > value for percpu dst_cache. > > Signed-off-by: wenxu > --- > net/ipv4/route.c | 6 ++++++ > net/ipv4/sysctl_net_ipv4.c | 2 +- > 2 files changed, 7 insertions(+), 1 deletion(-) > Hi, When we had the same issue in the bonding, we added a new mode which used the flow dissector to get the inner headers and hash on them. I believe that is even easier nowadays, but I think people wanted to use different hash algorithms as well and last we discussed this we were talking about yet another bpf use to generate the hash. Now we got bpf_set_hash() which can be used to achieve this from various places, if you use that with hash_policy=1 (L4) then skb->hash will be used and you can achieve any hashing that you desire. Cheers, Nik