[f-nsp] Multicast causing high CPU

[Alexey Kouznetsov]

Hello!

Yes, it is IronCore, not Jet

/Alexey

2009/3/7 Peter Olsen <Peter.Olsen at globalconnect.dk>

>  Is it IronCore mgmt module ?
>
> If yes, it is properly even worse.
>
> We discussed this in legth with foundry. To my opinion it is a design bug:
> stating wire speed packet forward performance and then having limitations
> like this.
> I don't know if there is a fix for you. But we gave up in the end, and as
> we for other reasons as well needed bigger boxes we have replaced nearly all
> JetCore with XMR/MLX
>
>
> *Med venlig hilsen/Best regards
>
> **Peter Olsen
> **CTO
> **D: +45 7730 3122
> **M: +45 2726 3122
> *
>
>
>  ------------------------------
> *From:* Alexey Kouznetsov [mailto:foundry-list at kouznetsov.com]
> *Sent:* 7. marts 2009 14:58
> *To:* Peter Olsen
> *Subject:* Re: [f-nsp] Multicast causing high CPU
>
>   Thank you, for your replay Peter!
>
> This is no Jet core... AFAIK Jet core will be J-BxGMR4 and CPU protection
> is not available in our version. As far as I can see it takes 100%CPU at
> less 10kpps, not 200k
> Active management module:
>   466 MHz Power PC processor 750 (version 8/8302) 66 MHz bus
>   512 KB boot flash memory
>  8192 KB code flash memory
>   256 KB SRAM
>   256 MB DRAM
> So, As far as I  can see only hardware upgrade is the possible solution ?
>
> /Alexey
>
> 2009/3/7 Peter Olsen <Peter.Olsen at globalconnect.dk>
>
>>  JetCore FPGA can handle around 200.000pps broadcast/multicast before you
>> have ~80-100% CPU load as far as L2 is concerned
>> All packets is handled by CPU by default.
>> You can play around with the CPU protection features but to my experience
>> it have limited impact (and limited success as far as CPU load is concerned)
>> I guess this is kind of architecture limitation in JetCore.
>>
>> It is even worse if you have the same mac adress arriving from two
>> different directions, e.g. hitting two port at the same time. (will happen
>> if you have a L2 loop), then 99% CPU load will happen at very load pps. In
>> this case it is caused by the mac learning process eating all CPU
>> resources. This behaviour makes JetCore L2 very sensitive to layer2 loops.
>>
>> For us it was first efficiently fixed going to MLX/XMR where
>> CPU-protection feature is very efficient and you can force all
>> braodcast/multicast packets to stay in hardware for forwarding. XMR/MLX can
>> also handle much more than 200.000pps in CPU
>>
>> br,
>> Peter
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20090310/63730f7d/attachment.html>