On 11/30/2016 11:46 PM, Cristian Dumitrescu wrote:
This RFC proposes an ethdev-based abstraction layer for Quality of Service (QoS)
hierarchical scheduler. The goal of the abstraction layer is to provide a simple
generic API that is agnostic of the underlying HW, SW or mixed HW-SW complex
impleme
On Wed, Nov 30, 2016 at 06:16:50PM +, Cristian Dumitrescu wrote:
> This RFC proposes an ethdev-based abstraction layer for Quality of Service
> (QoS)
> hierarchical scheduler. The goal of the abstraction layer is to provide a
> simple
> generic API that is agnostic of the underlying HW, SW or
njalon
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
> c
> 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 sched
rescu, Cristian [mailto:cristian.dumitre...@intel.com]
Sent: Wednesday, December 07, 2016 7:52 PM
To: Alan Robertson
Cc: dev@dpdk.org; Thomas Monjalon
Subject: RE: [dpdk-dev] [RFC] ethdev: abstraction layer for QoS hierarchical
scheduler
Hi Alan,
Thanks for your comments!
> Hi Cristian,
&
On Wed, Dec 07, 2016 at 10:58:49AM +, Alan Robertson wrote:
> Hi Cristian,
>
> Looking at points 10 and 11 it's good to hear nodes can be dynamically added.
>
> We've been trying to decide the best way to do this for support of qos on
> tunnels for
> some time now and the existing implementa
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
> Sent: Tuesday, December 6, 2016 10:14 PM
> To: Stephen Hemminger
> Cc: dev@dpdk.org; Dumitrescu, Cristian
> Subject: Re: [dpdk-dev] [RFC] ethdev: abstraction layer for QoS hierar
Hi Alan,
Thanks for your comments!
> Hi Cristian,
> Looking at points 10 and 11 it's good to hear nodes can be dynamically added.
Yes, many implementations allow on-the-fly remapping a node from one parent to
another
one, or simply adding more nodes post-initialization, so it is natural for t
Hi Steve,
Thanks for your comments!
> This seems to be more of an abstraction of existing QoS.
Really? Why exactly do you say this, any particular examples?
I think the current proposal provides an abstraction for far more features than
librte_sched provides. The goal for this API is to be ab
increase the priority of some of the tasks and a PR may
appear
on the mailing list.
Thanks,
Alan.
Subject:
[dpdk-dev] [RFC] ethdev: abstraction layer for QoS hierarchical scheduler
Date:
Wed, 30 Nov 2016 18:16:50 +
From:
Cristian Dumitrescu
<mailto:cristian.dumitre...@intel.com>
T
2016-12-06 11:51, Stephen Hemminger:
> Rather than reinventing wheel which seems to be DPDK Standard
> Procedure, could an existing abstraction be used?
Stephen, you know that the DPDK standard procedure is to consider
reviews and good comments ;)
On Wed, 30 Nov 2016 18:16:50 +
Cristian Dumitrescu wrote:
> This RFC proposes an ethdev-based abstraction layer for Quality of Service
> (QoS)
> hierarchical scheduler. The goal of the abstraction layer is to provide a
> simple
> generic API that is agnostic of the underlying HW, SW or mixe
This RFC proposes an ethdev-based abstraction layer for Quality of Service (QoS)
hierarchical scheduler. The goal of the abstraction layer is to provide a simple
generic API that is agnostic of the underlying HW, SW or mixed HW-SW complex
implementation.
Q1: What is the benefit for having an abstr
13 matches
Mail list logo