Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration

[Jiri Pirko]

Fri, Dec 19, 2014 at 10:22:24AM CET, marichika4@xxxxxxxxx wrote:
>On 19 December 2014 at 14:31, B Viswanath <marichika4@xxxxxxxxx> wrote:
>> On 19 December 2014 at 13:57, Jiri Pirko <jiri@xxxxxxxxxxx> wrote:
>>> Fri, Dec 19, 2014 at 06:14:57AM CET, marichika4@xxxxxxxxx wrote:
>>>>On 19 December 2014 at 05:18, Roopa Prabhu <roopa@xxxxxxxxxxxxxxxxxxx> wrote:
>>>>> On 12/18/14, 3:26 PM, Samudrala, Sridhar wrote:
>> <snipped for ease of reading>
>>>>>>
>>>>>>
>>>>>> We also need an interface to set per-switch attributes. Can this work?
>>>>>>     bridge link set dev sw0 sw_attr bcast_flooding 1 master
>>>>>> where sw0 is a bridge representing the hardware switch.
>>>>>
>>>>>
>>>>> Not today. We discussed this @ LPC, and one way to do this would be to have
>>>>> a device
>>>>> representing the switch asic. This is in the works.
>>>>
>>>>
>>>>Can I assume that on  platforms which house more than one asic (say
>>>>two 24 port asics, interconnected via a 10G link or equivalent, to get
>>>>a 48 port 'switch') , the 'rocker' driver (or similar) should expose
>>>>them as a single set of ports, and not as two 'switch ports' ?
>>>
>>> Well that really depends on particular implementation and drivers. If you
>>> have 2 pci-e devices, I think you should expose them as 2 entities. For
>>> sure, you can have the driver to do the masking for you. I don't believe
>>> that is correct though.
>>>
>>
>> In a platform that houses two asic chips, IMO, the user is still
>> expected to manage the router as a single entity. The configuration
>> being applied on both asic devices need to be matching if not
>> identical, and may not be conflicting. The FDB is to be synchronized
>> so that (offloaded) switching can happen across the asics. Some of
>> this stuff is asic specific anyway. Another example is that of the
>> learning. The (hardware) learning can't be enabled on one asic, while
>> being disabled on another one. The general use cases I have seen are
>> all involving managing the 'router' as a single entity.  That the
>> 'router' is implemented with two asics instead of a single asic (with
>> more ports) is to be treated as an implementation detail.  This is the
>> usual router management method that exists today.
>>
>> I hope I make sense.
>>
>> So I am trying to figure out what this single entity that will be used
>> from a user perspective. It can be a bridge, but our bridges are more
>> 802.1q bridges. We can use the 'self' mode, but then it means that it
>> should reflect the entire port count, and not just an asic.
>>
>> So I was trying to deduce that in our switchdevice model, the best bet
>> would be to leave the unification to the driver (i.e., to project the
>> multiple physical asics as a single virtual switch device). This
>> allows any 'switch' level configurations to the bridge in 'self' mode.
>>
>> And  then we would need to consider stacking. Stacking differs from
>> this multi-asic scenario since  there would be multiple CPU involved.
>>
>> Thanks
>> Vissu
>>
>
>Another example i can provide is that of mirroring. Imagine user
>wanted to mirror all traffic from port 1 of asic 1 to port 2 of asic
>2. This can be offloaded to hardware. However, user would be able to
>enter such a command only if he/she can look at a single management
>entity.

I understand your use case. I think this could be handled by higher
entity. In this sase tome userspace agent which would be aware (by
configuration) of all asics and how they are interconnected. Just a
thought. Seem much nice than to do custom masking in drivers.

>
>Thanks
>Vissu
>
>>>>
>>>>>
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/