Re: RE: RE: About custom device counter

[Xuan Zhuo <xuanzhuo@linux.alibaba.com>]

On Mon, 19 Jun 2023 20:40:54 +0000, Parav Pandit <parav@nvidia.com> wrote:
>
>
> > From: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > Sent: Thursday, June 15, 2023 2:35 AM
>
> > > Debug counters are useful to have.
> > > I agree that they may be vendor specific.
> > > We often try to abstract and define as much as vendor neutral as possible.
> > >
> > > So we should probably first put our efforts to see if more than one vendor can
> > use it.
> >
> > I agree.
> >
> > >
> > > Assuming there is some vendor specific counters, I imagine to come from a
> > separate vendor specific query command.
> > > This is to keep standard counters to avoid mixing with vend_specific.
> >
> > Yes, I agree that these are two separate channels.
> >
> > But I don't think we need to wait for the first job to finish.
> >
> I am saying if you have a counter in mind, lets discuss if we can generalize it, and if we can it falls in the first general bucket.
> If we cannot it falls in second vendor specific bucket.


That is ok.


>
> > It is conceivable that standard counters will be displayed on ethtool in the
> > future. For counters from different manufacturers, we can display them in
> > /sys/class/net/eth0/vendor_couters.
> >
> I understood that you want to show device specific counters.
> We can avoid bringing up the sw interface for a moment.
> For above specific suggestion, vendor counters in sysfs for sure will not be acceptable as no vendor specific sysfs can exist anymore.
>
> One can implement devlink health reporting counters as needed.


I am ok for any way to show this to the users.


>
> > Here we can tell the user that these are only for the current device, and may
> > change during the migration process.
> >
> Sure.
>
> >
> > >
> > > > Of course I know that doing this might hurt migration. But what I
> > > > want to say is, why does it affect live migration? These counters we
> > > > plan to give to users through ethtool -S, and some changes have
> > > > taken place in the ethtool counters output by users. Does this have
> > > > any practical impact? Or do we directly use some other output in a
> > > > way, we can clearly tell the user that these counters may change
> > > > during the migration process. For example, the driver is migrated to
> > > > some new devices. These devices support some new counters. I think
> > > > users should be able to see these new counters. These new counters may be
> > the purpose of the migration.
> > >
> > > Counters which are well defined non-vendor specific should be able to
> > migrate to destination on best effort basis.
> > > For well defined counters if device A at src support N counters, on migrated
> > destination, it should be N.
> > > This should be able to achieve with feature provisioning infra via group owner
> > command.
> >
> > Yes, for standard counters.
> >
> > >
> > > >
> > > > We don't need to support live migration at this point.
> > > When done on best effort level, infra exists, vendor has ability to
> > incrementally implement it.
> >
> >
> > For the standard counters, the manufacturer will be very willing to use it. I just
> > want to introduce the capabilities of the manufacturer's customized.
> >
> Lets try to generalize first and if we fail consider the vendor specific counters.


OK

Thanks.