> On Nov 5, 2019, at 9:39 AM, Damjan Marion via Lists.Fd.Io > <dmarion=me....@lists.fd.io> wrote: > > > >> On 5 Nov 2019, at 15:17, Christian Hopps <cho...@chopps.org> wrote: >> >> A recent code review comment mentioned that src/plugins/dpdk/ipsec would be >> deprecated soon. >> >> IMO this should not happen until at least equal functionality has been put >> in place to replace it (and maybe not even then -- see my point at the end). > > Absolutely…
Great! :) >> I could be missing something, but here are the major limitations I see with >> the native crypto engine: >> >> - No support for buffer chains. > > Neither DPDK software supports them at this point. Limitation is coming from > underlying ipsec mb library. Oh, I have some local fixes to support this that I plan to upstream after they've been tested for a bit longer. > 2. AESN-NI Multi Buffer Crypto Poll Mode Driver > 2.2. Limitations > • Chained mbufs are not supported. > > 3. AES-NI GCM Crypto Poll Mode Driver > 3.2. Limitations > • Chained mbufs are supported but only out-of-place (destination mbuf > must be contiguous). This is an OK limitation for us. It just burns a buffer. Adding async operation and dpdk cryptodev support in the crypto-engine path (you mentione below) sounds like it takes care of my concerns. :) Thanks, Chris. > There is ongoing work to add chained buffer support, and in case when ipsec > mb is used we will need to copy to contiguous buffer and back (except in case > of GCM). > > I’m also going to add chained buffers to my native AESNI GCM code, as it is > preferred GCM engine today. > > >> - Lack of support seemingly a *lot* of crypto offload hardware >> (https://doc.dpdk.org/guides/cryptodevs/index.html) > > yep, we are working on new crypto async infra, which will use DPDK cryptodev > as one of crypto engines so hardware support will not change. > >> >> At my company we use both buffer chaining as well as Marvell mvsam offload >> HW, and have plans to utilize other offload HW from the above link. We also >> use the Intel crypto_aesni_gcm (not crypto_aesni_mb) driver as well. > > new async infra will allow people to integrate non-dpdk hw crypto, mvsam is > good example. > >> >> New 100G Bluefield hardware apparently has support for HW crypto offload, >> which we certainly would want to use. > > Not sure how is that going to work so hard to comment. > >> Even if VPP eventually adds support for the existing HW offload, will it >> also be adding it as quickly as it gets added to dpdk? We like VPP, but part >> of that is that VPP leverages the work that is also being done in DPDK. > > We will continue to use dpdk crpytodev, idea is removing duplicate untested > ipsec implementation, not removing dpdk cryptodev support. > >> >> One way around this might be to have a dpdk crypto engine that interfaced >> the newer native crypto-engine path to the existing dpdk offload drivers; >> however, I do not believe that code is there currently, perhaps I'm mistaken. > > Few people working on it, will be in the review soon. > > — > Damjan-=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#14506): https://lists.fd.io/g/vpp-dev/message/14506 > Mute This Topic: https://lists.fd.io/mt/42104088/1826170 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [cho...@chopps.org] > -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14507): https://lists.fd.io/g/vpp-dev/message/14507 Mute This Topic: https://lists.fd.io/mt/42104088/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
