From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 0E9335934 for ; Fri, 29 Nov 2013 19:44:27 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 29 Nov 2013 10:45:27 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.93,798,1378882800"; d="scan'208";a="442125401" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga002.fm.intel.com with ESMTP; 29 Nov 2013 10:45:26 -0800 Received: from irsmsx106.ger.corp.intel.com (163.33.3.31) by IRSMSX101.ger.corp.intel.com (163.33.3.153) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 29 Nov 2013 18:45:25 +0000 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.114]) by IRSMSX106.ger.corp.intel.com ([169.254.8.15]) with mapi id 14.03.0123.003; Fri, 29 Nov 2013 18:45:25 +0000 From: "Dumitrescu, Cristian" To: "dev@dpdk.org" Thread-Topic: [dpdk-dev] 4 Traffic classes per Pipe limitation Thread-Index: AQHO7HvYNlA4wUqDgkWrSZGyhmQ/nZo8fe0w Date: Fri, 29 Nov 2013 18:45:25 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891261A5D21F4@IRSMSX102.ger.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] 4 Traffic classes per Pipe limitation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 18:44:28 -0000 Hi Ariel, some comments inlined below. Regards, Cristian -----Original Message----- From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ariel Rodriguez Sent: Thursday, November 28, 2013 8:53 PM To: dev@dpdk.org Subject: [dpdk-dev] 4 Traffic classes per Pipe limitation Hi, im working with the qos scheduler framework and i have a few questions. Why the 4 traffic classes per pipe limitation? . [Cristian] The DPDK hierarchical scheduler allows for 4 traffic classes wit= h 4 packet queues per traffic class for each pipe (user). Traffic classes a= nd scheduled in strict priority, while queues within a pipe traffic class a= re scheduled using byte-level Weighted Round Robin (WRR) with configured we= ights. Since we have 16 packet queues per pipe (user), we could argue that = actually 16 (sub)traffic classes are supported. When the weight ratio betwe= en different queues of the same traffic class is high (e.g. 4:1, 8:1, 16:1,= etc), then WRR starts behaving like strict priority. If your mapping to tr= affic classes is done using DSCP, you can simply map some DSCP values to di= fferent queues within same traffic class as well. Im developing a deep packet inspection solution for a telecom company and i we need more than just 4 traffic classes per pipe. Im able to recognise almost all layer 7 applications, such as youtube, p2p , netflix , google-ads , etc, etc and i really need to map this type of flows in differents traffic classes. [Cristian] Not sure I completely agree with you here. = The traffic classes are there for the reason of providing different levels = of delay (latency), delay variation (jitter), packet loss rate, etc. So, fo= r example, one possible mapping of traffic types to the 4 traffic classes m= ight be: voice =3D TC0 (highest priority), interactive video =3D TC1, non-i= nteractive/cached video =3D TC2, best effort traffic (file downloads, web b= rowsing, email, etc) =3D TC3 (lowest priority). In my opinion, youtube and = netflix could be considered as being part of the same traffic class (e.g. T= C2), as they have very similar (if not identical) requirements, probably sa= me for p2p and google-ads, email, web browsing, etc (where best effort traf= fic class is probably applicable). If really needed, youtube and netflix co= uld be mapped to different queues of TC2. If different service / actions need to be applied to different applications= that have the same scheduling requirements (and part of the same traffic c= lass), then this would probably have to be decided earlier during the class= ification phase and e.g. rate limit youtube traffic per user using traffic = metering algorithms, block p2p traffic if you are a firewall, etc; these ar= e probably actions that could be enforced outside of scheduling/traffic man= agement. The idea is mark each flow depending on the provisioning information and assign that flows to different subport depending on the information given and assign a pipe with the subscriber contract rate, but we really need to have more than 4 traffic clases, because we want to control the bandwidth of different layer 7 protocols flows. At most we need 32 or 64 traffic classes per subscriber. [Cristian] Bandwidth control could be done on both ingress side as well as = egress side. = On ingress, the amount of incoming traffic for a specific user (flow/connec= tion/application) could be limited to predefined values, with potentially d= ifferent levels for different classes of users (e.g. regular / premium / co= mpany / etc). On egress, several pipe profiles can be defined using the DPDK hierarchical= scheduler, which would allow setting up a different rate limit for each tr= affic class for each user. Likewise, traffic classes can be rate limited at= the subport level (group of users). I understand that in a given interval of time a subscriber dont use more than 4 protocols simultaneously , generally speaking , or 4 traffic classes in dpdk qos terminology, but the framework doesnt allow us to configure more traffic classes. Im looking the code of qos scheduler and im not seeing why this restriction. Is a performance problem, or a waste of resource problem? , maybe when the port grinder search for the active queues for each traffic class the delay of iterating over all pipes and each traffic class is too high. Cisco have a bandwidth managment solution that claims to control a million of subscribers simoultaneosly with 64 traffic classes per subscriber (pipes) and 4 queues per traffic classes (Cisco solution calls traffic clases as "Bandwith controller per service or BWC , a subscriber can have 64 BWC simoultaneasly). Its this posible? maybe this guys implements the bandwidth managment in hardware?. Anyway i really need this feature , but if the qos scheduller cannot scale to more than 4 traffic classes per pipe i would have to implement a custom packet scheduler from scratch and i really dont want to do that. Thanks for the patience, and sorry for my rusty english, im from Argentina. Best Regards. Ariel Horacio Rodriguez, Callis Technologies. -------------------------------------------------------------- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the s= ole use of the intended recipient(s). Any review or distribution by others = is strictly prohibited. If you are not the intended recipient, please conta= ct the sender and delete all copies.