Re: [patch net-next v3 08/17] bridge: call netdev_sw_port_stp_update when bridge port STP status changes

Jiri Pirko
2014-11-28T13:27:12Z

Fri, Nov 28, 2014 at 02:17:37PM CET, jhs@mojatatu.com wrote:
>On 11/28/14 05:51, Scott Feldman wrote:
>>On Fri, Nov 28, 2014 at 2:05 AM, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
>>>On 11/25/14, 5:35 PM, Scott Feldman wrote:
>>>>
>>>> The
>>>>bridge driver or external STP process (msptd) is still controlling STP
>>>>state for the port and processing the BPDUs. When the state changes
>>>>on the port, the bridge driver is letting HW know, that's it.
>>>
>>>
>>>I understand that. In which case, we should not call it stp state.
>>>It is just port state.
>>
>>Sure, call it port state but it takes on BR_STATE_xxx values which
>>just so happen to correspond exactly to STP states.
>>
>>>And since it is yet another port attribute like port
>>>priority,
>>>we should be able to use the same api to offload it to hw just like the
>>>other port attributes.
>>
>>Well it does...see ndo_bridge_setlink in bridge driver, br_setport
>>where IFLA_BRPORT_STATE is handled...it calls br_set_port_state(),
>>which calls into the swdev port driver. That's for the case where
>>user or external processing is setting STP state. For the case where
>>the bridge itself is managing the STP state, the bridge will make the
>>same br_set_port_state() call to adjust the port state.
>>
>
>What Roopa is requesting for if i am not mistaken is the same issue i
>raised earlier as well. We need an opaque way to set and get these
>attributes. We cant afford an ndo ops per bridge or the next thing.
>Its a port level issue - what it is depends on what the underlying
>hardware does.

I agree. This will be addressed (it's in the etherpad todo).

>
>cheers,
>jamal
>