RARE user and assistance email list

[mc36 <>]

hi,
going inline!
regards,
cs


On 9/5/20 10:19 AM, Frédéric LOUI wrote:
> 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 ...)
imho we cannot disable aes-ni, maybe within qemu by eabling/disabling cpu 
features provided to vm...
anyway openssl is quite mature and i bet you does the best available in terms 
of performance
even in the case when no aes-ni is available...


> > 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
[..]

> 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 ?
imho txe is for something else: 
https://en.wikipedia.org/wiki/Intel_Management_Engine
in short, you can brick the board remotely with this enabled! :)

> > 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...
yesss ncs5k uses broadcom and mostly switch asics also found in nexus 7k so 
it's quite normal that they have macsec...
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>