qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Zeng, Xin
Subject: Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio crypto device specification
Date: Mon, 18 Sep 2017 14:51:33 +0000

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?
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.

< Thanks,
< -Gonglei

reply via email to

[Prev in Thread] Current Thread [Next in Thread]