On 11/28/14 05:51, Scott Feldman wrote:

On Fri, Nov 28, 2014 at 2:05 AM, Roopa Prabhu [off-list ref] wrote:

quoted

On 11/25/14, 5:35 PM, Scott Feldman wrote:

quoted

   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.

quoted

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.

cheers,
jamal