[an error occurred while processing this directive]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 5 Mar 2018 10:21:18 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Alexander Duyck <alexander.duyck@...il.com>
Cc:     "Michael S. Tsirkin" <mst@...hat.com>,
        Sridhar Samudrala <sridhar.samudrala@...el.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>, virtio-dev@...ts.oasis-open.org,
        "Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
        "Duyck, Alexander H" <alexander.h.duyck@...el.com>,
        Jakub Kicinski <kubakici@...pl>
Subject: Re: [PATCH v4 2/2] virtio_net: Extend virtio to use VF datapath when
 available

Sun, Mar 04, 2018 at 10:58:34PM CET, alexander.duyck@...il.com wrote:
>On Sun, Mar 4, 2018 at 10:50 AM, Jiri Pirko <jiri@...nulli.us> wrote:
>> Sun, Mar 04, 2018 at 07:24:12PM CET, alexander.duyck@...il.com wrote:
>>>On Sat, Mar 3, 2018 at 11:13 PM, Jiri Pirko <jiri@...nulli.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?