On Thu, Jan 11, 2018 at 8:59 AM, Mahesh Bandewar (महेश बंडेवार) <mahe...@google.com> wrote: > On Thu, Jan 11, 2018 at 3:25 AM, Jiri Benc <jb...@redhat.com> wrote: >> On Wed, 10 Jan 2018 18:09:50 -0800, Mahesh Bandewar (महेश बंडेवार) wrote: >>> I still prefer the approach I had mentioned that uses 'mtu_adj'. In >>> that approach you can leave those slaves which have changed their mtu >>> to be lower than masters' but if master's mtu changes to larger value >>> all other slaves will get updated mtu leaving behind the slaves who >>> have opted to change their mtu on their own. Also the same thing is >>> true when mtu get reduced at master. >> >> The problem with this magic behavior is, well, that it's magic. There's >> no way to tell what happens with a given slave when the master's MTU >> gets changed just by looking at the current configuration. There's also >> no way to switch the magic behavior back on once the slave's MTU is >> changed. >> > 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. > > 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. > Actually we can just have boolean val per slave indicating it's changed locally instead of maintaining the mtu diff which is useless at this moment.
>> At minimum, you'd need some kind of indication that the slave's MTU is >> following the master. And a way to toggle this back. >> >> Keefe's patch is much saner, the behavior is completely deterministic. >> >> Jiri
