[dpdk-dev] [RFC] ethdev: abstraction layer for QoS hierarchical scheduler

Alan Robertson aroberts at Brocade.com
Fri Dec 9 10:28:24 CET 2016


Hi Cristian,

No, it'll be done as a completely separate scheduling mechanism.  We'd allocate a much smaller
footprint equivalent to a pipe, TCs and queues.   This structure would be completely independent.
It would be up to the calling code to allocate, track and free it so it could be associated with any
target.  The equivalent of the enqueue and dequeue functions would be called wherever it
was required in the data path.  So if we look at an encrypted tunnel:

Ip forward -> qos enq/qos deq -> encrypt -> port forward (possibly qos again at port)

So each structure would work independently with the assumption that it's called frequently
enough to keep the state machine ticking over.  Pretty much as we do for a PMD scheduler.

Note that if we run the features in the above order encrypted frames aren't dropped by the
Qos enqueue.  Since encryption is probably the most expensive processing done on a packet it
should give a big performance gain.

Thanks,
Alan.

-----Original Message-----
From: Dumitrescu, Cristian [mailto:cristian.dumitrescu at intel.com] 
Sent: Thursday, December 08, 2016 5:18 PM
To: Alan Robertson
Cc: dev at dpdk.org; Thomas Monjalon
Subject: RE: [dpdk-dev] [RFC] ethdev: abstraction layer for QoS hierarchical scheduler

> Hi Cristian,
> 
> The way qos works just now should be feasible for dynamic targets.   That is
> similar functions
> to rte_sched_port_enqueue() and rte_sched_port_dequeue() would be 
> called.  The first to enqueue the mbufs onto the queues the second to 
> dequeue.  The qos structures and scheduler don't need to be as 
> functionally rich though.  I would have thought a simple pipe with 
> child nodes should suffice for most.  That would allow each 
> tunnel/session to be shaped and the queueing and drop logic inherited 
> from what is there just now.
> 
> Thanks,
> Alan.

Hi Alan,

So just to make sure I get this right: you suggest that tunnels/sessions could simply be mapped as one of the layers under the port hierarchy?

Thanks,
Cristian



More information about the dev mailing list