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.dumitre...@intel.com] Sent: Thursday, December 08, 2016 5:18 PM To: Alan Robertson Cc: dev@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
