From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f196.google.com ([209.85.128.196]:36372 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752175AbeCCVZp (ORCPT ); Sat, 3 Mar 2018 16:25:45 -0500 Received: by mail-wr0-f196.google.com with SMTP id v111so13466089wrb.3 for ; Sat, 03 Mar 2018 13:25:44 -0800 (PST) Date: Sat, 3 Mar 2018 22:25:42 +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: <20180303212542.GA10132@nanopsycho.orion> References: <1519934923-39372-1-git-send-email-sridhar.samudrala@intel.com> <1519934923-39372-3-git-send-email-sridhar.samudrala@intel.com> <20180302083605.GD2099@nanopsycho> <20180302162017.GG2099@nanopsycho> <20180302214114-mutt-send-email-mst@kernel.org> <20180303113120.GA3205@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: Sat, Mar 03, 2018 at 07:04:57PM CET, alexander.duyck@gmail.com wrote: >On Sat, Mar 3, 2018 at 3:31 AM, Jiri Pirko wrote: >> Fri, Mar 02, 2018 at 08:42:47PM CET, mst@redhat.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.