Messages in this thread | | | Date | Tue, 28 Nov 2023 06:53:21 -0800 | From | Jakub Kicinski <> | Subject | Re: [PATCH V3 2/5] misc: mlx5ctl: Add mlx5ctl misc driver |
| |
On Mon, 27 Nov 2023 21:46:28 -0700 David Ahern wrote: > > You keep saying "debug information" which is really underselling this > > driver. Are you not going to support mstreg? > > > > The common development flow as far as netdev is concerned is: > > - some customer is interested in a new feature of a chip > > - vendor hacks the support out of tree, using oot module and/or > > user space tooling > > - customer does a PoC with that hacked up, non-upstream solution > > - if it works, vendor has to find out a proper upstream API, > > hopefully agreed on with other vendors > > - if it doesn't match customer needs the whole thing lands in the bin > > > > If the vendor specific PoC can be achieved with fully upstream software > > we lose leverage to force vendors to agree on common APIs. > > Please elaborate on what "common" API there is to create here?
Damn, am I so bad at explaining basic things or y'all are spending 5 seconds reading this and are not really paying attention? :|
> Do you agree that each ASIC in the device is unique and hence will > have made different trade offs - both features and nerd knobs to tune > and affect the performance and runtime capabilities? If you do not > agree, then we need to have a different discussion ... > If you do, please elaborate on the outline of some common API that > could possibly be done here.
We have devlink params. If that doesn't scale we can look for other solutions but let's see them not scale _in practice_ first.
> You said no to the devlink parameters as a way to tune an ASIC.
What? When?
> This is a common, established tool, using a common, established message > channel but in an open, free form way of letting a customer see what > tunables there are for a specific H/W version and firmware version > and then set them. That is about as common as can be for different > vendors creating different ASICs with different goals and design > objectives. Yet, you somehow expect all of them to have nerd knob X > and tunable Y. That is not realistic.
I don't know what you're talking about.
> > This should all be self-evident for people familiar with netdev, but > > I thought I'd spell it out. > > > > I understand that the device has other uses, but every modern NIC has > > other uses. I don't see how netdev can agree to this driver as long as > > there is potential for configuring random networking things thru it. > > All major netdev vendors have a set of out of tree tools / "expose > > everything misc drivers", "for debug". They will soon follow your > > example if we let this in. > > Out of tree drivers are already ingrained into customers now. Mellanox > (in this case) has tried many different angles at getting access to H/W > unique tunables (i.e., the devlink comment) and now dumping huge amounts > of data. Your response to the devlink parameters attempt is to basically > abuse the firmware upgrade command as a way to push a binary blob that > can contain said settings (and I still have not fully wrapped my head > around the fact that you suggested that option). > > What specifically are you looking for? There are different vendors and > different h/w options for specific market based reasons. Your hard line > stance against needs like this is what is pushing out of tree drivers > and tools to continue.
Sounds like you'd like a similar open-ended interface for your device.
| |