> 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…
>
> 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.
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).
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/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
