[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150225215651.GF17992@lunn.ch>
Date: Wed, 25 Feb 2015 22:56:51 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Andy Gospodarek <gospo@...ulusnetworks.com>
Cc: Rafa?? Mi??ecki <zajec5@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Network Development <netdev@...r.kernel.org>,
Jonas Gorski <jogo@...nwrt.org>,
Hauke Mehrtens <hauke@...ke-m.de>,
Felix Fietkau <nbd@...nwrt.org>, Jiri Pirko <jiri@...nulli.us>
Subject: Re: [PATCH] net: phy: b53: switchdev driver for Broadcom BCM53xx
switches
On Wed, Feb 25, 2015 at 10:46:07AM -0500, 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.
Using the broadcom tags, it does seem possible to direct packets out
specific ports. So this chip family could use the DSA infrastructure.
It should also be possible to perform bridging in hardware. We should
push DSA for all chips which fit this model.
However, i suspect there are simpler chips which do not support
tagging. When somebody tries to submit a driver for such a device, we
then need to consider what to do for these devices.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists