> > As per my earlier email, the proposal is not trying to support arbitrary > > transforms. If the admin has e.g. a SPEED-DUPLEX value of 100g-f,10m-h > > and they want to change the 10m-h value to 10m-f then they would need to > > enter 100g-f,10m-f, or first do -=10m-h followed by += of 10m-f. If they > > just want to add or remove a specific value then they can use += or -=. > > For instance, if they wanted to add CPU 12 to the list of cpus, they'd do > > set-linkprop -p cpus+=12. > > In all of these cases, I presume that the datalink.conf will have something > (imo gross) like > > en_10gfdx_cap=1,en_10ghdx_cap=..,en_1000fdx_cap=..,en_1000hdx_cap=..,en_100fdx_cap=..,en_100hdx_cap=.., > en_10fdx_cap=..,en_10hdx_cap=..
Which case? Certainly not in the model I'm suggesting, as those properties no longer would exist. > > > Also in today's model, only the modified setting (en_10fdx_cap = 0, > > > in my example) is saved in datalink.conf. As I understand, in your > > > proposal, the whole set of enabled props would have to get stored in > > > datalink.conf (and then, if the NIC is DR'ed or otherwise changes its > > > defaults, the stored set in datalink.conf may be out of sync). > > > > There are pros and cons with both approaches in the case of DR'd hardware. > > Are they overriding the setting because of a switch problem? A card > > problem? Just general confusion? Unclear, so it's hard to say what ideal > > behavior would be. > > Imposing defaults from user-space for untuned values (instead of just > letting the driver do its thing) is not a good idea- reset-linkprop > carefully avoids this by actually removing the property setting itself. I don't know why you think this is being proposed. If someone tunes en-mii, then there will be a recorded value for it that will be set when the link is created. If there is not a setting for en-mii, then no value will be set when the link is created. -- meem
