DPDK patches and discussions
 help / color / mirror / Atom feed

From: Alan Robertson <aroberts@Brocade.com>
To: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [dpdk-dev] [RFC] ethdev: abstraction layer for QoS hierarchical scheduler
Date: Fri, 9 Dec 2016 09:28:24 +0000	[thread overview]
Message-ID: <6520706120d4440f9acdf88e12de0f0d@EMEAWP-EXMB11.corp.brocade.com> (raw)
In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D8912652711C93@IRSMSX108.ger.corp.intel.com>

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@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

next prev parent reply	other threads:[~2016-12-09  9:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-30 18:16 Cristian Dumitrescu
2016-12-06 19:51 ` Stephen Hemminger
2016-12-06 22:14   ` Thomas Monjalon
2016-12-07 20:13     ` Dumitrescu, Cristian
2016-12-07 19:03   ` Dumitrescu, Cristian
     [not found] ` <57688e98-15d5-1866-0c3a-9dda81621651@brocade.com>
2016-12-07 10:58   ` Alan Robertson
2016-12-07 19:52     ` Dumitrescu, Cristian
2016-12-08 15:41       ` Alan Robertson
2016-12-08 17:18         ` Dumitrescu, Cristian
2016-12-09  9:28           ` Alan Robertson [this message]
2016-12-08 10:14     ` Bruce Richardson
2017-01-11 13:56 ` Jerin Jacob
2017-01-13 10:36 ` Hemant Agrawal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6520706120d4440f9acdf88e12de0f0d@EMEAWP-EXMB11.corp.brocade.com \
    --to=aroberts@brocade.com \
    --cc=cristian.dumitrescu@intel.com \
    --cc=dev@dpdk.org \
    --cc=thomas.monjalon@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).