netdev - Re: [PATCH v4 2/2] virtio_net: Extend virtio to use VF datapath when available

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]

Message-ID: <20180304071329.GA2112@nanopsycho.orion>
Date:   Sun, 4 Mar 2018 08:13:29 +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 01:26:53AM CET, alexander.duyck@...il.com wrote:
>On Sat, Mar 3, 2018 at 1:25 PM, Jiri Pirko <jiri@...nulli.us> wrote:
>> Sat, Mar 03, 2018 at 07:04:57PM CET, alexander.duyck@...il.com wrote:
>>>On Sat, Mar 3, 2018 at 3:31 AM, Jiri Pirko <jiri@...nulli.us> wrote:
>>>> Fri, Mar 02, 2018 at 08:42:47PM CET, mst@...hat.com wrote:
>>>>>On Fri, Mar 02, 2018 at 05:20:17PM +0100, Jiri Pirko wrote:
>>>>>> >Yeah, this code essentially calls out the "shareable" code with a
>>>>>> >comment at the start and end of the section what defines the
>>>>>> >virtio_bypass functionality. It would just be a matter of mostly
>>>>>> >cutting and pasting to put it into a separate driver module.
>>>>>>
>>>>>> Please put it there and unite the use of it with netvsc.
>>>>>
>>>>>Surely, adding this to other drivers (e.g. might this be handy for xen
>>>>>too?) can be left for a separate patchset. Let's get one device merged
>>>>>first.
>>>>
>>>> Why? Let's do the generic infra alongside with the driver. I see no good
>>>> reason to rush into merging driver and only later, if ever, to convert
>>>> it to generic solution. On contrary. That would lead into multiple
>>>> approaches and different behavious in multiple drivers. That is plain
>>>> wrong.
>>>
>>>If nothing else it doesn't hurt to do this in one driver in a generic
>>>way, and once it has been proven to address all the needs of that one
>>>driver we can then start moving other drivers to it. The current
>>>solution is quite generic, that was my contribution to this patch set
>>>as I didn't like how invasive it was being to virtio and thought it
>>>would be best to keep this as minimally invasive as possible.
>>>
>>>My preference would be to give this a release or two in virtio to
>>>mature before we start pushing it onto other drivers. It shouldn't
>>>take much to cut/paste this into a new driver file once we decide it
>>>is time to start extending it out to other drivers.
>>
>> I'm not talking about cut/paste and in fact that is what I'm worried
>> about. I'm talking about common code in net/core/ or somewhere that
>> would take care of this in-driver bonding. Each driver, like virtio_net,
>> netvsc would just register some ops to it and the core would do all
>> logic. I believe it is essential take this approach from the start.
>
>Sorry, I didn't mean cut/paste into another driver, I meant to make it
>a driver of its own. My thought was to eventually create a shared/core
>driver module that is then used by the other drivers.
>
>My concern right now is that Stephen has indicated he doesn't want
>this approach taken with netvsc, and most of the community doesn't

IIUC, he only does not like the extra netdev. Is there anything else?


>want the netvsc approach applied to virtio. Until that impasse can be
>resolved there isn't much value in trying to split this up so it is
>available to other drivers. In addition I would imagine it would make
>it a pain for others to back-port into distros since it would break
>legacy netvsc driver behavior. Patches are always welcome. Once this
>is in you are free to try fighting to get this made into a generic
>module and applied to both drivers, but we have already spent close to
>3 months on this and it seems like there has been significantly more

Alex, time is never a good argument for poor design and shortcuts.


>time spent arguing over the number of interfaces and/or drivers than
>spent writing/reviewing actual code.
>
>- Alex