Hi Harald-san and all.
Thank you for the review and comment!
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.
I don't deny that using the same IP is short-sighted. However, in environments such as Private 5G and Private LTE, it is possible that a small mobile core OSS (e.g., NextEPC, Free5GC, etc.) is placed. Even if the addresses are separated, processing on the same computer instance is a possible scenario, so there are practical use cases.
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?
Indeed, you might want them to be treated in the same way. But this follows the existing design of Ethtool. In fact, formats like tcp4, tcp6, etc... with the L3 version appended, are given, and the existing implementation of Ethtool is described in the format of IPv4|6 + L4. I don’t know why the existing implementation is divided into IPv4 and v6.
Don't worry, you were very clear in this e-mail.
Thank you for your kind comment :)
Thanks for taking the time. As stated, I think it would be best to have these or some other some brief comments about the different flow types in the source code (and especially the documentation) of ethtool.
Understood. I’m thinking of writing a definition in the Ethtool header about this flow in the next version of the patch :)
Based on your explanation, I agree that indeed those are all different flow types that occur in real-life on PGW/UPF and other 3GPP network elements/functions. I can also very well imagine that there are use cases to steer all of those separately, including the EH and UL/DL types you mentioned.
Thanks. I'm glad you understood. I appreciate your review and comments.
I've been able to organize various comments and I think you've understood what is operated by the patch I sent.
Now, here, I’d like to propose two policies for the next version of the patch.
1. Keep this patch as is and write the necessary supplementary comments (of course, nits fix will be done). The good thing about this is that it can handle detailed use cases (as Harald-san understood)
There might be something more pleasant than expected use cases. The bad thing is the multitude of flow formats. Considering 6G, it may increase a bit more.
2.Limit the rx-flow-hash flow type to gtpu4|6 and gtpc4|6, and rewrite to implicitly execute the previous function. we will add comments (There will be fewer comments than plan 1).
In other words, in Intel Ice, the proposal has the following semantics. gtpu4|6: GTPU_V(4|6)_FLOW + GTPU_EH_V(4|6)_FLOW gtpc4|6: GTPC_V(4|6)_FLOW + GTPC_TEID_V(4|6)_FLOW
The good thing is that it seems easy for users to use, and the format of the GTP-related flow is less likely to increase or decrease in the future. The bad thing is that it may not be able to handle detailed use cases.
Please let me know which one, 1 or 2, you prefer. Also, I would be happy if there is any further feedback!
Thanks
2023年10月18日(水) 17:26 Harald Welte laforge@gnumonks.org:
Hi Takeru,
On Wed, Oct 18, 2023 at 01:49:08AM +0900, takeru hayasaka wrote:
I'm not very proficient in English, so I'm worried whether I can explain it well.
Don't worry, you were very clear in this e-mail.
Therefore, I will try to briefly explain the flow and what kind of cases these are in a straightforward manner.
Thanks for taking the time. As stated, I think it would be best to have these or some other some brief comments about the different flow types in the source code (and especially the documentation) of ethtool.
Based on your explanation, I agree that indeed those are all different flow types that occur in real-life on PGW/UPF and other 3GPP network elements/functions. I can also very well imagine that there are use cases to steer all of those separately, including the EH and UL/DL types you mentioned.
So I'm supporing your patch with all its many different flow types for RSS.
Thanks, Harald --
- Harald Welte laforge@gnumonks.org https://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)