[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 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. 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. 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? -- MST
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]