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  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]
Date:	Fri, 22 Aug 2014 08:42:04 -0400
From:	Jamal Hadi Salim <>
To:	Florian Fainelli <>,
	Jiri Pirko <>
CC:	netdev <>,
	David Miller <>,
	Neil Horman <>,
	Andy Gospodarek <>, tgraf <>,
	dborkman <>, ogerlitz <>,
	jesse <>, pshelar <>,
	azhou <>, Ben Hutchings <>,
	Stephen Hemminger <>,
	Jeff Kirsher <>,
	vyasevic <>,
	Cong Wang <>,
	John Fastabend <>,
	Eric Dumazet <>,
	Scott Feldman <>,
	Roopa Prabhu <>,
	John Linville <>,
	dev <>,
	"" <>,
	"Eric W. Biederman" <>,
	Nicolas Dichtel <>,
	Sergey Ryazanov <>,
	Lennert Buytenhek <>,
	Aviad Raveh <>,
	Felix Fietkau <>,
	Alexei Starovoitov <>,
	Neil Jerram <>,
Subject: Re: [patch net-next RFC 03/12] net: introduce generic switch devices

On 08/21/14 13:05, Florian Fainelli wrote:
> 2014-08-21 9:18 GMT-07:00 Jiri Pirko <>:
>> The goal of this is to provide a possibility to suport various switch
>> chips. Drivers should implement relevant ndos to do so. Now there is a
>> couple of ndos defines:
>> - for getting physical switch id is in place.
>> - for work with flows.
>> Note that user can use random port netdevice to access the switch.
> I read through this patch set, and I still think that DSA is the
> generic switch infrastructure we already have because it does provide
> the following:
> - taking a generic platform data structure (C struct or Device Tree),
> validate, parse it and map it to internal kernel structures
> - instantiate per-port network devices based on the configuration data provided
> - delegate netdev_ops to the switch driver and/or the CPU NIC when relevant
> - provide support for hooking RX and TX traffic coming from the CPU NIC
> I would rather we build on the existing DSA infrastructure and add the
> flow-related netdev_ops rather than having the two remain in
> disconnect while flow-oriented switches driver get progressively
> added. I guess I should take a closer look at the rocker driver to see
> how hard would that be for you.
> What do you think?

I thought we had concluded that DSA was a good path forward?  Or maybe 
at this stage we need to have several alternative approaches
and we eventually converge?


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists