On Thu, 11 Jan 2018 08:59:58 -0800, Mahesh Bandewar (महेश बंडेवार) wrote: > I guess the logic would be as simple as - if mtu_adj for a slave is > set to 0, then it's > following master otherwise not. By setting different mtu for a slave, you will > set this mtu_adj a positive number which would mean it's not following master. > So it's subjected to clamping when masters' mtu is reducing but should stay > otherwise. Also when slave decides to follow master again, it can set the mtu > to be same as masters' (making mtu_adj == 0) and then it would start following > master again.
How can the mtu_adj value be queried and set from user space? > Whether it's magic or not, it's the current behavior and I know several use > cases depend on this behavior which would be broken otherwise. The > approach I proposed keeps that going for those who depend on that while > adds an ability to set mtu per slave for the use case mentioned in this > patch-set too. I don't think this works currently. When someone (does not have to be you, it can be a management software running in background) sets the MTU to the current value, the magic behavior is lost without any way to restore it (unless I'm missing a way to restore it, see my question above). So any user that depends on the magic behavior is broken anyway even now. Jiri
