[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [PATCH] virtio: i2c: Allow buffer less transactions
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]