RARE user and assistance email list

[Simon Leinen <>]

mc36  writes:
> yesss ncs5k uses broadcom and mostly switch asics also found in nexus
> 7k so it's quite normal that they have macsec...

I don't think the Nexus 7000 uses Broadcom chipsets.

The NCS5k uses Broadcom "Jericho(+)" chipsets.  Note that these are
"genetically" different from the other Broadcom chipsets like
Trident/Tomahawk (used by e.g. Nexus 3100/3200 respectively), so feature
sets may differ.

If I read [1] correctly, the NCS5500 supports MACsec via separate chips
(on some linecards/for some ports).

According to [2], Cisco's Nexus 3400 uses the Tofino ASIC, and also uses
external chips ("Bear Valley") to provide MACsec en/decryption.

Broadcom announced a (dual) 400G MACsec PHY chip[3] in 2019.

This was interesting to check out. I had also thought that MACsec would
be something that people put on forwarding ASICs.  I'm sure there are
good reasons for not doing so.

Cheers,
-- 
Simon.

[1] 
https://xrdocs.io/ncs5500/tutorials/Understanding-ncs5500-jericho-plus-systems/
[2] 
https://www.nextplatform.com/2018/06/20/a-deep-dive-into-ciscos-use-of-merchant-switch-chips/
[3] 
https://www.broadcom.com/products/ethernet-connectivity/phy-and-poe/optical/bcm81343

> anyway ask9k also have it, but both only on their hungig ports, and only 
> with selected linecards...
> anyway asking bf about it seems good idea, at least they'll know that there 
> is user need for it,
> but imho it would not be the best place for it to appear: recall that cisco 
> initially proposed
> that macsec should be in the sfp+ and not on the linecards... finally that 
> heaven never happened,
> but for now, if bf implements crypto within their stuff itself then at 
> least we can apply that
> to different places of packet: the whole, after the vlan, after the gre, 
> and so on...

>> 
>>> regarding the future plans, obviously i'll go for ipsec!
>>> once that happens, we'll have an enterprise grade cpe.... :)
>> Let’s peer over IPsec once this is available ;)
>> 
> sure thing... ping me once you're ready... :)


>> Have a good week end !
>> À bientôt,
>> --  Frederic
>> 
>>> Le 5 sept. 2020 à 07:16, mc36 <> a écrit :
>>> 
>>> hi,
>>> 
>>> please find attached the fresh test runs with bmv2 and dpdk.
>>> news is macsec support in p4emu (dpdk, pcap).
>>> and even better news is that on a 7 years old i7-3770 it's does gigabit 
>>> on 1 cpucore with aes256+sha1!
>>> 
>>> and every interface could have it's own receiver and transmitter core 
>>> associated in dpdk...
>>> in case of pcap, every interface by default have an own thread to process 
>>> packets from the interface...
>>> 
>>> in the i7 case, iperfing at gigabit used 20% 1cpu then enabling macsec 
>>> bumped it to 120%. (it used p4dpdk)
>>> the opposite was a xeon, iperfing at gigabit used 70% 1cpu then enabling 
>>> macsec bumped it to 170% (it used p4pcap, this is why it have so high 
>>> initial cpu)
>>> so we can safely say that enabling crypto on adds about a five multiplied 
>>> to the load so divides the performance by five.
>>> 
>>> regarding the implementation, i linked against libcrypto (from openssl) 
>>> and to maintain
>>> full locklessness, i reinitalize the thread's own crypto contexts for 
>>> every packet.
>>> (did a quick testing with common contexts and did now saw any gain in 
>>> performance,
>>> but there could be algorithms that have much more expensive init 
>>> functions:)
>>> 
>>> regarding the rest of the dataplanes, nor bmv2 nor tofino have
>>> no crypto at all so until that changes, it'll be p4emu specific...
>>> 
>>> regarding the future plans, obviously i'll go for ipsec!
>>> once that happens, we'll have an enterprise grade cpe.... :)
>>> 
>>> regards,
>>> cs
>>> <rtrp4lang-bmv2-.csv><rtrp4lang-bmv2-.html><rtrp4lang-dpdk-.csv><rtrp4lang-dpdk-.html>
>>