Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Namespace prefix support #1792

Open
wants to merge 27 commits into
base: main
Choose a base branch
from

Conversation

DenisBiryukov91
Copy link
Contributor

@DenisBiryukov91 DenisBiryukov91 commented Feb 24, 2025

Namespace prefix support
Supersedes #1772.
Includes #1780.
Related PRs to account for api changes:
eclipse-zenoh/zenoh-c#930
eclipse-zenoh/zenoh-cpp#417

Copy link

PR missing one of the required labels: {'internal', 'bug', 'enhancement', 'dependencies', 'documentation', 'new feature', 'breaking-change'}

@DenisBiryukov91 DenisBiryukov91 added the enhancement Existing things could work better label Feb 24, 2025
@gabrik
Copy link
Contributor

gabrik commented Feb 26, 2025

Btw this needs to be tested also with rmw_zenoh, idea on how to do it?

};

pub(crate) static KE_UHLC: &keyexpr = ke!("uhlc");
#[zenoh_macros::unstable]
kedefine!(
pub(crate) ke_liveliness: "@adv/${entity:*}/${zid:*}/${eid:*}/${meta:**}/@/${remaining:**}",
pub(crate) ke_liveliness: "${remaining:**}/@adv/${entity:*}/${zid:*}/${eid:*}/${meta:**}",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the current form a keyexpr is transformed from a/b/c to @foo/prefix/a/b/c.
Would it make sense to simply invert the order to a/b/c/@foo/prefix?
Would it make the whole namespace prefix logic simpler?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand the comment, In this PR it is indeed supposed to be transformed into a/b/c/@foo/prefix

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the clarification. I see the intended behaviour was introduced by #1780 and integrated in this PR. I was momentarily misled by this PR title.

@DenisBiryukov91
Copy link
Contributor Author

Btw this needs to be tested also with rmw_zenoh, idea on how to do it?

Maybe @evshary have some ideas, otherwise I suppose we would need to create dedicated branches on zenoh-c and zenoh-cpp.

@Mallets
Copy link
Member

Mallets commented Feb 26, 2025

The implementation LGTM. However it should be tested with rmw_zenoh and performance should be re-evaluated because of changes to the Session.

@gabrik gabrik self-requested a review February 26, 2025 10:29
@gabrik
Copy link
Contributor

gabrik commented Feb 26, 2025

Sister PRs may be needed for bindings, as just changing the branch makes zenoh-c CI to fail: https://github.com/eclipse-zenoh/zenoh-c/actions/runs/13541109439/

@gabrik
Copy link
Contributor

gabrik commented Feb 26, 2025

The implementation LGTM. However it should be tested with rmw_zenoh and performance should be re-evaluated because of changes to the Session.

I did run some tests on my machine:

  • Fedora 41 (Linux 6.12.8)
  • AMD Ryzen 7940HS

and I got:

current main 8 bytes payload, routed:

./target/release/examples/z_sub_thr -m client -e tcp/127.0.0.1:7447
Press CTRL-C to quit...
1277457.120427186 msg/s
1518631.413015306 msg/s
1565301.5963634413 msg/s
1711239.609994803 msg/s
1719369.142141571 msg/s
1900478.8047295848 msg/s
1976058.15839521 msg/s
1985429.5283205141 msg/s
2179012.9759786916 msg/s
2310795.2613445893 msg/s

this branch 8 bytes payload, routed, namespace is : test-user:

./target/release/examples/z_sub_thr -c zz-confs/config-client1.json 
Press CTRL-C to quit...
1365669.8646876547 msg/s
1624621.5423809255 msg/s
1620312.2341675241 msg/s
1676526.5146943443 msg/s
1603012.5093485687 msg/s
1706649.4527176267 msg/s
1903488.0180663855 msg/s
1861687.6649210923 msg/s
1908878.9020586687 msg/s
2078146.7120871954 msg/s

so a few hundreds k/msgs/s are lost

may need to re-run the test on a better machine, instead of the laptop

@gabrik
Copy link
Contributor

gabrik commented Feb 27, 2025

Here results on a proper machine

Throughput

main, p2p
2025:02:27-08:00:07 throughput aggregated

namespace-as-dyn, namespace = "test", p2p
2025:02:27-10:32:44 throughput aggregated

namespace-as-dyn, no namespace, p2p
2025:02:27-13:30:43 throughput aggregated

Latency

main, p2p
2025:02:27-12:25:58 latency aggregated

namespace-as-dyn, namespace = "test", p2p
2025:02:27-11:21:48 latency aggregated

namespace-as-dyn, no namespace, p2p
2025:02:27-13:00:25 latency aggregated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Existing things could work better
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants