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 07:47:55 +0100 Message-ID: <20150226064755.GA2074@nanopsycho.orion> References: <20150224223039.GC1332@gospo.home.greyhouse.net> <54ED017E.6000902@gmail.com> <20150225001534.GB15633@lunn.ch> <54ED19AB.7020003@gmail.com> <20150225140356.GB17992@lunn.ch> <20150225154607.GD1332@gospo.home.greyhouse.net> <20150226042158.GF1332@gospo.home.greyhouse.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Scott Feldman , Andrew Lunn , Rafa?? Mi??ecki , Florian Fainelli , "David S. Miller" , Network Development , Jonas Gorski , Hauke Mehrtens , Felix Fietkau To: Andy Gospodarek Return-path: Received: from mail-wg0-f52.google.com ([74.125.82.52]:42935 "EHLO mail-wg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753273AbbBZGr7 (ORCPT ); Thu, 26 Feb 2015 01:47:59 -0500 Received: by wghl2 with SMTP id l2so8091596wgh.9 for ; Wed, 25 Feb 2015 22:47:58 -0800 (PST) Content-Disposition: inline In-Reply-To: <20150226042158.GF1332@gospo.home.greyhouse.net> Sender: netdev-owner@vger.kernel.org List-ID: 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 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... >