Re: [net-next v8 2/2] net: sched: support hash/classid/cpuid selecting tx queue
From: Tonghao Zhang <hidden>
Date: 2022-02-15 01:40:43
On Tue, Feb 15, 2022 at 8:22 AM Jamal Hadi Salim [off-list ref] wrote:
On 2022-01-26 09:32, xiangxia.m.yue@gmail.com wrote:quoted
From: Tonghao Zhang <redacted> This patch allows user to select queue_mapping, range from A to B. And user can use skbhash, cgroup classid and cpuid to select Tx queues. Then we can load balance packets from A to B queue. The range is an unsigned 16bit value in decimal format. $ tc filter ... action skbedit queue_mapping skbhash A B "skbedit queue_mapping QUEUE_MAPPING" (from "man 8 tc-skbedit") is enhanced with flags: * SKBEDIT_F_TXQ_SKBHASH * SKBEDIT_F_TXQ_CLASSID * SKBEDIT_F_TXQ_CPUID Use skb->hash, cgroup classid, or cpuid to distribute packets. Then same range of tx queues can be shared for different flows, cgroups, or CPUs in a variety of scenarios. For example, F1 may share range R1 with F2. The best way to do that is to set flag to SKBEDIT_F_TXQ_HASH, using skb->hash to share the queues. If cgroup C1 want to share the R1 with cgroup C2 .. Cn, use the SKBEDIT_F_TXQ_CLASSID. Of course, in some other scenario, C1 use R1, while Cn can use the Rn.So while i dont agree that ebpf is the solution for reasons i mentioned earlier - after looking at the details think iam confused by this change and maybe i didnt fully understand the use case. What is the driver that would work with this? You said earlier packets are coming out of some pods and then heading to the wire and you are looking to balance and isolate between bulk and latency sensitive traffic - how are any of these metadatum useful for that? skb->priority seems more natural for that.
Hi I try to explain. there are two tx-queue range, e.g. A(Q0-Qn), B(Qn+1-Qm). A is used for latency sensitive traffic. B is used for bulk sensitive traffic. A may be shared by Pods/Containers which key is high throughput. B may be shared by Pods/Containers which key is low latency. So we can do the balance in range A for latency sensitive traffic. So we can use the skb->hash or CPUID or classid to classify the packets in range A or B. The balance policies are used for different use case. For skb->hash, the packets from Pods/Containers will share the range. Should to know that one Pod/Container may use the multi TCP/UDP flows. That flows share the tx queue range. For CPUID, while Pod/Container use the multi flows, pod pinned on one CPU will use one tx-queue in range A or B. For CLASSID, the Pod may contain the multi containters. skb->priority may be used by applications. we can't require application developer to change them.
cheers, jamal
-- Best regards, Tonghao