Re: [PATCH] virtio: i2c: Allow buffer less transactions

[Viresh Kumar <viresh.kumar@linaro.org>]

On 29-07-21, 14:18, Jie Deng wrote:
> The number of descriptors required for a request will not be fixed.

That is true today as well, as we allow 3 (write or read) or 4
(write-read) descriptors.

> If there is a descriptor sequence in the virtqueue, then you may need a
> state machine
> 
> to parse the sequence. For example, when you have
> 
> 
> WR      RR        ZR
> 
> O O I   O I I     O I
> 
> * WR:(write request), RR (read request), ZR (zero request), O: output
> descriptor, I: input descriptor
> 
> 
> When you encounter "O I" combination, you have to read the element after it
> to distinguish
> 
> RR and ZR. Will this bring unnecessary difficulties for the backend coding ?

I understand what you are saying, but at least all the backends that I
have worked with (Qemu and Rust), further categorizes these into
blocks and this is how it looks there (writing in qemu terminology):

VuVirtqElement *elem = vu_queue_pop();

elem->in_num and elem_out_num gives the number of out/in buffers
there.

And so there is no way one can get confused between two different
elements and you will always know if it is WR or RR or ZR.

Look at the implementation of vi2c_handle_ctrl() here in one of my
qemu implementations [1].

The same is true for Rust backend.

And so I thought it is evidently clear from virtio standard itself.
Otherwise even with the current specification, how will you know if it
is a WR or RR or WRR (write-read request).

Is my understanding correct ?

-- 
viresh

[1] https://lore.kernel.org/qemu-devel/e0adcd9552cee4de0ee844f6b3c87fb2b2f2357c.1617278395.git.viresh.kumar@linaro.org/