From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ea0-f173.google.com (mail-ea0-f173.google.com [209.85.215.173]) by dpdk.org (Postfix) with ESMTP id 551CD5934 for ; Fri, 29 Nov 2013 23:32:05 +0100 (CET) Received: by mail-ea0-f173.google.com with SMTP id g15so7220775eak.18 for ; Fri, 29 Nov 2013 14:33:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CU9KkE5iEcylcPlMLnM/KS4sRSjAHjMISgQNAaYCsuk=; b=UZCGv+9DKhEpe5el8XWmdoTtRfgmu5uKliDtyDhrKlRf5TbfoNp44UGfF8R6XU3eC4 daynCtcpXnlSmfCWbFzfY83apApusvBO3yBNv7Ytg+Piqz8v1DXyBYJy/J6XwZLDmgkC VSr+smiwhrN947Tj4mbh3WDVzb+Ef9RqP3W7IRTfyh19RVzt2Vk8zDeM+21Y7yHueeoe onvsCCpzl+bAqf2Mqm8ZBsJE72DPnocQIDcO6Antoxa1m/dJ9cUOWbbXknwrsBVR6bG8 Y0adJ8YOfz3CUGoVnJPHUt8PUw4+QK+S5upUVEL/4okBZWWBrLIpmSNUGM0p7yNEHy/m 4xfA== X-Gm-Message-State: ALoCoQltLp6P5coN9tu8lp0u5Siy5a9CIodn+ePxERMCt8Mx0d8wXZBvWAOyw9biY1QnkisQ4hCX MIME-Version: 1.0 X-Received: by 10.14.251.68 with SMTP id a44mr3651661ees.64.1385764385994; Fri, 29 Nov 2013 14:33:05 -0800 (PST) Received: by 10.14.89.4 with HTTP; Fri, 29 Nov 2013 14:33:05 -0800 (PST) X-Originating-IP: [200.69.240.117] In-Reply-To: <20131129132611.2ed0335c@nehalam.linuxnetplumber.net> References: <3EB4FA525960D640B5BDFFD6A3D891261A5D21F4@IRSMSX102.ger.corp.intel.com> <20131129132611.2ed0335c@nehalam.linuxnetplumber.net> Date: Fri, 29 Nov 2013 20:33:05 -0200 Message-ID: From: Ariel Rodriguez To: Stephen Hemminger Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" 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 22:32:05 -0000 Ok thats give the reason i need, yes i could change the number of bits of ,for example , pipe size which is 20 bytes but we need around a million of pipe (the telecom has a million of concurent subscribers). Thank you so much, i have to think about this, for the moment i believe we will use the 4 traffic classes and group the differents protocols to a traffic class. Maybe later i will ask some questions about the traffic metering. Thank you again , best regards, Ariel Horacio Rodriguez, Callis Technologies. On Fri, Nov 29, 2013 at 6:26 PM, Stephen Hemminger < stephen@networkplumber.org> wrote: > On Fri, 29 Nov 2013 17:50:34 -0200 > Ariel Rodriguez wrote: > > > Thanks for the answer, your explanation was perfect. > Unfortunally > > , the client requirements are those, we need at traffic control level > > around 64 traffic metering controlers (traffic classes) at subscriber > level. > > I think you maybe confused by the Intel QoS naming. It is better to > think about it as 3 different classification levels and not get too hung > up about the naming. > > The way to do what you want that is with 64 different 'pipes'. > In our usage: > subport => VLAN > pipe => subscriber matched by tuple > traffic class => mapping from DSCP to TC > > > > Each subscriber have a global plan rate (each pipe have the > same > > token bucket configuration), inside that plan there are different rules > for > > the traffic (traffic classes). For Example, facebook traffic, twitter > > traffic, whatsapp traffic have different plan rates lower than the plan > > global rate but different than the others protocols. We could group those > > in one traffic class, but still the 4 traffic classes is a strong > > limitation for us, beacause each protocol mapped to a traffic class share > > the same configuration (facebook traffic, twitter traffic have had the > same > > rate and more, they compete for the same traffic class rate). > > We have to compete against cisco bandwith control solution and > at > > least we need to offer the same features. The cisco solution its a DPI > but > > also a traffic control solution, its permit priorization of traffic and > > manage the congestion inside the network per subscriber and per > application > > service. So apperently the dpdk qos scheduller doesnt fit for our needs. > > Anyway, i still doesnt understand the traffic classes > limitation. > > Inside the dpdk code of the qos scheduler i saw this: > > > > /** Number of queues per pipe traffic class. Cannot be changed. */ > > #define RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS 4 > > > I follow where the code use that define and except for the > struct > > rte_sched_port_hierarchy where its mandatory a bitwise field of two > (0...3) > > , i dont see where is the limitation here (except for performance). Its > > worth to change the code to support more than 4 traffic classes, well i > > could try to change the code more precisely jejeje. I just want to know > if > > there are another limitation than a design desicion of that number. I > dont > > want to make the effort for nothing maybe you guys can help me to > > understand why the limitation. > > I strongly use the dpdk solution for feed our dpi solution, i > > wont change that because work greats!!! but its difficult to develop a > > traffic control managment from scratch and integrated with the dpdk in a > > clean way without touching the dpdk api, you guys just done that with the > > qos scheduler, i dont want to reinvent the wheel. > > Again thank you for the patience, and for your expertise. > > > The limitation on number's of TC (and pipes) comes from the number of > bits available. Since the QoS code overloads the 32 bit RSS field in > the mbuf there isn't enough bits to a lot. But then again if you add lots > of pipes or subports the memory footprint gets huge. > > Since it is open source, you could reduce the number of bits for one > field and increase the other. But having lots of priority classes > would lead to poor performance and potential starvation. >