[dpdk-dev] Regarding HQOS with run-to-completion Model

[dpdk-dev] Regarding HQOS with run-to-completion Model

[farooq basha]

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

Hello DevTeam,

    I am planning to use DPDK HQOS for Traffic shaping with a
run-to-completion Model. While I was reading the dpdk-qos document, I came
across the following statement.

"*Running enqueue and dequeue operations for the same output port from
different cores is likely to cause significant impact on scheduler’s
performance and it is therefore not recommended"*

 Let's take an  example, Port1  & Port2 have 4 Rx queues and each Queue
mapped to a different CPU. Traffic coming on port1  gets forwarded to port2
. With the above limitation application needs to take a lock before doing
rte_sched_port_enqueue & dequeue operation. Performance is limited to only
1 CPU even though Traffic is coming on 4 Different CPUs.

Correct me if my understanding is Wrong?

Thanks
Basha

[-- Attachment #2: Type: text/html, Size: 2727 bytes --]

Re: [dpdk-dev] Regarding HQOS with run-to-completion Model

[Stephen Hemminger]

On Mon, 28 Apr 2025 16:55:07 +0530
farooq basha <farooq.juturu@gmail.com> wrote:

> Hello DevTeam,
> 
>     I am planning to use DPDK HQOS for Traffic shaping with a
> run-to-completion Model. While I was reading the dpdk-qos document, I came
> across the following statement.
> 
> "*Running enqueue and dequeue operations for the same output port from
> different cores is likely to cause significant impact on scheduler’s
> performance and it is therefore not recommended"*
> 
>  Let's take an  example, Port1  & Port2 have 4 Rx queues and each Queue
> mapped to a different CPU. Traffic coming on port1  gets forwarded to port2
> . With the above limitation application needs to take a lock before doing
> rte_sched_port_enqueue & dequeue operation. Performance is limited to only
> 1 CPU even though Traffic is coming on 4 Different CPUs.
> 
> Correct me if my understanding is Wrong?
> 
> Thanks
> Basha

The HQOS code is not thread safe so yes you need a lock.
The traffic scheduling (QOS) needs to be at last stage of the pipeline just
before mbufs are passed to the device.

The issue is that QOS is single threaded, so lock is required. 

The statement is misleading, the real overhead is the lock; the secondary
overhead is the cache miss that will happen if processing on different cores.
But if you are doing that you are going to cut performance a lot from cache
misses.