From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Duyck Subject: Re: [PATCH v4 2/2] virtio_net: Extend virtio to use VF datapath when available Date: Sat, 3 Mar 2018 16:26:53 -0800 Message-ID: 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> <20180303212542.GA10132@nanopsycho.orion> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: "Michael S. Tsirkin" , Sridhar Samudrala , Stephen Hemminger , David Miller , Netdev , virtio-dev@lists.oasis-open.org, "Brandeburg, Jesse" , "Duyck, Alexander H" , Jakub Kicinski To: Jiri Pirko Return-path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: In-Reply-To: <20180303212542.GA10132@nanopsycho.orion> List-Id: netdev.vger.kernel.org On Sat, Mar 3, 2018 at 1:25 PM, Jiri Pirko wrote: > 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. 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 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 time spent arguing over the number of interfaces and/or drivers than spent writing/reviewing actual code. - Alex From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-3404-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [66.179.20.138]) by lists.oasis-open.org (Postfix) with ESMTP id A80D05818F0F for ; Sat, 3 Mar 2018 16:27:05 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <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> <20180303212542.GA10132@nanopsycho.orion> From: Alexander Duyck Date: Sat, 3 Mar 2018 16:26:53 -0800 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: [virtio-dev] Re: [PATCH v4 2/2] virtio_net: Extend virtio to use VF datapath when available To: Jiri Pirko Cc: "Michael S. Tsirkin" , Sridhar Samudrala , Stephen Hemminger , David Miller , Netdev , virtio-dev@lists.oasis-open.org, "Brandeburg, Jesse" , "Duyck, Alexander H" , Jakub Kicinski List-ID: On Sat, Mar 3, 2018 at 1:25 PM, Jiri Pirko wrote: > 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. 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 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 time spent arguing over the number of interfaces and/or drivers than spent writing/reviewing actual code. - Alex --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org