On 03/25/14 16:31, Neil Horman wrote:

On Tue, Mar 25, 2014 at 01:11:55PM -0700, Florian Fainelli wrote:

quoted

2014-03-25 12:35 GMT-07:00 Neil Horman [off-list ref]:

quoted

On Tue, Mar 25, 2014 at 06:00:09PM +0000, Thomas Graf wrote:

quoted

Not sure if I got this right, but there might be additional control
knobs required for specific Ethernet switch features that do not map
nicely, if at all with existing interfaces provided by ip/tc,
ethtool... although I guess one would say, well, then go add these
APIs instead of creating "extended" ones?

Ostensibly yes, but I'm not well versed enough in what those interfaces are, to
know for certain.  I definately agree however, that if a given interface outside
the scope of network device control is required (say for example, direct access
to a switch fabrics cam lookup table), then you are correct, we should develop
those api's rather than shoehorn them into a net_device model

Sorry i should have started from last and gone backwards reading emails.
So things like stats that are only available via some chip but not
others come to mind. But we know how to carry those things to user
space via netlink. Give me an IFLA_KIND and i can give you access to
set/get extended features.
I dont see much disagreement to the end goals from any of the goals.
Thou shalt make current tools work.
The challenge perhaps maybe the different implementation approaches.
It seems we are also agreeing that there will be some conduit driver
which will expose ports to the kernel. It will likely own the ASIC
feature set and can be queried for capabilities indirectly.
It can talk DSA, PCI etc.

For when things dont fit: I would expect this "driver" to
also be the conduit to the chip resources and any
translation that needs to happen between the kernel view of the
abstraction to the chip view.

cheers,
jamal