OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[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]