Re: [patch net-next RFC 0/4] introduce infrastructure for support of switch chip datapath

[Jamal Hadi Salim <jhs@mojatatu.com>]

On 03/25/14 16:31, Neil Horman wrote:
> On Tue, Mar 25, 2014 at 01:11:55PM -0700, Florian Fainelli wrote:
>> 2014-03-25 12:35 GMT-07:00 Neil Horman <nhorman@tuxdriver.com>:
>>> On Tue, Mar 25, 2014 at 06:00:09PM +0000, Thomas Graf wrote:

>> 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