RARE user and assistance email list

[Frédéric LOUI <>]

Hi !

This is tremendous result !

And was just mentioning in the presentation during Jisc NGN VC that is had a 
"feasibility status"  (not RFS soon :) )
So don’t push too hard ... Get some rest !

> aes256+sha1!

Question, do you seen an improvement with/without AES-NI extension.
(Not sure if we can disable AES-NI … Maybe via the BIOS I don’t have sone so 
I can’t tell ...)

> and every interface could have it's own receiver and transmitter core 
> associated in dpdk...
So these are DPDK cores. 

> so we can safely say that enabling crypto on adds about a five multiplied 
> to the load so divides the performance by five.

Question: This is my dpdk-devbind —status

root@mjolnir:~# dpdk-devbind.py --status

Network devices using DPDK-compatible driver
============================================
0000:01:00.0 'I211 Gigabit Network Connection 1539' drv=uio_pci_generic 
unused=igb
0000:02:00.0 'I211 Gigabit Network Connection 1539' drv=uio_pci_generic 
unused=igb
0000:05:00.0 'I211 Gigabit Network Connection 1539' drv=uio_pci_generic 
unused=igb
0000:06:00.0 'I211 Gigabit Network Connection 1539' drv=uio_pci_generic 
unused=igb
0000:07:00.0 'I211 Gigabit Network Connection 1539' drv=uio_pci_generic 
unused=igb
0000:08:00.0 'I211 Gigabit Network Connection 1539' drv=uio_pci_generic 
unused=igb

Network devices using kernel driver
===================================
0000:09:00.0 'AR928X Wireless Network Adapter (PCI-Express) 002a' if=wlan0 
drv=ath9k unused=uio_pci_generic 

No 'Baseband' devices detected
==============================

Other Crypto devices
====================
0000:00:1a.0 'Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine 
0f18' unused=uio_pci_generic

No 'Eventdev' devices detected
==============================

No 'Mempool' devices detected
=============================

No 'Compress' devices detected
==============================

No 'Misc (rawdev)' devices detected
===================================

Is _THIS CRYPTO_ device: 
"
Other Crypto devices
====================
0000:00:1a.0 'Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine 
0f18' unused=uio_pci_generic
« 
And be of help andprovide hardware assisted computation ?

> regarding the rest of the dataplanes, nor bmv2 nor tofino have
> no crypto at all so until that changes, it'll be p4emu specific…
I’ll ask INTEL/BAREFOOT if they have plans for embedding crypto. How is doing 
Cisco ccs5k macsec linecard ?
I’ll try to have a look and see how these line cards are build… ncs seems not 
to use dedicated Cisco hardware...

> 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 ;)

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>