Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio crypto device specification

[Halil Pasic <pasic@linux.vnet.ibm.com>]

On 09/18/2017 04:51 PM, Zeng, Xin wrote:
> On Monday, September 18, 2017 9:24 PM, Gonglei (Arei) wrote:
> 
> < > On 09/18/2017 02:13 PM, Gonglei (Arei) wrote:
> < > >> Destroy does not need to specify queue_id. That means session_id's aren't
> < > >> queue scoped from namespace perspective. The question remains what is
> < > >> queue_id good for, and whether a session type op request should be
> < > >> rejected if the the session id originates from a session creation
> < > >> request specifying a different dataqueue (not the dataqueue containing
> < > >> the given request)?
> < > >>
> < > > My original idea about the queue_id is using the queue_id to specify which
> < > > datequeue of the following data requests will be used. But after deep
> < > thinking,
> < > > I find that the queue_id is superfluous, and the current code in QEMU also
> < > > don't use the queue_id value as well. That's because the we can use
> < > session_id
> < > > to find the pervious session information and get the current dataqueue id
> < > > from the used virtqueue .
> < > >
> < > > So maybe we should drop the queue_id this time.
> < > >
> < > >
> < >
> < > Sounds reasonable to me. We can make it reserved and ignored in
> < > the specification. Linux uses it, but it's always set to 0 as we only
> < > support one data-queue (if I'm not wrong). So reserved and must be zero
> < > is an option too.
> < >
> < Makes sense to keeping compatibility.
> < 
> 
> If we always set it to 0, and backend device doesn't specify the queue
> id when creating session, this works only when one data queue is
> supported. But if we want to support multi data queues,
> how does frontend driver know which queue it should use when 
> sending requests to the virt queue? And furthermore, if the data queue 
> id which can be used is determined by backend device, how does 
> guest frontend driver know which queue can be used when operating
> in stateless mode in case multi data queue is supported?

AFAIU you answered your own questions (questions above, answers below). Gonglei
has just stated that he intends to abandon the queue_id.

> So from my point of view, session should only be associated with service
> related information, but not associated with the transport layer information,
> i.e. data queue id in this case. The data queue to be used should be chosen by
> frontend driver. Frontend driver can use any valid data queue to send requests
> to backend device, backend device need to extract the session information
> from the request packet and retrieve the request's session info then handle it 
> correspondingly.

AFAIU that's what we have agreed, basically. I'm not sure about your wording
(for instance I would have said session identifier instead of session information),
but I think we think the same. In short conceptually all configured data queues
are equivalent in the sense that it does not matter on which queue a request is
placed -- modulo capacity.

Halil

> 
> < Thanks,
> < -Gonglei
>