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 Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D2653CDB484 for ; Wed, 18 Oct 2023 08:15:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 776174036E; Wed, 18 Oct 2023 08:15:17 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 776174036E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1697616917; bh=03fQjPHgInwdjf6p8dN674Gw8bX9L3SyOPJ8Ivx4RKo=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=F4Gqx1nIEz1PilUXB9nd4TAJWXOjFBjrQrrOjnhcpyWNpOFZ2WaAzNqfJZCBMxKM2 7Uy4T+gtqym1bnLUk++FO4zOEIZqK+zCu6ftZy9BEz9X/7B5EL8talyQ8FTSR3zhWv OG6c2BvudTYyHwB5cd/hXAoMhUKsj9siAmj7pVCR10iPn8oajxRcseCv+H64s/mbXj 1v4zvf9JyQO3nFpruaq62YEDVIDJrj+rUjDdOHEJ76WR7/8ybCI3YHziPaZWqHZEhp rLNEnCQ0l4DawQJPbySbw5O1ia+dnmcOJUpMRg6oFAA6D5ADr8C/v2YnqIHqsWnj2I MEfcG26jrByTw== X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzRneaitHLHz; Wed, 18 Oct 2023 08:15:16 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by smtp2.osuosl.org (Postfix) with ESMTP id 1BCB7404D3; Wed, 18 Oct 2023 08:15:16 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1BCB7404D3 Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by ash.osuosl.org (Postfix) with ESMTP id 18A2A1BF285 for ; Wed, 18 Oct 2023 08:15:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id E452B60E03 for ; Wed, 18 Oct 2023 08:15:14 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E452B60E03 X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ged80BpkEzYC for ; Wed, 18 Oct 2023 08:15:14 +0000 (UTC) Received: from ganesha.gnumonks.org (ganesha.gnumonks.org [IPv6:2001:780:45:1d:225:90ff:fe52:c662]) by smtp3.osuosl.org (Postfix) with ESMTPS id C66C560B29 for ; Wed, 18 Oct 2023 08:15:12 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org C66C560B29 Received: from uucp by ganesha.gnumonks.org with local-bsmtp (Exim 4.94.2) (envelope-from ) id 1qt1hq-00BbbJ-Ah; Wed, 18 Oct 2023 10:15:06 +0200 Received: from laforge by nataraja with local (Exim 4.97-RC2) (envelope-from ) id 1qt1fY-00000002Ylo-3fKj; Wed, 18 Oct 2023 10:12:44 +0200 Date: Wed, 18 Oct 2023 10:12:44 +0200 From: Harald Welte To: takeru hayasaka Message-ID: References: <20231012060115.107183-1-hayatake396@gmail.com> <20231016152343.1fc7c7be@kernel.org> <20231017164915.23757eed@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Subject: Re: [Intel-wired-lan] [PATCH net-next v2] ethtool: ice: Support for RSS settings to GTP from ethtool X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Willem de Bruijn , intel-wired-lan@lists.osuosl.org, osmocom-net-gprs@lists.osmocom.org, Jesse Brandeburg , linux-kernel@vger.kernel.org, Eric Dumazet , Tony Nguyen , netdev@vger.kernel.org, Jakub Kicinski , Paolo Abeni , "David S. Miller" , Pablo Neira Ayuso Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" Dear Takeru, Jakub and list, On Wed, Oct 18, 2023 at 10:53:02AM +0900, takeru hayasaka wrote: > > Let's forget about capabilities of Intel NICs for now - can you as a > > user think of practical use cases where we'd want to turn on hashing > > based on TEID for, e.g. gtpu6 and not gtpc6? > > of course! > There are clearly cases where we would want to use gtpu4|6 instead of gtpc4|6. > > For instance, there are PGWs that have the capability to separate the > termination of communication of 4G LTE users into Control and User > planes (C/U). I would argue it is the standard case in any PGW (or SMF+UPF) to process GTP-C differently than GTP-U. That's what the entire CUPS (control/user plane split) architecture is meant for. Now the question is how does one implement that? As the related signaling protocols all allow to specify different IP addresses for GTPv1/v2-C (v1 for 2G/3G and v2 for 4G) and GTPv1-U (v1 used everywhere) it is always possible to use separate IP addresses for control and user plane. It's even normal that a single GTP-C instance (on one IP) manages multiple GTP-U instances on other IP-addresses. Those IPs are then handled by completely different physical servers/systems/VMs/... So only in case the user intentionally configures their network to use the same IP address for GTP-C and GTP-U traffic one will need to start distinguishing GTP-C and GTP-U on one host/NIC with the RSS mechanism: Steer the GTP-C traffic to the control plane instance on one CPU and spread the GTP-U traffic via hash function to multiple other queues/CPUs. I personally think it's short-sighted to use identical IPs for control and user plane, as it means you can never scale out to multiple machines without introducing some kind of dedicated load balancer in front. But assuming some people still want to do it that way: Yes, then you need the feature to split GTP-C form GTP-U via RSS to scale well. What I'm somehwat more wondering about is the usability to load-balance GTP-C traffic over multiple queues/cores. As stated earlier, that's just signaling. > If we were to propose again, setting aside considerations specific to > Intel, I believe, considering the users of ethtool, the smallest units > should be gtpu4|6 and gtpc4|6. agreed. Though I'm not entirely sure one would usually want to treat v4 different from v6. I'd assume they would usually both follow the same RSS scheme? > Regarding Extension Headers and such, I think it would be more > straightforward to handle them implicitly. I would also agree to that. -- - Harald Welte https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) _______________________________________________ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan