[RFC,0/3] Add PIE support for HQoS library

  DPDK sched library is equipped with mechanism that secures it from the bufferbloat problem
which is a situation when excess buffers in the network cause high latency and latency 
variation. Currently, it supports RED for queue congestion control (which is designed 
to control the queue length but it does not control latency directly and is now being 
obsoleted ). However, more advanced queue management is required to address this problem
and provide desirable quality of service to users.

This solution (RFC) proposes usage of new algorithm called "PIE" (Proportional Integral
controller Enhanced) that can effectively and directly control queuing latency to address 
the bufferbloat problem.

The implementation of mentioned functionality includes modification of existing and 
adding a new set of data structures to the library, adding PIE related APIs. 
This affects structures in public API/ABI. That is why deprecation notice is going
to be prepared and sent.


Liguzinski, WojciechX (3):
  sched: add pie based congestion management
  example/qos_sched: add pie support
  example/ip_pipeline: add pie support

 config/rte_config.h                      |   1 -
 drivers/net/softnic/rte_eth_softnic_tm.c |   4 +-
 examples/ip_pipeline/tmgr.c              |   4 +-
 examples/qos_sched/app_thread.c          |   1 -
 examples/qos_sched/cfg_file.c            |  82 +++++++--
 examples/qos_sched/init.c                |   5 +-
 examples/qos_sched/profile.cfg           | 196 +++++++++++++-------
 lib/sched/meson.build                    |  10 +-
 lib/sched/rte_sched.c                    | 220 +++++++++++++++++------
 lib/sched/rte_sched.h                    |  53 ++++--
 10 files changed, 411 insertions(+), 165 deletions(-)
  

On Mon, 24 May 2021 11:58:19 +0100
"Liguzinski, WojciechX" <wojciechx.liguzinski@intel.com> wrote:

> DPDK sched library is equipped with mechanism that secures it from the bufferbloat problem
> which is a situation when excess buffers in the network cause high latency and latency 
> variation. Currently, it supports RED for queue congestion control (which is designed 
> to control the queue length but it does not control latency directly and is now being 
> obsoleted ). However, more advanced queue management is required to address this problem
> and provide desirable quality of service to users.
> 
> This solution (RFC) proposes usage of new algorithm called "PIE" (Proportional Integral
> controller Enhanced) that can effectively and directly control queuing latency to address 
> the bufferbloat problem.
> 
> The implementation of mentioned functionality includes modification of existing and 
> adding a new set of data structures to the library, adding PIE related APIs. 
> This affects structures in public API/ABI. That is why deprecation notice is going
> to be prepared and sent.
> 
> 
> Liguzinski, WojciechX (3):
>   sched: add pie based congestion management
>   example/qos_sched: add pie support
>   example/ip_pipeline: add pie support
> 
>  config/rte_config.h                      |   1 -
>  drivers/net/softnic/rte_eth_softnic_tm.c |   4 +-
>  examples/ip_pipeline/tmgr.c              |   4 +-
>  examples/qos_sched/app_thread.c          |   1 -
>  examples/qos_sched/cfg_file.c            |  82 +++++++--
>  examples/qos_sched/init.c                |   5 +-
>  examples/qos_sched/profile.cfg           | 196 +++++++++++++-------
>  lib/sched/meson.build                    |  10 +-
>  lib/sched/rte_sched.c                    | 220 +++++++++++++++++------
>  lib/sched/rte_sched.h                    |  53 ++++--
>  10 files changed, 411 insertions(+), 165 deletions(-)

What about FQ codel which is more widely deployed, has less configuration?
  

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Liguzinski,
> WojciechX
> Sent: Monday, 24 May 2021 12.58
> 
> DPDK sched library is equipped with mechanism that secures it from the
> bufferbloat problem
> which is a situation when excess buffers in the network cause high
> latency and latency
> variation. Currently, it supports RED for queue congestion control

The correct term is "active queue management", not "queue congestion control".

> (which is designed
> to control the queue length but it does not control latency directly
> and is now being
> obsoleted ).

Some might prefer other algorithms, such as PIE, CoDel, CAKE, etc., but RED is not obsolete!

> However, more advanced queue management is required to
> address this problem
> and provide desirable quality of service to users.
> 
> This solution (RFC) proposes usage of new algorithm called "PIE"
> (Proportional Integral
> controller Enhanced) that can effectively and directly control queuing
> latency to address
> the bufferbloat problem.
> 
> The implementation of mentioned functionality includes modification of
> existing and
> adding a new set of data structures to the library, adding PIE related
> APIs.
> This affects structures in public API/ABI. That is why deprecation
> notice is going
> to be prepared and sent.
> 
> 
> Liguzinski, WojciechX (3):
>   sched: add pie based congestion management
>   example/qos_sched: add pie support
>   example/ip_pipeline: add pie support

It's "PIE", not "pie". :-)

Nonetheless, the RFC looks good!

-Morten
  

> -----Original Message-----
> From: Morten Brørup <mb@smartsharesystems.com> 
> Sent: Tuesday, May 25, 2021 10:57 AM
> To: Liguzinski, WojciechX <wojciechx.liguzinski@intel.com>; dev@dpdk.org; Singh, Jasvinder <jasvinder.singh@intel.com>; Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: Dharmappa, Savinay <savinay.dharmappa@intel.com>
> Subject: RE: [dpdk-dev] [RFC PATCH 0/3] Add PIE support for HQoS library
>
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Liguzinski, 
> > WojciechX
> > Sent: Monday, 24 May 2021 12.58
> > 
> > DPDK sched library is equipped with mechanism that secures it from the 
> > bufferbloat problem which is a situation when excess buffers in the 
> > network cause high latency and latency variation. Currently, it 
> > supports RED for queue congestion control
>
> The correct term is "active queue management", not "queue congestion control".

Good point. I will correct the naming.

>
> > (which is designed
> > to control the queue length but it does not control latency directly 
> > and is now being obsoleted ).
>
> Some might prefer other algorithms, such as PIE, CoDel, CAKE, etc., but RED is not obsolete!

I didn't write that it is obsolete, I just shortened what was written in the RFC (8033) on page 4:
"(...) AQM schemes, such as Random Early Detection
(RED) [RED] as suggested in [RFC2309] (which is now obsoleted by
[RFC7567]), have been around for well over a decade. RED is
implemented in a wide variety of network devices, both in hardware
and software. Unfortunately, due to the fact that RED needs careful
tuning of its parameters for various network conditions, most network
operators don't turn RED on. (...)"

Apologies if I weren't precise when thinking about such a summary. :-)

>
> > However, more advanced queue management is required to address this 
> > problem and provide desirable quality of service to users.
> > 
> > This solution (RFC) proposes usage of new algorithm called "PIE"
> > (Proportional Integral
> > controller Enhanced) that can effectively and directly control queuing 
> > latency to address the bufferbloat problem.
> > 
> > The implementation of mentioned functionality includes modification of 
> > existing and adding a new set of data structures to the library, 
> > adding PIE related APIs.
> > This affects structures in public API/ABI. That is why deprecation 
> > notice is going to be prepared and sent.
> > 
> > 
> > Liguzinski, WojciechX (3):
> >   sched: add pie based congestion management
> >   example/qos_sched: add pie support
> >   example/ip_pipeline: add pie support
>
> It's "PIE", not "pie". :-)

Sure, I will make a proper naming corrections ;-)

>
> Nonetheless, the RFC looks good!
>
> -Morten

Thanks,
Wojciech