On Friday 23 September 2011 15:30:58 David Lamparter wrote:

On Fri, Sep 23, 2011 at 10:36:04AM +0300, Vitalii Demianets wrote:

quoted

I suppose these questions are not related to kernel development so I
suggest to continue discussion on above topics at the project discussion
board: http://sourceforge.net/p/mstpd/discussion/

That's a forum - I'm afraid that's not quite a good communication
channel for software development feedback. A "normal" software developer
probably has 10, 20, 30... packages he follows around; if each of them
was using a separate discussion forum, the developer would have to check
30 forums regularly, in hir browser.

A mailing list delivers all of that discussion to the developer's
mailbox where it's very easy to sort, follow & respond. Considering the
probably rather low traffic, an existing list might even do it.

Ok, as long as there is no objection from other list participants, let's 
continue in netdev list.

quoted

quoted

I assume it works with current Linux kernel bridge code on a RSTP
level? The code looks considerably more maintainable than rstpd :) - I
will try running it later!

Sorry, at the moment function MSTP_OUT_set_state() does nothing except
logging. But it is valueable thought: although MSTI states do not have
meaning to the kernel bridge code, CIST states can be used to control
bridge slave states, so mstpd can replace rstpd as more generic (and
conforming to more recent standard).

Well, with the current kernel code you can basically support MSTP setups
where all VLANs are mapped to one MSTI, since there's just one port
state for all VLANs. As far as I can tell, that doesn't need to be
the CIST/instance 0, as long as it's the same for all VLANs.

Theoretically, yes. But if the user have bothered to change default config and 
assign all the VLANs to some MSTI, he obviously wants to do something 
MST-related. Maybe she is just in the middle of the configuration process and 
in some time he'll add some  VLANs to another MSTI?
I'd prefer to keep it simple, and translating CIST states to the kernel bridge 
(and all MSTI states to another driver) seems simple enough to me. And this 
approach will also work in the cases when mstpd chooses (R)STP mode of 
operation instead of MSTP, e.g. auto-sensing STP-only neighbors.

quoted

Anyways, the code is basically untested. It compiles and runs in my
setup, that's all for now. But I somehow have gut feeling that the code
is mature enough to be put for the community consideration.

Well, "the community" is usually happy when you continually maintain and
improve your code - one-shot code publications ("fire & forget") happen
all too often and are forgotten quickly...

Understandable enough :)
So for now I'll focus on the (R)STP case and add code which will translate 
CIST states to the kernel bridge. Then the code can be really evaluated (at 
least for the (R)STP cases), not only reviewed.

-- 
Vitalii Demianets