> >> DEVLINK_ATTR_PERM_CFG_NPAR_BW_RESERVATION_VALID: 1 to use > >> BW_RESERVATION setting, 0 to ignore. > >> > > ... > >> DEVLINK_ATTR_PERM_CFG_NPAR_BW_LIMIT_VALID: 1 to use BW_LIMIT > >> setting, 0 to ignore. > > > > While it probably ties to different fields in your NVM layout why would the > user > > require specific attributes for these? Why not have values in the actual > > attributes indicating of this status? > > Hi Yuval, > > Does having the separate valid flag present any difficulties? There > are lots of implementation options here (a limit or reservation value > of 0 could mean invalid, or we could define (1 << 31) to be a valid > flag when setting the value, etc.), and I'm not necessarily tied to > doing it this way, but it seemed a straightforward way to represent > the validity of the other field.
You're pushing a LOT of new attributes, every one of which is going to have to be documented for future generations. I think whenever it's possible to drop an unnecessary attribute, that would be the better option.
