[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] [PATCH v3 1/4] Add VIRTIO_RING_F_INDIRECT_SIZE
On Sonntag, 20. März 2022 22:52:16 CET Michael S. Tsirkin wrote: > On Sun, Mar 20, 2022 at 06:43:53PM +0100, Christian Schoenebeck wrote: > > To be honest, I don't feel like discussing precise wordings at this point > > when you are questioning the proposal on design level already. > > > > Maybe you make some more thorough thoughts on what you actually want this > > to be on design level before continueing to argue about precise > > terminology, which you are not using either BTW when you articulating > > your criticism. > > > > Or even better: come up with your own proposol with the precise wording > > you > > feel appropriate. > > OK let's go back and agree on what we are trying to achieve. The github > issue and the cover letter imply that while indirect descriptors would > normally allow huge tables, we artificially limit them to queue size, > and you want to be able to relax that. Correct, that's my motivation for all of this. > Fair enough. > > However, I feel trying to talk about indirect descriptor is too narrow a > use-case, simply because the issue is not indirect at all. Why do we > limit number of segments? I think it's really because of backend > limitations. And indirect is only used by the frontend. So limiting > that is really going about it wrong. I am only aware about current implementation situation in QEMU and Linux kernel. As for those two: yes, it is not a limitation on Linux kernel side, but on QEMU side. As for other implementations: no idea. > So block for example has seg_max already. What should happen > if that exceeds queue size is not defined. > > So maybe we can generalize that making it device independent? > The litmus paper for this is the block and scsi devices, > we should be able to use the new feature as a super-set. > > Before we discuss solutions, did I formulate the problem correctly? Keep in mind that I never worked on virtio code or virtio spec before. I just started to review virtio implementation of QEMU and Linux kernel and the virtio spec in November, specifically in context of 9p. I definitely don't know all the other virtioo device classes out there. In other words: I can't help you on fitting this appropriately into a superset picture. Best regards, Christian Schoenebeck
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]