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