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

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

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


Subject: Re: [PATCH v10] virtio-net: support device stats



å 2022/3/1 äå8:25, Michael S. Tsirkin åé:
On Tue, Mar 01, 2022 at 07:32:23PM +0800, Xuan Zhuo wrote:
I have to say, this design is really good.

I think one of the core points of your design is to separate drop stats, gso
stats, etc. Get the stats you want based on negotiation and needs. And covering
the control queue, I am very surprised.

But does this design solve the problem of expansion? Various stats independent
structures seem to be convenient for expansion. But is this expansion ready for
dynamic negotiation?
For negotiation, we can either separate feature flags for each supported
type, or do like RSS and add commands for querying supported types
and enabling stats collection.


I think new command would be better but I don't understand why we need the logic of enable/disable?


Features is probably easier
for now ... Also, do we need to enable/disable stat collection?



My earliest solution is dynamic negotiation, that is, the driver tells the
device how many stats it wants to get. And the device negotiates how many stats
it should give to the driver based on this information of the driver.

But that's not great for migration. So gave up.  @Jason
Any optional feature is problematic for migration, at least with
features device knows ahead of the time what does driver
want to use.


If we tie e.g RSS stats command to RSS feature, we won't have any problem.

Thanks






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