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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 27 Mar 2014 17:55:19 -0400
From:	Jamal Hadi Salim <>
To:	Florian Fainelli <>,
	Sergey Ryazanov <>
CC:	Jiri Pirko <>,
	Roopa Prabhu <>,
	Neil Horman <>,
	Thomas Graf <>, netdev <>,
	David Miller <>,
	Andy Gospodarek <>,
	dborkman <>, ogerlitz <>,
	jesse <>, pshelar <>,
	azhou <>, Ben Hutchings <>,
	Stephen Hemminger <>,, vyasevic <>,
	Cong Wang <>,
	John Fastabend <>,
	Eric Dumazet <>,
	Scott Feldman <>,
	Lennert Buytenhek <>,
	Shrijeet Mukherjee <>,
	Felix Fietkau <>
Subject: Re: [patch net-next RFC 0/4] introduce infrastructure for support
 of switch chip datapath

On 03/27/14 17:20, Florian Fainelli wrote:
> 2014-03-27 13:32 GMT-07:00 Sergey Ryazanov <>:

>> I would like go further and suggest to consider a netdev that is
>> connected to the CPU switch port, as master. In case when we need to
>> perform some action on whole switch (e.g. dump FIB).
> This is what the 'sw1' net_device in Jiri's proposal would do.
>> And even name
>> switch ports, using master netdev name as prefix (e.g. eth1p0, eth1p1,
>> ..., eth1pN for ports of switch that is connected via eth1).
> I think the port naming using the switch abstract interface (sw1 here)
> is better because ports do belong to the switch.

Can we start calling whatever this netdev is something like "control"?
Or maybe it is "cpu" netdev? Since i am
comprehending better the need for such a special netdev, i would say:
if i do a "route add" and it needs to go to the specific switch,
the FIB entry will find its way to the "control" netdev which will
invoke device specific interfaces for the ASIC.
I would go as far as almost claiming - let this interface use netlink
definitions (we know how fib netlink interfaces look like already); 
caveat is: there may room  to tone it down.
Repeat and rinse for everything else we know how to do already

Of course there's a lot of evolution on the core code but thats
a different discussion.


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