On 05/06/20 12:28 +0100, Bruce Richardson wrote: > On Fri, Jun 05, 2020 at 12:43:00PM +0200, Gaëtan Rivet wrote: > > On 04/06/20 18:04 -0700, Stephen Hemminger wrote: > > > I have a full patch that replaces the master/slave lcore > > > naming (widely used in DPDK) with a better primary/secondary naming. > > > > > > For now this is just a trial balloon to see what the impact would > > > look like. The change mostly automated so likely that things > > > are broken. > > > > > > It is hard to break a change like this down, and still > > > keep git bisection clean. > > > > > > It keeps rte_master_lcore_id and RTE_FOREACH_SLAVE as deprecated > > > items so that user code can still be built but they will be motivated > > > to change. > > > > > > Here is a sample of what it would look like: > > > > > > > I think PRIMARY is a poor choice to describe the control thread. PRIMARY > > is often used to designate the active element currently doing the work. > > SECONDARY threads are also active threads doing equal dataplane work. > > > > Another issue I see with primary / secondary is the ambiguity with > > multi-process in DPDK. Doc readers could get confused about where a > > primary / secondary thread is executed. > > > > I think we could use instead DPDK-specific terminology. The lcore > > organization is a little specific, with an lcore that does most init work > > and spawns the others, but then runs the application like all others. > > > > I'd propose instead leader lcore - there is this idea that the leader > > is still a member of the team and will participate in the work. > > > > Leader / worker? > > > No sure I like the term "Leader" for a thread, but "worker" is an ok name. > How about "init thread" and "worker threads"? > > /Bruce
Init was actually my first idea :) . I thought leader could be more palatable in some documentation, but after some tests I think init thread could work better after all. I was thinking init / spawned threads first, but worker is ok. -- Gaëtan
