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
| ||
|
Date: Sun, 4 Mar 2018 13:54:49 -0800 From: "Samudrala, Sridhar" <sridhar.samudrala@...el.com> To: Jiri Pirko <jiri@...nulli.us>, Alexander Duyck <alexander.duyck@...il.com> Cc: "Michael S. Tsirkin" <mst@...hat.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 On 3/4/2018 10:50 AM, Jiri Pirko 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: >>> 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? >> Nope that is pretty much it. It doesn't seem like a big deal for >> virtio, but for netvsc it is significant since they don't have any >> "backup" bit feature differentiation, so they would likely be stuck >> with 2 netdevs even in their basic setup. > Okay. If that is a strict "no-go" for netvsc, this should be > just a flag passed down to the in-driver bond code. This results in a 3 driver model (virtio/netvsc, vf & bypass) with 2 netdevs created when bypass is based on netvsc and 3 netdevs created when the bypass is based on virtio_net. Unless we agree on a common netdev model between netvsc and virtio_net, i am not sure if it is useful to commonize the code into a separate driver. -Sridhar
Powered by blists - more mailing lists