lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ