From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com ([74.125.82.67]:33245 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932672AbeCEJVV (ORCPT ); Mon, 5 Mar 2018 04:21:21 -0500 Received: by mail-wm0-f67.google.com with SMTP id s206so12216959wme.0 for ; Mon, 05 Mar 2018 01:21:20 -0800 (PST) Date: Mon, 5 Mar 2018 10:21:18 +0100 From: Jiri Pirko To: Alexander Duyck Cc: "Michael S. Tsirkin" , Sridhar Samudrala , Stephen Hemminger , 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: <20180305092118.GG2112@nanopsycho.orion> References: <20180302162017.GG2099@nanopsycho> <20180302214114-mutt-send-email-mst@kernel.org> <20180303113120.GA3205@nanopsycho.orion> <20180303212542.GA10132@nanopsycho.orion> <20180304071329.GA2112@nanopsycho.orion> <20180304185034.GE2112@nanopsycho.orion> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: 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?