On 1 June 2016 at 19:30, Ben Hammadi, Kayssar (Nokia - TN/Tunis) <[email protected]> wrote:
Hey, > As per my knowledge , when we mix DFC and CFC module , Sup capacity in term > of PPS will fall to 15MPPS , but I see some weird value such as 214 Billion > pps and 30 billion pps in the output below , what does this mean ? If linecard has DFC, lookup is done on the DFC and packet is sent over fabric to destination(s), i.e. it is not using lookup capacity of SUP. If linecard does not have DFC, then packet headers are sent over DBUS to SUP for lookup and lookup result is sent over RBUS (where each linecard copies it), and linecards not needing the packet purge it. It does not matter if you mix and match, behaviour is dictated by ingress linecard. Now the 15Mpps is not really exact number. The SUP lookup performance is limited by DBUS capacity. We can never congest the lookup engine itself, we simply don't have enough capacity towards it. DBUS is 62.5MHz and transfers 32B per cycle. IPv4 lookup uses 64B headers, IPv6 and MPLS lookup uses 96B headers. Consequently IPv4 is 62.5MHz/2cycles => 31.25Mpps, MPLS and IPv6 are 62.5MHz/3cycles => 20.83Mpps. If lookup also requires recirculation, for every recirculation needed performance is halved. 30Bpps, 214Bpps are bugs, those values are not possible. > Forwarding engine load: > Module pps peak-pps peak-time > 2 198313 181027384 21:56:54 GMT+1 Fri Apr 15 > 2016 > 3 379682 4092767857 08:55:20 GMT+1 Wed Dec 17 > 2014 > 4 0 149982456 14:10:33 GMT+1 Sun Jan 18 > 2015 > 5 1135379 21448701149 19:35:24 GMT+1 Sun Aug > 30 2015 > 6 16254 109212 16:35:01 GMT+1 Wed May 25 > 2016 > 7 459665 532775771 22:38:55 GMT+1 Wed Jan 7 > 2015 > 8 207789 21962852 08:28:16 GMT+1 Sun Jan 18 > 2015 > 9 384508 3050062992 17:49:49 GMT+1 Mon Mar 23 > 2015 -- ++ytti _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
