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: [PATCH v3 6/8] admin: Add theory of operation for write recording commands


On Tue, Nov 14, 2023 at 3:34âPM Zhu, Lingshan <lingshan.zhu@intel.com> wrote:
>
>
>
> On 11/13/2023 2:57 PM, Michael S. Tsirkin wrote:
> > On Mon, Nov 13, 2023 at 11:31:37AM +0800, Jason Wang wrote:
> >> On Thu, Nov 9, 2023 at 3:59âPM Michael S. Tsirkin <mst@redhat.com> wrote:
> >>> On Thu, Nov 09, 2023 at 11:31:27AM +0800, Jason Wang wrote:
> >>>> On Wed, Nov 8, 2023 at 4:17âPM Michael S. Tsirkin <mst@redhat.com> wrote:
> >>>>> On Wed, Nov 08, 2023 at 12:28:36PM +0800, Jason Wang wrote:
> >>>>>> On Tue, Nov 7, 2023 at 3:05âPM Michael S. Tsirkin <mst@redhat.com> wrote:
> >>>>>>> On Tue, Nov 07, 2023 at 12:04:29PM +0800, Jason Wang wrote:
> >>>>>>>>>>> Each virtio and non virtio devices who wants to report their dirty page report,
> >>>>>>>>>> will do their way.
> >>>>>>>>>>>> 3) inventing it in the virtio layer will be deprecated in the future
> >>>>>>>>>>>> for sure, as platform will provide much rich features for logging
> >>>>>>>>>>>> e.g it can do it per PASID etc, I don't see any reason virtio need
> >>>>>>>>>>>> to compete with the features that will be provided by the platform
> >>>>>>>>>>> Can you bring the cpu vendors and committement to virtio tc with timelines
> >>>>>>>>>> so that virtio TC can omit?
> >>>>>>>>>>

[...]

> > On the other hand they have an extra CPU cost.  Personally if this is
> > coming from a hardware vendor, I am inclined to trust them wrt PCI
> > transactions.  But anyway, discussing this at a high level theoretically
> > is pointless - whoever bothers with actual prototyping for performance
> > testing wins, if no one does I'd expect a back of a napkin estimate
> > to be included.
> if so, Intel has released productions implementing these interfaces
> years ago,
> see live migration in 4.1. IFCVF vDPA Implementation,
> https://doc.dpdk.org/guides-21.11/vdpadevs/ifc.html
> and
>
> But I still believe we are here try our best to work out an industrial spec
> with better quality, to serve broad interest. This is not competition
> between companies,
> and the spec is not a FIFO, not like a early bird can catch all the worm.


This is my understanding as well.

Thanks



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]