From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <aroberts@Brocade.com>
Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com
 [67.231.144.122]) by dpdk.org (Postfix) with ESMTP id 4AAC22C60
 for <dev@dpdk.org>; Fri,  9 Dec 2016 10:28:31 +0100 (CET)
Received: from pps.filterd (m0000542.ppops.net [127.0.0.1])
 by mx0a-000f0801.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id
 uB99PrIB013626; Fri, 9 Dec 2016 01:28:30 -0800
Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227])
 by mx0a-000f0801.pphosted.com with ESMTP id 277r6m0mu0-2
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT);
 Fri, 09 Dec 2016 01:28:29 -0800
Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by
 BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS)
 id 15.0.1210.3; Fri, 9 Dec 2016 02:28:25 -0700
Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by
 EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server
 (TLS) id 15.0.1210.3; Fri, 9 Dec 2016 10:28:24 +0100
Received: from EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640]) by
 EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640%21]) with
 mapi id 15.00.1210.000; Fri, 9 Dec 2016 10:28:24 +0100
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>
Thread-Topic: [dpdk-dev] [RFC] ethdev: abstraction layer for QoS hierarchical
 scheduler
Thread-Index: AQHSUAXX1nBIRfHHyEC6aV2DVJ7quqD8RZPwgACQXoCAAVnVoIAADYEAgAEbzCA=
Date: Fri, 9 Dec 2016 09:28:24 +0000
Message-ID: <6520706120d4440f9acdf88e12de0f0d@EMEAWP-EXMB11.corp.brocade.com>
References: <1480529810-95280-1-git-send-email-cristian.dumitrescu@intel.com>
 <57688e98-15d5-1866-0c3a-9dda81621651@brocade.com>
 <6d862b500e1e4f34a4cbf790db8d5d48@EMEAWP-EXMB11.corp.brocade.com>
 <3EB4FA525960D640B5BDFFD6A3D8912652711302@IRSMSX108.ger.corp.intel.com>
 <ed5a51a8bda648d2a92504c42ada9381@EMEAWP-EXMB11.corp.brocade.com>
 <3EB4FA525960D640B5BDFFD6A3D8912652711C93@IRSMSX108.ger.corp.intel.com>
In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D8912652711C93@IRSMSX108.ger.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.252.49.8]
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, ,
 definitions=2016-12-09_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0
 priorityscore=1501 malwarescore=0
 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015
 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0
 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1612090126
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: Fri, 09 Dec 2016 09:28:32 -0000

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