Mon, Feb 19, 2024 at 02:33:54PM CET, [email protected] wrote: >On 2/19/24 13:37, Jiri Pirko wrote: >> Mon, Feb 19, 2024 at 11:05:57AM CET, [email protected] wrote: >> > From: Lukasz Czapnik <[email protected]> >> > >> > It was observed that Tx performance was inconsistent across all queues >> > and/or VSIs and that it was directly connected to existing 9-layer >> > topology of the Tx scheduler. >> > >> > Introduce new private devlink param - tx_scheduling_layers. This parameter >> > gives user flexibility to choose the 5-layer transmit scheduler topology >> > which helps to smooth out the transmit performance. >> > >> > Allowed parameter values are 5 and 9. >> > >> > Example usage: >> > >> > Show: >> > devlink dev param show pci/0000:4b:00.0 name tx_scheduling_layers >> > pci/0000:4b:00.0: >> > name tx_scheduling_layers type driver-specific >> > values: >> > cmode permanent value 9 >> > >> > Set: >> > devlink dev param set pci/0000:4b:00.0 name tx_scheduling_layers value 5 >> > cmode permanent >> >> This is kind of proprietary param similar to number of which were shot > >not sure if this is the same kind of param, but for sure proprietary one > >> down for mlx5 in past. Jakub? > >I'm not that familiar with the history/ies around mlx5, but this case is >somewhat different, at least for me: >we have a performance fix for the tree inside the FW/HW, while you >(IIRC) were about to introduce some nice and general abstraction layer, >which could be used by other HW vendors too, but instead it was mlx-only
Nope. Same thing. Vendor/device specific FW/HW knob. Nothing to abstract. > >> >> Also, given this is apparently nvconfig configuration, there could be >> probably more suitable to use some provisioning tool. > >TBH, we will want to add some other NVM related params, but that does >not justify yet another tool to configure PF. (And then there would be >a big debate if FW update should be moved there too for consistency). > >> This is related to the mlx5 misc driver. >> >> Until be figure out the plan, this has my nack: >> >> NAcked-by: Jiri Pirko <[email protected]> > >IMO this is an easy case, but would like to hear from netdev maintainers > >
