Skip to content

Support core affinity for subscription threads #661

Open
@levb

Description

@levb

See https://natsio.slack.com/archives/C01AWP40KGF/p1684269701738519

An options API would be a good approach. Internally there could be a struct for various fields, one of the fields could be a cpu_set_t like member, which would define the core or core(s) that the NATS thread could run upon.
Something similar to the posix CPU_SET/CPU_ZERO would be needed to allow for cores to be added to it in a sensible way - wouldn't want people to having to deal with cores in terms of masks.

Here are some possible additions to the API:
Types:
natsCoreSet
APIs:

natsOptions_ClearCoreSet(natsCoreSet**)
natsOptions_AddCore(natsCoreSet**, int coreid)
natsOptions_RemoveCore(natsCoreSet**, int coreid)
natsOptions_ApplyCoreSet(natsCoreSet*)

The above would then have to be called before the NATs thread is created which would be before any natsConnection_Subscribe call is made, a possible example would be like so:

{
   natsCoreSet core_set;
   natsConnection* conn = nullptr;
   natsSubscription *sub = nullptr;

   natsOptions_ClearCoreSet(core_set);

   // NATS thread shall only run on cores 1,3 and 5
   natsOptions_AddCore(core_set,1)
   natsOptions_AddCore(core_set,3)
   natsOptions_AddCore(core_set,5)

   natsOptions_ApplyCoreSet(core_set)

   natsConnection_ConnectTo(&conn, nats_uri);
   natsConnection_Subscribe(&sub, conn, subj, msg_handler, nullptr);
   .
   .
   .

   while (running)
   {
   }
}

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementEnhancement to existing functionality

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions