[dpdk-dev] Regarding VM live migration with SRIOV
Hi Stephen, Agreed that the current code does not directly support hotplug. Now I am looking for a hint regarding how best the DPDK application can find out that the PCI device on which it was doing the I/O has been removed from underneath. In that case the application can call the ethdev stop and ethdev close functions gracefully. Question is -- is there a way for the PMD to know that the device is gone. Further the PCI device is a mapped memory, so when the plugout of the PCI device happen, is the DPDK application, which is doing I/O, vulnerable to a crash ? Regards -Prashant -Original Message- From: Stephen Hemminger [mailto:step...@networkplumber.org] Sent: Wednesday, November 27, 2013 11:54 AM To: Prashant Upadhyaya Cc: dev at dpdk.org Subject: Re: [dpdk-dev] Regarding VM live migration with SRIOV On Wed, 27 Nov 2013 11:39:28 +0530 Prashant Upadhyaya wrote: > Hi Stephen, > > The rte_eal_pci_probe is typically called at the startup. > > Now let's say a DPDK application is running with a PCI device (doing > tx and rx) and I remove that PCI device underneath (hot plugout) So how does > the application now know that the device is gone ? > > Is it that rte_eal_pci_probe should be called periodically from, let's say, > the slow control path of the DPDK application ? > > Regards > -Prashant > Like I said current code doesn't do hotplug. If you wanted to add it, you would have to refactor the PCI management layer. === Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. ===
[dpdk-dev] Unable to build dpdk : #error "SSSE3 instruction set not enabled"
Hi, I am a beginner with dpdk and trying to follow the instructions in http://www.dpdk.org/doc/quick-start I am seeing the following error when doing make with 1.5.0r2 or 1.5.1r1 == Build lib/librte_meter == Build lib/librte_sched CC rte_sched.o In file included from /home/surya/dpdk/dpdk-1.5.1r1/lib/librte_sched/rte_bitmap.h:77:0, from /home/surya/dpdk/dpdk-1.5.1r1/lib/librte_sched/rte_sched.c:47: /usr/lib/gcc/x86_64-linux-gnu/4.6/include/tmmintrin.h:31:3: error: #error "SSSE3 instruction set not enabled" make[3]: *** [rte_sched.o] Error 1 make[2]: *** [librte_sched] Error 2 make[1]: *** [lib] Error 2 make: *** [all] Error 2 I am running this on a Ubuntu VM (12.04) with gcc version 4.6.3 It built fine on another vm where I have Ubuntun 13.10 with gcc version 4.8.1 Should I upgrade to 4.8.1 here as well (it has become a long process with lot of road blocks) or is there any simple fix? The DPDK doc says I just need gcc versions 4.5.x or later. Thanks, Surya
[dpdk-dev] Unable to build dpdk : #error "SSSE3 instruction set not enabled"
Changing the CPU type emulation to some model that supports SSSE3 solved it (e.g. core2duo) should do the trick. I faced the same problem sometime ago. best marc On 29/11/13 11:39, Surya Nimmagadda wrote: > Hi, > > I am a beginner with dpdk and trying to follow the instructions in > http://www.dpdk.org/doc/quick-start > > I am seeing the following error when doing make with 1.5.0r2 or 1.5.1r1 > > == Build lib/librte_meter > == Build lib/librte_sched >CC rte_sched.o > In file included from > /home/surya/dpdk/dpdk-1.5.1r1/lib/librte_sched/rte_bitmap.h:77:0, > from > /home/surya/dpdk/dpdk-1.5.1r1/lib/librte_sched/rte_sched.c:47: > /usr/lib/gcc/x86_64-linux-gnu/4.6/include/tmmintrin.h:31:3: error: #error > "SSSE3 instruction set not enabled" > make[3]: *** [rte_sched.o] Error 1 > make[2]: *** [librte_sched] Error 2 > make[1]: *** [lib] Error 2 > make: *** [all] Error 2 > > I am running this on a Ubuntu VM (12.04) with gcc version 4.6.3 > > It built fine on another vm where I have Ubuntun 13.10 with gcc version 4.8.1 > > Should I upgrade to 4.8.1 here as well (it has become a long process with lot > of road blocks) or is there any simple fix? > > The DPDK doc says I just need gcc versions 4.5.x or later. > > Thanks, > Surya >
[dpdk-dev] Sporadic errors while initializing NICs in example applications, dpdk-1.5.0r1
Hmm, that's strange. I don't know how to interpret my observations then. I have access to two platforms, one is based on Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz and another on Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz. Both running ubuntu-12.04 server. I see repeating errors on NIC initialisation phase. The error frequency greatly reduces if I patch loop limit as I described earlier or if I call rte_power_init and rte_power_freq_max as Thomas suggested. But the only way to get rid of them completely is to set performance governor. On 11/28/2013 03:01 PM, Richardson, Bruce wrote: >> It's probably due to a frequency scaling. >> The timer based is initialized when DPDK initialize and the CPU can change >> its frequency, breaking next timers. >> >> The fix is to control the CPU frequency. >> Please try this, without your patch: >> for g in /sys/devices/system/cpu/*/cpufreq/scaling_governor; do >> echo performance >$g; done The right fix for applications (examples and >> testpmd included) could be to call rte_power_init(). Patches are welcomed. >> > [BR] Frequency changes should not affect timers for modern Intel CPUs. Please > see the " Intel(r) 64 and IA-32 Architectures Software Developer's Manual" > Volume 3 > (http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-system-programming-manual-325384.pdf) > , Section 17.13 for more details on this. >
[dpdk-dev] Sporadic errors while initializing NICs in example applications, dpdk-1.5.0r1
29/11/2013 14:53, Dmitry Vyal : > On 11/28/2013 03:01 PM, Richardson, Bruce wrote: > >> It's probably due to a frequency scaling. > >> The timer based is initialized when DPDK initialize and the CPU can > >> change > >> its frequency, breaking next timers. > >> > >> The fix is to control the CPU frequency. > >> > >> Please try this, without your patch: > >>for g in /sys/devices/system/cpu/*/cpufreq/scaling_governor; do > >> > >> echo performance >$g; done The right fix for applications (examples and > >> testpmd included) could be to call rte_power_init(). Patches are > >> welcomed. > > > > [BR] Frequency changes should not affect timers for modern Intel CPUs. > > Please see the " Intel(r) 64 and IA-32 Architectures Software Developer's > > Manual" Volume 3 > > (http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-i > > a-32-architectures-software-developer-system-programming-manual-325384.pdf > > ) , Section 17.13 for more details on this. > > Hmm, that's strange. I don't know how to interpret my observations then. > I have access to two platforms, one is based on Intel(R) Xeon(R) CPU > E3-1230 V2 @ 3.30GHz and another on Intel(R) Xeon(R) CPU E3-1270 v3 @ > 3.50GHz. Both running ubuntu-12.04 server. I see repeating errors on NIC > initialisation phase. The error frequency greatly reduces if I patch > loop limit as I described earlier or if I call rte_power_init and > rte_power_freq_max as Thomas suggested. > > But the only way to get rid of them completely is to set performance > governor. Please check that your hardware do not support invariant TSC. It would explain why you need to fix frequency. I attach a simple code to test CPU feature "Invariant TSC". -- Thomas
[dpdk-dev] Unable to build dpdk : #error "SSSE3 instruction set not enabled"
Hi Surya, SSE3 instructions are not enabled by default. To enable, you can either tell gcc your CPU architecture (-march=) as suggested by Marc, or enable just the specific SSE version that's supported by your CPU (e.g., make TOOLCHAIN_CFLAGS="-msse4") See http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html for a list of CPU architectures and instruction flags. Regards, Etai -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Marc Sune Sent: Friday, November 29, 2013 12:53 PM To: dev at dpdk.org Subject: Re: [dpdk-dev] Unable to build dpdk : #error "SSSE3 instruction set not enabled" Changing the CPU type emulation to some model that supports SSSE3 solved it (e.g. core2duo) should do the trick. I faced the same problem sometime ago. best marc On 29/11/13 11:39, Surya Nimmagadda wrote: > Hi, > > I am a beginner with dpdk and trying to follow the instructions in > http://www.dpdk.org/doc/quick-start > > I am seeing the following error when doing make with 1.5.0r2 or > 1.5.1r1 > > == Build lib/librte_meter > == Build lib/librte_sched >CC rte_sched.o > In file included from /home/surya/dpdk/dpdk-1.5.1r1/lib/librte_sched/rte_bitmap.h:77:0, > from /home/surya/dpdk/dpdk-1.5.1r1/lib/librte_sched/rte_sched.c:47: > /usr/lib/gcc/x86_64-linux-gnu/4.6/include/tmmintrin.h:31:3: error: #error "SSSE3 instruction set not enabled" > make[3]: *** [rte_sched.o] Error 1 > make[2]: *** [librte_sched] Error 2 > make[1]: *** [lib] Error 2 > make: *** [all] Error 2 > > I am running this on a Ubuntu VM (12.04) with gcc version 4.6.3 > > It built fine on another vm where I have Ubuntun 13.10 with gcc > version 4.8.1 > > Should I upgrade to 4.8.1 here as well (it has become a long process with lot of road blocks) or is there any simple fix? > > The DPDK doc says I just need gcc versions 4.5.x or later. > > Thanks, > Surya >
[dpdk-dev] Sporadic errors while initializing NICs in example applications, dpdk-1.5.0r1
29/11/2013 13:25, Thomas Monjalon :
> 29/11/2013 14:53, Dmitry Vyal :
> > On 11/28/2013 03:01 PM, Richardson, Bruce wrote:
> > > [BR] Frequency changes should not affect timers for modern Intel CPUs.
> > > Please see the " Intel(r) 64 and IA-32 Architectures Software
> > > Developer's
> > > Manual" Volume 3
> > > (http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64->
> > > > > i
> > > a-32-architectures-software-developer-system-programming-manual-325384.p
> > > df
> > > ) , Section 17.13 for more details on this.
> >
> > Hmm, that's strange. I don't know how to interpret my observations then.
> > I have access to two platforms, one is based on Intel(R) Xeon(R) CPU
> > E3-1230 V2 @ 3.30GHz and another on Intel(R) Xeon(R) CPU E3-1270 v3 @
> > 3.50GHz. Both running ubuntu-12.04 server. I see repeating errors on NIC
> > initialisation phase. The error frequency greatly reduces if I patch
> > loop limit as I described earlier or if I call rte_power_init and
> > rte_power_freq_max as Thomas suggested.
> >
> > But the only way to get rid of them completely is to set performance
> > governor.
>
> Please check that your hardware do not support invariant TSC.
> It would explain why you need to fix frequency.
>
> I attach a simple code to test CPU feature "Invariant TSC".
It seems that the file is stripped on the mailing-list.
Code inlined:
#include
#include
#include
#include
int main()
{
uint32_t a = 0x8000;
uint32_t b, d;
__asm__("cpuid;"
:"=a"(b)
:"0"(a));
if (b >= 0x8007) {
a = 0x8007;
__asm__("cpuid;"
:"=a"(b), "=d"(d)
:"0"(a));
if (d & (1<<8)) {
printf("Invariant TSC is supported\n");
} else{
printf("Invariant TSC is NOT supported\n");
}
} else {
printf("No support for Advanced Power Management Information in
CPUID\n");
}
return 0;
}
[dpdk-dev] Sporadic errors while initializing NICs in example applications, dpdk-1.5.0r1
Thomas29/11/2013 13:25, Monjalon : > 29/11/2013 14:53, Dmitry Vyal : > > On 11/28/2013 03:01 PM, Richardson, Bruce wrote: > > > [BR] Frequency changes should not affect timers for modern Intel CPUs. > > > > The error frequency greatly reduces if I patch > > loop limit as I described earlier or if I call rte_power_init and > > rte_power_freq_max as Thomas suggested. > > > > But the only way to get rid of them completely is to set performance > > governor. > > Please check that your hardware do not support invariant TSC. > It would explain why you need to fix frequency. > > I attach a simple code to test CPU feature "Invariant TSC". Note that this feature is called constant_tsc in /proc/cpuinfo: grep --color -m1 constant_tsc /proc/cpuinfo It is checked by check_tsc_flags() at DPDK initialization and should print a warning if missing: http://dpdk.org/browse/dpdk/commit/?id=e7c8996e13b9abb706ea0de53271346f4f86ca03 -- Thomas
[dpdk-dev] 4 Traffic classes per Pipe limitation
Hi Ariel, some comments inlined below. Regards, Cristian -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ariel Rodriguez Sent: Thursday, November 28, 2013 8:53 PM To: dev at 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 with 4 packet queues per traffic class for each pipe (user). Traffic classes and scheduled in strict priority, while queues within a pipe traffic class are scheduled using byte-level Weighted Round Robin (WRR) with configured weights. Since we have 16 packet queues per pipe (user), we could argue that actually 16 (sub)traffic classes are supported. When the weight ratio between 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 traffic classes is done using DSCP, you can simply map some DSCP values to different 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, for example, one possible mapping of traffic types to the 4 traffic classes might be: voice = TC0 (highest priority), interactive video = TC1, non-interactive/cached video = TC2, best effort traffic (file downloads, web browsing, email, etc) = TC3 (lowest priority). In my opinion, youtube and netflix could be considered as being part of the same traffic class (e.g. TC2), as they have very similar (if not identical) requirements, probably same for p2p and google-ads, email, web browsing, etc (where best effort traffic class is probably applicable). If really needed, youtube and netflix could 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 class), then this would probably have to be decided earlier during the classification phase and e.g. rate limit youtube traffic per user using traffic metering algorithms, block p2p traffic if you are a firewall, etc; these are probably actions that could be enforced outside of scheduling/traffic management. 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/connection/application) could be limited to predefined values, with potentially different levels for different classes of users (e.g. regular / premium / company / 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 traffic 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 s
[dpdk-dev] 4 Traffic classes per Pipe limitation
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. 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_CLASS4 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. Regards, Ariel Horacio Rodriguez. Callis Technologies. On Fri, Nov 29, 2013 at 3:45 PM, Dumitrescu, Cristian < cristian.dumitrescu at intel.com> wrote: > Hi Ariel, some comments inlined below. Regards, Cristian > > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ariel Rodriguez > Sent: Thursday, November 28, 2013 8:53 PM > To: dev at 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 > with 4 packet queues per traffic class for each pipe (user). Traffic > classes and scheduled in strict priority, while queues within a pipe > traffic class are scheduled using byte-level Weighted Round Robin (WRR) > with configured weights. Since we have 16 packet queues per pipe (user), we > could argue that actually 16 (sub)traffic classes are supported. When the > weight ratio between 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 traffic classes is done using DSCP, you can simply map > some DSCP values to different 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, > for example, one possible mapping of traffic types to the 4 traffic classes > might be: voice = TC0 (highest priority), interactive video = TC1, > non-interactive/cached video = TC2, best effort traffic (file downloads, > web browsing, email, etc) = TC3 (lowest priority). In my opinion, youtube > and netflix could be considered as being part of the same traffic class > (e.g. TC2), as they have very similar (if not identical) requirements, > probably same for p2p and google-ads, email, web browsing, etc (where best > effort traffic class is probably applicable). If really needed, youtube and > netflix could be mapped to different queues of TC2. > If different service / actions nee
[dpdk-dev] 4 Traffic classes per Pipe limitation
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_CLASS4 > 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.
[dpdk-dev] 4 Traffic classes per Pipe limitation
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 at 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_CLASS4 > > > 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. >
