Sun, Mar 04, 2018 at 10:58:34PM CET, alexander.du...@gmail.com wrote: >On Sun, Mar 4, 2018 at 10:50 AM, Jiri Pirko <j...@resnulli.us> wrote: >> Sun, Mar 04, 2018 at 07:24:12PM CET, alexander.du...@gmail.com wrote: >>>On Sat, Mar 3, 2018 at 11:13 PM, Jiri Pirko <j...@resnulli.us> wrote:
[...] > >>>Currently we only have agreement from Michael on taking this code, as >>>such we are working with virtio only for now. When the time comes that >> >> If you do duplication of netvsc in-driver bonding in virtio_net, it will >> stay there forever. So what you say is: "We will do it halfway now >> and promise to fix it later". That later will never happen, I'm pretty >> sure. That is why I push for in-driver bonding shared code as a part of >> this patchset. > >You want this new approach and a copy of netvsc moved into either core >or some module of its own. I say pick an architecture. We are looking >at either 2 netdevs or 3. We are not going to support both because >that will ultimately lead to a terrible user experience and make >things quite confusing. > >> + if you would be pushing first driver to do this, I would understand. >> But the first driver is already in. You are pushing second. This is the >> time to do the sharing, unification of behaviour. Next time is too late. > >That is great, if we want to share then lets share. But what you are >essentially telling us is that we need to fork this solution and >maintain two code paths, one for 2 netdevs, and another for 3. At that >point what is the point in merging them together? Of course, I vote for the same behaviour for netvsc and virtio_net. That is my point from the very beginning. Stephen, what do you think? Could we please make virtio_net and netvsc behave the same and to use a single code with well-defined checks and restrictions for this feature?