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

[Zeng, Xin]

on September 19, 2017 12:33 AM Halil Pasic 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.

Actually I agreed with your point to make queue_id reserved  in 
current implementation and ignored in the spec. I just want to clarify the 
usage of virt queues especially when multi data queue is supported.
Now it's clear, thanks.

Cheers
Xin

< 
< Halil
< 
< >
< > < Thanks,
< > < -Gonglei
< >n
< 
< 
< ---------------------------------------------------------------------
< To unsubscribe, e-mail: address@hidden
< For additional commands, e-mail: address@hidden