Reconsidering 1-to-1 mapping of ROS nodes to DDS participants

[MartinCornelis2]

Feature request

Reconsidering 1-to-1 mapping of ROS nodes to DDS participants

Feature description

As a result of the research published here:
https://github.com/nobleo/ros2_performance
A ROS discourse discussion was started here:
https://discourse.ros.org/t/reconsidering-1-to-1-mapping-of-ros-nodes-to-dds-participants/10062
at this discussion it was requested that this feature be posted as an issue.

From the discourse discussion:
dirk-thomas:
"Instead of introducing an option the current idea is to associate the DDS participant with the context created during rmw_init. That would imply that common applications using a single init / context will only use a single DDS participant - even if they are composed of multiple ROS nodes."

Argumentation for change: Making every Node in rclcpp a DDS participant creates significant CPU overhead. Use cases exists where all Nodes run on a single piece of hardware. The CPU overhead can be reduced by creating 1 participant per process space.

Implementation considerations

From the discourse discussion:
dirk-thomas:
"... Any help is appreciated. It will likely start with a design article to discuss the side affects of the intended change. E.g. the ROS node name is currently being used for the DDS participant name. When that mapping goes away there needs to be a replacement mechanism to communicate the node name."

kyrofa:
"Not trying to debate the performance gains of this approach, but I think it’s worth pointing out that SROS 2 (and indeed DDS-Security in general) currently only supports security at the domain participant level. Using the same participant for multiple nodes will make security very difficult, as all nodes will have effectively the same identity and thus the same access control."

[artivis]

Relates to ros2/design#250

[fujitatomoya]

thread information with Fast-RTPS,
this is just information cz it is actually dependent on dds vendors implementation.

https://github.com/nobleo/ros2_performance
rosonenode:

rosonenode(25352)─┬─{rosonenode}(25353)
                  ├─{rosonenode}(25354)
                  ├─{rosonenode}(25355)
                  ├─{rosonenode}(25356)
                  ├─{rosonenode}(25357)
                  └─{rosonenode}(25358)

ros:

ros(9434)─┬─{ros}(9435)
          ├─{ros}(9436)
          ├─{ros}(9437)
          ├─{ros}(9438)
          ├─{ros}(9439)
          ├─{ros}(9440)
          ├─{ros}(9441)
          ├─{ros}(9442)
          ├─{ros}(9443)
          ├─{ros}(9444)
          ├─{ros}(9445)
          ├─{ros}(9446)
          ├─{ros}(9447)
          ├─{ros}(9448)
          ├─{ros}(9449)
          ├─{ros}(9450)
          ├─{ros}(9451)
          ├─{ros}(9452)
          ├─{ros}(9453)
          ├─{ros}(9454)
          ├─{ros}(9455)
          ├─{ros}(9456)
          ├─{ros}(9457)
          ├─{ros}(9458)
          ├─{ros}(9459)
          ├─{ros}(9460)
          ├─{ros}(9461)
          ├─{ros}(9462)
          ├─{ros}(9463)
          ├─{ros}(9464)
          ├─{ros}(9465)
          ├─{ros}(9466)
          ├─{ros}(9467)
          ├─{ros}(9468)
          ├─{ros}(9469)
          ├─{ros}(9470)
          ├─{ros}(9471)
          ├─{ros}(9472)
          ├─{ros}(9473)
          ├─{ros}(9474)
          ├─{ros}(9475)
          └─{ros}(9476)

# of threads = main1thread + 2subthreads + (4 x #ofParticipants)

[wjwwood]

I'm going to close this in favor of the existing design pr (ros2/design#250) and discourse discussions (https://discourse.ros.org/t/reconsidering-1-to-1-mapping-of-ros-nodes-to-dds-participants/10062/12) and because this will affect way more than just this repository.

Feel free to continue to comment or suggest a reason why we should keep this open.