From: Jakub Kicinski <kuba@kernel.org>
To: takeru hayasaka <hayatake396@gmail.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
netdev@vger.kernel.org, osmocom-net-gprs@lists.osmocom.org,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
Harald Welte <laforge@gnumonks.org>,
linux-kernel@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
intel-wired-lan@lists.osuosl.org,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Paolo Abeni <pabeni@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
Pablo Neira Ayuso <pablo@netfilter.org>
Subject: Re: [Intel-wired-lan] [PATCH net-next v2] ethtool: ice: Support for RSS settings to GTP from ethtool
Date: Wed, 18 Oct 2023 10:37:03 -0700 [thread overview]
Message-ID: <20231018103703.41fd4d9b@kernel.org> (raw)
In-Reply-To: <CADFiAc+OnpyNTXntZBkDAf+UfueRotqqWKg+BrApWcL=x_8vjQ@mail.gmail.com>
On Wed, 18 Oct 2023 10:53:02 +0900 takeru hayasaka wrote:
> 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).
> This is quite convenient from a scalability perspective. In fact, in
> 5G UPF, the communication is explicitly only on the User plane
> (Uplane).
>
> Therefore, services are expected to receive only GTPU traffic (e.g.,
> PGW-U, UPF) or only GTPC traffic (e.g., PGW-C). Hence, there arises a
> necessity to use only GTPU.
>
> If we do not distinguish packets into Control/User (C/U) with options
> like gtp4|6, I can conceive scenarios where performance tuning becomes
> challenging.
> For example, in cases where we want to process only the control
> communication (GTPC) using Flow Director on specific CPUs, while
> processing GTPU on the remaining cores.
> In scenarios like IoT, where user communication is minimal but the
> volume of devices is vast, the control traffic could substantially
> increase. Thus, this might also be possible in reverse.
> In short, this pertains to being mindful of CPU core affinity.
>
> 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.
> Regarding Extension Headers and such, I think it would be more
> straightforward to handle them implicitly.
>
> What does everyone else think?
Harald went further and questioned use of the same IP addresses for
-U and -C traffic, but even within one endpoint aren't these running
on a different port? Can someone reasonably use the same UDP port
for both types of traffic?
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: takeru hayasaka <hayatake396@gmail.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
Harald Welte <laforge@gnumonks.org>,
Pablo Neira Ayuso <pablo@netfilter.org>,
osmocom-net-gprs@lists.osmocom.org
Subject: Re: [PATCH net-next v2] ethtool: ice: Support for RSS settings to GTP from ethtool
Date: Wed, 18 Oct 2023 10:37:03 -0700 [thread overview]
Message-ID: <20231018103703.41fd4d9b@kernel.org> (raw)
In-Reply-To: <CADFiAc+OnpyNTXntZBkDAf+UfueRotqqWKg+BrApWcL=x_8vjQ@mail.gmail.com>
On Wed, 18 Oct 2023 10:53:02 +0900 takeru hayasaka wrote:
> 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).
> This is quite convenient from a scalability perspective. In fact, in
> 5G UPF, the communication is explicitly only on the User plane
> (Uplane).
>
> Therefore, services are expected to receive only GTPU traffic (e.g.,
> PGW-U, UPF) or only GTPC traffic (e.g., PGW-C). Hence, there arises a
> necessity to use only GTPU.
>
> If we do not distinguish packets into Control/User (C/U) with options
> like gtp4|6, I can conceive scenarios where performance tuning becomes
> challenging.
> For example, in cases where we want to process only the control
> communication (GTPC) using Flow Director on specific CPUs, while
> processing GTPU on the remaining cores.
> In scenarios like IoT, where user communication is minimal but the
> volume of devices is vast, the control traffic could substantially
> increase. Thus, this might also be possible in reverse.
> In short, this pertains to being mindful of CPU core affinity.
>
> 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.
> Regarding Extension Headers and such, I think it would be more
> straightforward to handle them implicitly.
>
> What does everyone else think?
Harald went further and questioned use of the same IP addresses for
-U and -C traffic, but even within one endpoint aren't these running
on a different port? Can someone reasonably use the same UDP port
for both types of traffic?
next prev parent reply other threads:[~2023-10-18 17:37 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-12 6:01 [Intel-wired-lan] [PATCH net-next v2] ethtool: ice: Support for RSS settings to GTP from ethtool Takeru Hayasaka
2023-10-12 6:01 ` Takeru Hayasaka
2023-10-16 9:27 ` [Intel-wired-lan] " Simon Horman
2023-10-16 9:27 ` Simon Horman
2023-10-16 22:23 ` [Intel-wired-lan] " Jakub Kicinski
2023-10-16 22:23 ` Jakub Kicinski
2023-10-17 6:11 ` [Intel-wired-lan] " Harald Welte
2023-10-17 6:11 ` Harald Welte
2023-10-17 6:44 ` [Intel-wired-lan] " Harald Welte
2023-10-17 6:44 ` Harald Welte
2023-10-17 14:18 ` [Intel-wired-lan] " takeru hayasaka
2023-10-17 14:18 ` takeru hayasaka
2023-10-17 14:37 ` [Intel-wired-lan] " takeru hayasaka
2023-10-17 14:37 ` takeru hayasaka
2023-10-17 16:49 ` [Intel-wired-lan] " takeru hayasaka
2023-10-17 16:49 ` takeru hayasaka
2023-10-18 8:25 ` [Intel-wired-lan] " Harald Welte
2023-10-18 8:25 ` Harald Welte
2023-10-18 16:20 ` [Intel-wired-lan] " takeru hayasaka
2023-10-18 16:20 ` takeru hayasaka
2023-10-17 23:49 ` [Intel-wired-lan] " Jakub Kicinski
2023-10-17 23:49 ` Jakub Kicinski
2023-10-18 1:53 ` [Intel-wired-lan] " takeru hayasaka
2023-10-18 1:53 ` takeru hayasaka
2023-10-18 8:12 ` [Intel-wired-lan] " Harald Welte
2023-10-18 8:12 ` Harald Welte
2023-10-18 17:40 ` [Intel-wired-lan] " Jakub Kicinski
2023-10-18 17:40 ` Jakub Kicinski
2023-10-18 17:37 ` Jakub Kicinski [this message]
2023-10-18 17:37 ` Jakub Kicinski
2023-10-18 17:57 ` [Intel-wired-lan] " Harald Welte
2023-10-18 17:57 ` Harald Welte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231018103703.41fd4d9b@kernel.org \
--to=kuba@kernel.org \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hayatake396@gmail.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jesse.brandeburg@intel.com \
--cc=laforge@gnumonks.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=osmocom-net-gprs@lists.osmocom.org \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=willemdebruijn.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.