[Bridge] MSTPd in RSTP mode is sometimes slow...

Rodolfo Giometti giometti at enneenne.com
Mon Oct 15 16:39:40 UTC 2012


On Mon, Oct 15, 2012 at 05:45:28PM +0200, Rodolfo Giometti wrote:
> 
> The mstpd daemon needs ~0.7s to rerun the function! =:-/

I discovered why... I modified these funtions:

static inline void run_timeouts(void)
{
LOG("------> 0");
    bridge_one_second();
    ++(nexttimeout.tv_sec);
LOG("------> 10");
}

int epoll_main_loop(void)
{
    gettimeofday(&nexttimeout, NULL);
    ++(nexttimeout.tv_sec);
#define EV_SIZE 8
    struct epoll_event ev[EV_SIZE];

    while(1)
    {
        int r, i;
        int timeout;

        struct timeval tv;
LOG("------> 0");
        gettimeofday(&tv, NULL);
        timeout = time_diff(&nexttimeout, &tv);
        if(timeout < 0)
        {
            run_timeouts();
            timeout = 0;
        }

LOG("------> 1");
        r = epoll_wait(epoll_fd, ev, EV_SIZE, timeout);
        if(r < 0 && errno != EINTR)
        {
            fprintf(stderr, "epoll_wait: %m\n");
            return -1;
        }
LOG("------> 2");
        for(i = 0; i < r; ++i)
        {
            struct epoll_event_handler *p = ev[i].data.ptr;
            if(p != NULL)
                p->ref_ev = &ev[i];
        }
LOG("------> 3");
        for (i = 0; i < r; ++i)
        {
            struct epoll_event_handler *p = ev[i].data.ptr;
            if(p && p->handler)
                p->handler(ev[i].events, p);
        }
LOG("------> 4");
        for (i = 0; i < r; ++i)
        {
            struct epoll_event_handler *p = ev[i].data.ptr;
            if(p != NULL)
                p->ref_ev = NULL;
        }
LOG("------> 10");
    }

    return 0;
}

and I get:

1038909843.937476: bridge_bpdu_rcv: ifindex 6, len 60
1038909843.941673: MSTP_IN_rx_bpdu: br0:mrvl4 received RST BPDU
1038909843.946618: br_state_machines_run: ------> 0
1038909843.952425: br_state_machines_run: ------> 1
1038909843.957172: br_state_machines_run: ------> 2
1038909843.961917: br_state_machines_run: ------> 3
1038909843.966664: br_state_machines_run: ------> 4
1038909843.971420: br_state_machines_run: ------> 5
1038909843.976163: PISM_to_RECEIVE: br0:mrvl4:0 
1038909843.980921: PISM_to_SUPERIOR_DESIGNATED: br0:mrvl4:0 
1038909843.985399: PISM_to_CURRENT: br0:mrvl4:0 
1038909843.990954: br_state_machines_run: ------> 6
1038909843.995443: br_state_machines_run: ------> 7
1038909844.000183: br_state_machines_run: ------> 8
1038909844.004924: br_state_machines_run: ------> 9
1038909844.009673: br_state_machines_run: ------> 10
1038909844.014428: epoll_main_loop: ------> 4
1038909844.019259: epoll_main_loop: ------> 10
1038909844.023471: epoll_main_loop: ------> 0
1038909844.027772: epoll_main_loop: ------> 1
1038909844.050699: epoll_main_loop: ------> 2
1038909844.053582: epoll_main_loop: ------> 3
1038909844.054920: epoll_main_loop: ------> 4
1038909844.059130: epoll_main_loop: ------> 10
1038909844.063343: epoll_main_loop: ------> 0
1038909844.067644: run_timeouts: ------> 0
1038909844.071868: br_state_machines_run: ------> 0
1038909844.075796: br_state_machines_run: ------> 1
1038909844.080549: br_state_machines_run: ------> 2
1038909844.085295: br_state_machines_run: ------> 3
1038909844.090675: br_state_machines_run: ------> 4
1038909844.094796: br_state_machines_run: ------> 5
1038909844.099543: PISM_to_UPDATE: br0:mrvl4:0 
1038909844.104295: PISM_to_CURRENT: br0:mrvl4:0 
1038909844.108681: br_state_machines_run: ------> 6
1038909844.113167: br_state_machines_run: ------> 7
1038909844.117920: br_state_machines_run: ------> 8
1038909844.122659: br_state_machines_run: ------> 9
1038909844.127408: br_state_machines_run: ------> 10
1038909844.132162: run_timeouts: ------> 10
1038909844.136993: epoll_main_loop: ------> 1
1038909844.141032: epoll_main_loop: ------> 2
1038909844.145236: epoll_main_loop: ------> 3
1038909844.149447: epoll_main_loop: ------> 4
1038909844.153668: epoll_main_loop: ------> 10
1038909844.157870: epoll_main_loop: ------> 0
1038909844.162174: epoll_main_loop: ------> 1
1038909845.040037: epoll_main_loop: ------> 2
1038909845.042945: epoll_main_loop: ------> 3
1038909845.044283: epoll_main_loop: ------> 4
1038909845.048494: epoll_main_loop: ------> 10
1038909845.052714: epoll_main_loop: ------> 0
1038909845.057008: run_timeouts: ------> 0
1038909845.061226: br_state_machines_run: ------> 0
1038909845.065160: br_state_machines_run: ------> 1
1038909845.069910: br_state_machines_run: ------> 2
1038909845.074665: br_state_machines_run: ------> 3
1038909845.079407: br_state_machines_run: ------> 4
1038909845.084165: MSTP_OUT_tx_bpdu: br0:mrvl4 sending RST BPDU

As you can see the daemon changes its internal state only when
run_timeouts() is executed!

I suppose this is not right...

Ciao,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail: giometti at enneenne.com
Linux Device Driver                          giometti at linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti
Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it


More information about the Bridge mailing list