From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <cristian.dumitrescu@intel.com>
Received: from mga06.intel.com (mga06.intel.com [134.134.136.31])
 by dpdk.org (Postfix) with ESMTP id E08A12BC5
 for <dev@dpdk.org>; Wed,  7 Dec 2016 20:03:43 +0100 (CET)
Received: from orsmga003.jf.intel.com ([10.7.209.27])
 by orsmga104.jf.intel.com with ESMTP; 07 Dec 2016 11:03:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.33,315,1477983600"; d="scan'208";a="909799777"
Received: from irsmsx109.ger.corp.intel.com ([163.33.3.23])
 by orsmga003.jf.intel.com with ESMTP; 07 Dec 2016 11:03:35 -0800
Received: from irsmsx112.ger.corp.intel.com (10.108.20.5) by
 IRSMSX109.ger.corp.intel.com (163.33.3.23) with Microsoft SMTP Server (TLS)
 id 14.3.248.2; Wed, 7 Dec 2016 19:03:34 +0000
Received: from irsmsx108.ger.corp.intel.com ([169.254.11.159]) by
 irsmsx112.ger.corp.intel.com ([169.254.1.113]) with mapi id 14.03.0248.002;
 Wed, 7 Dec 2016 19:03:34 +0000
From: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>
CC: "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: [dpdk-dev] [RFC] ethdev: abstraction layer for QoS
 hierarchical scheduler
Thread-Index: AQHSSzXynsac9sXyqk++qsVVyCqc5aD7XdMAgAF9TCA=
Date: Wed, 7 Dec 2016 19:03:34 +0000
Message-ID: <3EB4FA525960D640B5BDFFD6A3D89126527112A9@IRSMSX108.ger.corp.intel.com>
References: <1480529810-95280-1-git-send-email-cristian.dumitrescu@intel.com>
 <20161206115124.67ccc0c7@xeon-e3>
In-Reply-To: <20161206115124.67ccc0c7@xeon-e3>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMjMzZWNlOGYtYzQxNy00NWZmLWIwNmYtMDIzNjFmYWUzNzU2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjIuMTEuMCIsIlRydXN0ZWRMYWJlbEhhc2giOiJ6MHliem5rWnp2d3dMQ2IrR3hCdys1K2pMcjBYZDRlcXBTNDdtZkZzYU9nPSJ9
x-ctpclassification: CTP_IC
x-originating-ip: [163.33.239.182]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dpdk-dev] [RFC] ethdev: abstraction layer for QoS hierarchical
 scheduler
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2016 19:03:44 -0000

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 able to describe=
 virtually any hierarchy that could be implemented in HW and/or SW, not jus=
t what is currently provided by librte_sched.

If your statement is true, then I failed in my mission, and hopefully I did=
n't :)


> Why not something like Linux Qdisc or FreeBSD DummyNet/PF/ALTQ where the =
Qos components are stackable objects?=20

After designing Packet Framework, I don't think anybody could suspect me of=
 not being a fan of stackable objects ;). Not sure why you say this either,=
 as basically current proposal builds the hierarchy out of inter-connected =
nodes sitting on top of shapers and WRED contexts. To me, this is a decent =
stack?

I don't think this proposal is that far away from Linux qdisc: qdisc classe=
s are nodes, shapers are present, WRED contexts as well. Any particular qdi=
sc feature you see missing?

Of course, Linux qdisc also includes classification, policing, marking, etc=
 which are outside of the hierarchical scheduling that is targeted by this =
proposal. But this is an interesting thought: designing a qdisc-like layer =
within DPDK that binds together classification, policing, filters, scheduli=
ng.


> And why not make it the same as existing OS abstractions?

Do you mean using the Linux qdisc API and implementation as is? Of course, =
this is GPL licensed code and we cannot do this in DPDK.

Do you mean having a Linux qdisc-like API? I largely agree with this, and I=
 think the current proposal is very much inline with this; if you think oth=
erwise, again, specific examples of what's missing would help a lot. I can =
also take a look at DummyNet to make sure there is nothing left behind.


> Rather than reinventing wheel which seems to be DPDK Standard Procedure, =
could an existing abstraction be used?

I thought we are just trying to create a car instead of a faster horse :)


Regards,
Cristian