From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f181.google.com ([209.85.128.181]:37686 "EHLO mail-wr0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753055AbeCEWaP (ORCPT ); Mon, 5 Mar 2018 17:30:15 -0500 Received: by mail-wr0-f181.google.com with SMTP id z12so18967706wrg.4 for ; Mon, 05 Mar 2018 14:30:15 -0800 (PST) Date: Mon, 5 Mar 2018 23:30:13 +0100 From: Jiri Pirko To: Stephen Hemminger Cc: Alexander Duyck , "Michael S. Tsirkin" , Sridhar Samudrala , David Miller , Netdev , virtio-dev@lists.oasis-open.org, "Brandeburg, Jesse" , "Duyck, Alexander H" , Jakub Kicinski Subject: Re: [PATCH v4 2/2] virtio_net: Extend virtio to use VF datapath when available Message-ID: <20180305223013.GA2144@nanopsycho> References: <20180303113120.GA3205@nanopsycho.orion> <20180303212542.GA10132@nanopsycho.orion> <20180304071329.GA2112@nanopsycho.orion> <20180304185034.GE2112@nanopsycho.orion> <20180305092118.GG2112@nanopsycho.orion> <20180305081132.72b5159f@xeon-e3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180305081132.72b5159f@xeon-e3> Sender: netdev-owner@vger.kernel.org List-ID: Mon, Mar 05, 2018 at 05:11:32PM CET, stephen@networkplumber.org wrote: >On Mon, 5 Mar 2018 10:21:18 +0100 >Jiri Pirko wrote: > >> Sun, Mar 04, 2018 at 10:58:34PM CET, alexander.duyck@gmail.com wrote: >> >On Sun, Mar 4, 2018 at 10:50 AM, Jiri Pirko wrote: >> >> Sun, Mar 04, 2018 at 07:24:12PM CET, alexander.duyck@gmail.com wrote: >> >>>On Sat, Mar 3, 2018 at 11:13 PM, Jiri Pirko 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? > >Eventually, yes both could share common code routines. In reality, >the failover stuff is only a very small part of either driver so >it is not worth stretching to try and cover too much. If you look, >the failover code is just using routines that already exist for >use by bonding, teaming, etc. Yeah, we consern was also about the code that processes the netdev notifications and does auto-enslave and all related stuff. > >There will always be two drivers, the ring buffers and buffering >are very different between vmbus and virtio. It would help to address >some of the awkward stuff like queue selection and offload handling >in a common way. Agreed. > >Don't worry too much about backports. The backport can use the >old code if necessary.