Re: [Qemu-devel] [PATCH 3/4] cryptodev-vhost-user: add crypto session handler

[Michael S. Tsirkin]

On Wed, Nov 29, 2017 at 02:33:59AM +0000, Gonglei (Arei) wrote:
> 
> > -----Original Message-----
> > From: Paolo Bonzini [mailto:address@hidden
> > Sent: Tuesday, November 28, 2017 7:20 PM
> > To: Gonglei (Arei); address@hidden
> > Cc: address@hidden; Huangweidong (C); address@hidden; Zhoujian
> > (jay); address@hidden; longpeng; address@hidden;
> > address@hidden
> > Subject: Re: [PATCH 3/4] cryptodev-vhost-user: add crypto session handler
> > 
> > On 28/11/2017 12:06, Gonglei (Arei) wrote:
> > >>> You mean we can share control virtqueue to DPDK as well? Like data
> > queues?
> > >> I don't know :) but why not?
> > >>
> > > Current there are two main reasons for this design:
> > >
> > > 1) we should use another cpu to polling the control virtqueue, which is
> > expensive.
> > 
> > IIRC DPDK also supports interrupt mode, doesn't it?  Is it possible to
> > do interrupt mode for some virtqueues and poll mode for others?
> > 
> 
> The intel guy Tan (Ccing) said to me:
> 
> " Interrupt mode for vhost-user is still not supported in current 
> implementation. But we are evaluating the necessity now.

That's more or less a spec violation. Guest must get interrupts
if it does not disable them. And it must notify host
if host does not disable notifications.

> And yes, the mode (polling or interrupt) can be different for different 
> queues."
> 
> > > 2) we should copy the logic of parsing control message to DPDK, which 
> > > break
> > >  current layered architecture .
> > 
> > But isn't it already a layering violation that you're adding *some*
> > control messages to the vhost-user protocol?  I am not sure why only
> > these two are necessary.
> > 
> Sorry, but I don't think this is layering violation, just like 
> "vhost_net_set_mtu"
> for vhost-net and "vhost_vsock_set_guest_cid_op" for vhost_vsock. They're all
> device-specific messages. Aren't they?
> 
> Thanks,
> -Gonglei
> 
> > Paolo
> > 
> > > I'm not sure if there are any other hidden issues for future scalability, 
> > > such as
> > > using Qemu to manage some control messages, avoiding D-Dos attack etc.
> > >
> > > Thanks,
> > > -Gonglei
>