From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ganesha.gnumonks.org (ganesha.gnumonks.org [213.95.27.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 15F736089A; Tue, 30 Jan 2024 10:15:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.95.27.120 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706609717; cv=none; b=HyOzxP5HWZJ7Qr6COqRFGnKBUULITTH+n4bvPAhAZkQ2waN3th7obcx+jMTKiczqzk+jYb+lxJxhvxuEW2az1ZIrlj6iq4xz040UzdiotMDxt5NBZRfj2U7bQuzfuZpJ29SW1GbLk0pcR9TMb9Ta6+Zmcwe8lQ28L3OtGY8yl9k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706609717; c=relaxed/simple; bh=9fYioI8dC2iBxcG6AmP63IOk32XJP98pHndMcV1dzEQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cCSqYjGIN7b4321OuvyZRdgMT80JGvXSQKB/rW9yuzGEch/7jf9VnuPlMylI/H0Y9xhsLFcMzGdQkfYM22CmWY6ZoFPScY2aUyID6RPEyHD43Ugz+acET1CeQWtbTJ+n4e/rwER5e/y1KQ4//6P6Am93clmceJEQlph4zsQhYzI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gnumonks.org; spf=pass smtp.mailfrom=gnumonks.org; arc=none smtp.client-ip=213.95.27.120 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gnumonks.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gnumonks.org Received: from uucp by ganesha.gnumonks.org with local-bsmtp (Exim 4.94.2) (envelope-from ) id 1rUl90-00F0vY-2G; Tue, 30 Jan 2024 11:15:06 +0100 Received: from laforge by localhost.localdomain with local (Exim 4.97) (envelope-from ) id 1rUl5f-0000000FnQK-1I97; Tue, 30 Jan 2024 11:11:39 +0100 Date: Tue, 30 Jan 2024 11:11:39 +0100 From: Harald Welte To: Marcin Szycik Cc: takeru hayasaka , Jesse Brandeburg , Tony Nguyen , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Jonathan Corbet , linux-doc@vger.kernel.org, vladimir.oltean@nxp.com, linux-kernel@vger.kernel.org, intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, mailhol.vincent@wanadoo.fr Subject: Re: [Intel-wired-lan] [PATCH net-next RESENT v3] ethtool: ice: Support for RSS settings to GTP from ethtool Message-ID: References: <20240127140747.905552-1-hayatake396@gmail.com> <154f979e-a335-461b-b72e-5e9c54fe940c@linux.intel.com> <92958c7b-7e5f-4e25-819f-4e52f9ffcf7b@linux.intel.com> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92958c7b-7e5f-4e25-819f-4e52f9ffcf7b@linux.intel.com> hi Marcin, Disclaimer: I have no understanding of the proposed implementation here, just commenting on this from a 3GPP protocol architecture point of view. On Tue, Jan 30, 2024 at 10:59:40AM +0100, Marcin Szycik wrote: > >> gtpc(4|6) doesn't include TEID, so what is its purpose? > > In GTPC communication, there is no TEID in the CSR (Create Session Request). > > Therefore, there are cases of GTPC that do not include TEID. > > The way I understand it now, this patch (and the ethtool one) adds hashing on > TEID field in GTP* headers. So I wanted to ask why do we have a case (gtpc(4|6)) > that doesn't include TEID? Do we hash on other fields in this header? There are many differen GTPv2C messages, most of which contain a TEID. So it does in general still make sense to be able to use RSS for all those other messages. The CSR (Create Session Request) will not be able to benfit from it, but it's just the first message initiating a dialogue between two elements (think of it like a TCP SYN). All the follow-up messages in that dialogue contain TEIDs and hence can benefit from RSS. -- - Harald Welte https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)