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

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

On 03/26/14 01:37, Roopa Prabhu wrote:
> On 3/25/14, 1:11 PM, Florian Fainelli wrote:
>> 2014-03-25 12:35 GMT-07:00 Neil Horman <nhorman@tuxdriver.com>:

> Sorry about getting on this thread late and possibly in the middle.
> Agree on the idea of keeping the ports linked to the master switch dev
> (or the 'conduit' to the switch chip) via private list instead of the
> master-slave relationship proposed earlier.
> By private i mean the netdev->priv linkage to the master switch dev and
> not really keeping the ports from being exposed to the user.
>
> We think its better to keep the switch ports exposed as any other netdev
> on linux.
>   This approach will make the switch ports look exactly like a nic port
> and all tools will continue to work seamlessly. The switch port
> operations could internally be forwarded to the switch netdev (sw1 in
> the above case).
>
> example:
> $ip link set dev sw1p0 up
> $ethtool -S sw1p0
>

I like the approach. I know the above is a simple version, but i am
assuming you also mean i can do things like
ip route add ...
bridge fdb add ... (and if you like your brctl go ahead)
bonding ...



>
> whether sw1 is needed as a separate netdev existing on the system is
> debatable.

I dont see need to expose it. For 1, it will be confusing to have this
netdev whose only task is to control the chip.

> Most cases the switch port driver (API) can talk to the switch chip
> driver without a switch netdev in between.
> But there are cases where a switch netdev might become necessary for
> switch chip specific operations (which probably has been discussed on
> this thread). An example could be a global acl rule that applies to all
> switch ports. One can argue that this can be applied on individual
> switch ports and the switch driver can take care of consolidating or
> optimally programming the acl rule in the switch chip.
>

There are a lot of things which dont tie to a specific port.
I think these should be transparent to the chip. If i add a route
and the decision is for that route to go to the chip, then it
shows up at the driver and it goes to the ASIC.
If i am dumping a fib table and some parts of it sit in the chip,
then whatever interfaces would end up querying the chip.

cheers,
jamal


> Thanks,
> Roopa
>
>
>
>
>