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: virtio-dev-unsubscr...@lists.oasis-open.org < For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
