Fri, Sep 02, 2016 at 07:08:54PM CEST, mahe...@google.com wrote: >On Fri, Sep 2, 2016 at 9:37 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: >> On Fri, 2016-09-02 at 18:25 +0200, Jiri Pirko wrote: >> >>> Understand the reason. All I say is we tried hard (I surely did) in >>> the past to remove bonding specific quirks and now we are adding one. >>> And the simple reason is that the code is such a mess. >>> >I would not qualify this as bonding specific change! The check of you can >really use the interface is simple enough, and can be used by other virtual >drivers (e.g. macvlan, ipvlan, vrf etc.). Waiting until >rx_handler_register() can be >called in your code and then try to do rollback is bad. Also doing >register() early >has it's own consequences. On contrary, I would argue that this is much >cleaner.
Fair enough. Would be great to do this in all other rx_handler users so we are consistent. Thanks! > >Agreed that bonding-driver has become a monster but that doesn't mean we >should not fix issues. This argument would be valid when we are >dealing with last >couple installations / use cases of bonding and everyone else has moved to >alternatives. Unfortunately we are not there yet :( > >>> Just use team instead and you'll be fine. You can "google" it :) >> >> Sure, please join _our_ team and make all the needed changes in user >> land. >> >:) Cannot put it more eloquently than Eric did but we would (in >theory) love to move >to team-driver, but logistics don't support this (yet!). > >> The kernel part of it is epsilon compared to all the control part (ie >> talk to the various Google switches.), and monitoring. >> >> I am fine to leave the bug in upstream bonding driver, if you really >> want to force people out of bonding land ! >> >> Here an automated test simply used macvlan and did not remove the >> macvlan before enslaving the netdev again in a bonding, we already fixed >> the test, because it is faster than deploying new kernels anyway. >> >> >>
