Re: [Qemu-devel] [RFC v1 1/1] virtio-crypto: Allow disabling of cipher algorithms for virtio-crypto device

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Jun 13, 2018 at 11:01:05AM -0400, Farhan Ali wrote:
> Hi Daniel
> 
> On 06/13/2018 05:37 AM, Daniel P. Berrangé wrote:
> > On Tue, Jun 12, 2018 at 03:48:34PM -0400, Farhan Ali wrote:
> > > The virtio-crypto driver currently propagates to the guest
> > > all the cipher algorithms that the backend cryptodev can
> > > support. But in certain cases where the guest has more
> > > performant mechanism to handle some algorithms, it would be
> > > useful to propagate only a subset of the algorithms.
> > 
> > I'm not really convinced by this.
> > 
> > The performance of crypto algorithms has many influencing
> > factors, making it pretty hard to decide which is best
> > without actively testing specific impls and comparing
> > them in a manner which matches the application usage
> > pattern. eg in theory the kernel crypto impl of an alg
> > is faster than a userspace impl, if the kernel uses
> > hardware accel and userspace does not. This, however,
> > ignores the overhead of the kernel/userspace switch.
> > The real world performance winner, thus depends on the
> > amount of data being processed in each operation. Some
> > times userspace can win & sometimes kernel space can
> > win. This is even more relevant to virtio-crypto as
> > it has more expensive context switches.
> 
> True. But what if the guest can perform some crypto algorithms without a
> incurring a VM exit? For example in s390 we have the cpacf instructions to
> perform crypto and this instruction is implemented for us by our hardware
> virtualization technology. In such a case it would be better not to use
> virtio-crypto's implementation of such a crypto algorithm.
> 
> At the same time we would like to take advantage of virtio-crypto's
> acceleration capabilities for certain crypto algorithms for which there is
> no hardware assistance.

IIUC, the kernel's crypto layer can support multiple implementations of
any algorithm. Providers can report a priority against implementations
which influences which impl is used in practice. So if there's a native
instruction for a partiuclar algorithm I would expect the impl registered
for that to be designated higher priority than other impls, so that it is
used in preference to other impls.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|