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?

Reply via email to