From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: [PATCH] net: phy: b53: switchdev driver for Broadcom BCM53xx switches Date: Thu, 26 Feb 2015 15:44:33 +0100 Message-ID: <20150226144433.GF1973@nanopsycho.lan> References: <20150225001534.GB15633@lunn.ch> <54ED19AB.7020003@gmail.com> <20150225140356.GB17992@lunn.ch> <20150225154607.GD1332@gospo.home.greyhouse.net> <20150226042158.GF1332@gospo.home.greyhouse.net> <20150226064755.GA2074@nanopsycho.orion> <20150226141319.GA7971@gospo.home.greyhouse.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andy Gospodarek , Andrew Lunn , Rafa?? Mi??ecki , Florian Fainelli , "David S. Miller" , Network Development , Jonas Gorski , Hauke Mehrtens , Felix Fietkau To: Scott Feldman Return-path: Received: from mail-wg0-f46.google.com ([74.125.82.46]:34484 "EHLO mail-wg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753190AbbBZOoj (ORCPT ); Thu, 26 Feb 2015 09:44:39 -0500 Received: by wghn12 with SMTP id n12so11480964wgh.1 for ; Thu, 26 Feb 2015 06:44:38 -0800 (PST) Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Thu, Feb 26, 2015 at 03:19:27PM CET, sfeldma@gmail.com wrote: >On Thu, Feb 26, 2015 at 6:13 AM, Andy Gospodarek > wrote: >> On Thu, Feb 26, 2015 at 07:47:55AM +0100, Jiri Pirko wrote: >>> Thu, Feb 26, 2015 at 05:21:58AM CET, gospo@cumulusnetworks.com wrote: >>> >On Wed, Feb 25, 2015 at 04:53:24PM -0800, Scott Feldman wrote: >>> >> On Wed, Feb 25, 2015 at 7:46 AM, Andy Gospodarek >>> >> wrote: >>> >> > On Wed, Feb 25, 2015 at 03:03:56PM +0100, Andrew Lunn wrote: >>> >> > [...] >>> >> >> >>> >> >> What we don't want is X chip families and Y different ways to >>> >> >> configure the features. Ideal we want X chip families, and one way to >>> >> >> configure them all. >>> >> > >>> >> > This statement is really my primary concern. There is lots of interest >>> >> > around hardware offload at this point and it seems like there is a risk >>> >> > that a lack of consistency can create problems. >>> >> > >>> >> > I think these patches are great as they allow for the programming of the >>> >> > offload hardware (and it has been pointed out that this drastically >>> >> > increases performance), but one concern I have with this patch (related >>> >> > to this) is that I'm not sure there is a major need to create netdevs >>> >> > automatically if there is not the ability to rx/tx actual frames on >>> >> > these interfaces. >>> >> >>> >> Even when not used for rx/tx to CPU, it seems the netdevs are still >>> >> useful as an anchor to build higher-level constructs such as bridge or >>> >> bond, and to hang stuff like netdev stats or ethtool-ish things. >>> >> >>> > >>> >I agree that they are useful, but now we are really dealing with a >>> >netdev that is slightly lower functionality than we expect from a netdev >>> >right now. >>> >>> Is that a real care for some device now? >> I guess that depends on how users expect to use it. :) >> >>> I agree with Scott that we need to model is consistently. If there is >>> such port netdev witch cannot tx/rx, we can expose the fact using some >>> flag... >> Using a flag to expose/mark this was exactly my thought. > >Missing .ndo_start_xmit is the clue....do we need more? You do not want to add null check for ndo_start_xmit to xmit path :) This should be some stub in case of no-tx.