I thought we already agree'd on the rational in the weekly meetings. This meetings purpose is to nail down the approach we want to take because we keep having discussions about the long term approach, which means we need to nail it down. donald On Thu, May 18, 2017 at 8:04 AM, Vincent Jardin <vincent.jardin@6wind.com> wrote:

David,

It seems I did miss the Doodle. First, please, we need a written rational of Quentin's intention when he did push pthread support.

Le 18 mai 2017 1:38:55 PM David Lamparter <equinox@opensourcerouting.org> a écrit :

...

Hi all,

as polled on Doodle (and with Lou's side-input), the Multithreading design call mentioned in our last weekly meeting will be

tomorrow (Friday) 08:00 PDT (US West Coast -0700) 11:00 EDT (US East Coast -0400) 17:00 CEST (EU Central +0200)

I'll also send out calendar invites.

Cheers,

-David

_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev

_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev

Vincent - You are correct that better meeting minutes would be helpful. I run the meetings and don't have time to write notes as I go, so we get stuff cobbled together at the end. To answer your original question about the why of it: 1) We have several known situations where show commands for bgp take an extraordinary amount of time to run/process( especially with JSON output turned on ). This long time is causing bgp neighbor relationships to be taken down because hello's are not getting out. 2) Quentin/David/Olivier have all been working/thinking about threads and all have slightly different approaches. This last round of changes changed an api that was found to be surprising after it was committed. At that point we decided that it would be a good idea to spend a couple hours( or more ) hammering out the general approach we want to take. Hence this meeting donald On Thu, May 18, 2017 at 9:37 AM, Vincent Jardin <vincent.jardin@6wind.com> wrote:

Maybe some minutes for people who could not attend would help ? This topic related to thread needs to on board many view.

Le 18 mai 2017 2:18:01 PM Donald Sharp <sharpd@cumulusnetworks.com> a écrit :

...

I thought we already agree'd on the rational in the weekly meetings. This meetings purpose is to nail down the approach we want to take because we keep having discussions about the long term approach, which means we need to nail it down.

donald

On Thu, May 18, 2017 at 8:04 AM, Vincent Jardin <vincent.jardin@6wind.com> wrote:

...

David,

It seems I did miss the Doodle. First, please, we need a written rational of Quentin's intention when he did push pthread support.

Le 18 mai 2017 1:38:55 PM David Lamparter <equinox@opensourcerouting.org> a écrit :

...

Hi all,

as polled on Doodle (and with Lou's side-input), the Multithreading design call mentioned in our last weekly meeting will be

tomorrow (Friday) 08:00 PDT (US West Coast -0700) 11:00 EDT (US East Coast -0400) 17:00 CEST (EU Central +0200)

I'll also send out calendar invites.

Cheers,

-David

_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev

_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev

Thanks the call and emails did help for people who could not attend. I think pthread() should show up progressively to avoid breaking FRR while we benefit of the other hardening and new protocol features so we'll avoid next release with pthread() to be stabilize only after years... I do agree with the logic that some tasks need offloading to pthreads to avoid some head-of-line issues (keepalive, spf computation, huge parsing, etc...). Big thanks, Le 19 mai 2017 18:08:09 David Lamparter <equinox@opensourcerouting.org> a écrit :

Here's a paste of what we wrote down during the meeting. The document is still accessible under this URL: https://docs.google.com/document/d/1736qrFFDHCxokZyb8i2mD_BLMzer0EbDSoOM9zje... (if the formatting of this mail is broken, please use the link)

FRR Multithreading meeting -- minutes & design foo

Context (David) - “Why MT” is hopefully not a big discussion item Generally: - Keepalive problems, i.e. CLI blocking protocol engine - More generally - making use of modern multicore CPUs Possibility to use modern IPC (e.g. shared memory, semaphore …)

Minutes - Priorities: 1. Eliminate CLI blocking 2. Introduce framework for general MT usage - Prior Implementations 1. Implemented by Chris Hall for EuroIX Motivated by keepalive generation blocked by update processing Ultimately not merged due to magnitude of change 2. By David Lamparter as prototype - Evaluations of other event loops - not viable Changes involved too large / invasive

Design - General idea: keep existing userspace “threading” model (thread.c) working as-is as much as possible - Add support for ‘persistent events’ i.e. events / tasks that do not need to be manually rescheduled after they pop - OpenMP? Platform support sketchy, our implementation should be flexible enough to allow the same thing / choice - Models One pthread per connection? Probably way too much implicit ‘locking’ already going on to make this change 1000 bgp peers → 1000 pthreads, not great General idea (current working direction): MT-safe thread_master Avoid excessive locking / code restructuring by allowing pthreads to safely schedule tasks onto each other to do work on data structures they ‘own’ Current primary problem: Struct thread is not owned by anyone in particular Cancellation of a task scheduled / running on another pthread ⇒ possible solution with pthread_setcancelstate() Need implementations of blocking & nonblocking thread_cancel Nonblocking implementations require daemon code to synchronize access to shared data themselves Need _persistent_ tasks / events - Action items Testing for/adding MT-safety of thread_master Memory allocation zlog deduplication of attributes in bgpd

Future work - Thread pooling for one thread_master? - Multiple threads handling events from one thread_master - Socket / shm IPC

_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev