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