disable rpc tracing by default

[carns]

• enabled via new json paramter or automatically enabled along with monitoring

[codecov]

Codecov Report

Attention: Patch coverage is 77.77778% with 2 lines in your changes missing coverage. Please review.

Project coverage is 57.95%. Comparing base (ce62b9e) to head (b6c16dc).

Files with missing lines	Patch %	Lines
src/margo-core.c	50.00%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #299      +/-   ##
==========================================
+ Coverage   57.93%   57.95%   +0.01%     
==========================================
  Files          70       70              
  Lines       10196    10205       +9     
  Branches     1341     1343       +2     
==========================================
+ Hits         5907     5914       +7     
  Misses       3453     3453              
- Partials      836      838       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[carns]

basic testing under rpc load on sunspot shows a 2 to 5% performance gain for small rpc throughput

[mdorier]

A couple of comments:

• When disabling ABT keys, you are not disabling RPC tracing, you are disabling the possibility to know the parent of an RPC, and to know the RPC that is issuing a bulk transfer. So I would suggest finding a name other than "enable_rpc_tracing". Maybe "enable_lineage_tracking"?
• When ABT keys are disabled, in margo_get_current_rpc_id you set parent_id to 0. However there is already a set value for when there is no lineage, a few lines later: *parent_id = mux_id(0, MARGO_DEFAULT_PROVIDER_ID); (which is not 0, it has the default provider ID, 65535, embedded in it). I'd suggest using the latter value in both cases. Note: the "no lineage available" case appears either when a client sends an RPC with no parent RPC, or when we have lost the parent ID because we are sending the child RPC from a new ULT rather than the parent RPC's ULT.

Note: I think the costly operation in ABT_key_set is somewhere here. I could imagine an alternative to ABT_set_key to attach the parent ID to a ULT: we could use ABT_thread_get_attr followed by ABT_thread_attr_get_stack to get the ULT's stack and stack size, and we place the parent ID as the last 8 bytes of the allocated space for the stack. It's unlikely to get overwritten silently there: if a program reaches this point in the stack, it's most likely going past it as well and causing a crash. What do you think?

[carns]

Yep, Ok. I see what you are saying. Closing this PR in deference to either the solution in #300 or else optimizing the ABT key functions.