[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [PATCH V6 1/2] virtio-gpio: Add the device specification
On Tue, 27 Jul 2021 at 17:37, Arnd Bergmann <arnd@kernel.org> wrote: > On Tue, Jul 27, 2021 at 12:56 PM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > If we send only one notification at the end, it takes ~ 1ms for 256 > > GPIO pins, pretty much like a single request only. The downside here > > is that the device (host) also needs to prepare the queue for equal > > number (to ngpio) of elements. This is something the spec hasn't > > touched until now, i.e. how many buffers must be queued for the > > virtqueues. The max allowed in qemu is 1024 right now. > > 1ms is borderline I guess, it's close to the range of things that gets > annoying for boot-time optimization. > > > Even if I send them sequentially, with separate notification for each > > request, it takes ~15-20 ms to finish 256 lines and ~80 for 1024 > > lines. > > > > Though a single request still sounds tempting to me :) > > Right, 80ms is definitely noticeable, this can easily make the difference > between an instant guest boot and a perceived delay. It is also important to mention here that in my current example, there was no copy of the gpio line name string made anywhere. If we choose this message to be per-line, then there will be at least one memcpy at the host of the string for each GPIO line, there may be another copy somewhere in between at guest or host, not sure. Though in case of a single request, this will be a single memcpy operation at the guest (and others in between as mentioned earlier), but not per line and maybe more efficient. So even in the best possible scenario, this will be several ms, at least for separate message for each GPIO line. Anyway, how do you suggest I define this call now. Per-line or entire block (fixed size or from config structure) ? I will do it the way you suggest to cut short the discussion :) > > I am not sure how we can do that :( > > I suppose not without a complete redesign from scratch. Yeah, I am not doing it then :) -- viresh
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]