From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH v4 2/2] virtio_net: Extend virtio to use VF datapath when available Date: Wed, 7 Mar 2018 04:38:54 +0200 Message-ID: <20180307043534-mutt-send-email-mst@kernel.org> References: <20180304185034.GE2112@nanopsycho.orion> <20180305092118.GG2112@nanopsycho.orion> <20180305081132.72b5159f@xeon-e3> <20180305223013.GA2144@nanopsycho> <20180305191508.298bd595@xeon-e3> <20180306225927.GB2144@nanopsycho> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jiri Pirko , Stephen Hemminger , Sridhar Samudrala , David Miller , Netdev , virtio-dev@lists.oasis-open.org, "Brandeburg, Jesse" , "Duyck, Alexander H" , Jakub Kicinski To: Alexander Duyck Return-path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Content-Disposition: inline In-Reply-To: List-Id: netdev.vger.kernel.org On Tue, Mar 06, 2018 at 03:27:46PM -0800, Alexander Duyck wrote: > > I definitelly vote for a separate common shared code for both netvsc and > > virtio_net - even if you use 2 and 3 netdev model, you could share the > > common code. Strict checks and limitation should be in place. > > Noted. But as I also mentioned there isn't that much "common" code > between the two models. I think if anything we could probably look at > peeling out a few bits such as "get__bymac" which really would > become dev_get_by_mac_and_ops in order to find the device for the > notifiers. I probably wouldn't even put that in our driver and would > instead put it in the core code since it almost makes more sense > there. Beyond that sharing becomes much more challenging due to the > differences in the Rx and Tx paths that build out of the difference > between the 2 driver and 3 driver models. At this point it might be worth it to articulate the advantages of the 3 netdev model. If they are compelling, why wouldn't netvsc users want them? Alex, I think you were one of the strongest proponents of this model, you should be well placed to provide a summary. -- MST