This repository was archived by the owner on Nov 15, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Implement Network Bridge #1280
Merged
Merged
Implement Network Bridge #1280
Changes from 1 commit
Commits
Show all changes
34 commits
Select commit
Hold shift + click to select a range
54873ea
network bridge skeleton
rphmeier 5eea3bf
move some primitives around and add debug impls
rphmeier 27456b5
protocol registration glue & abstract network interface
rphmeier 3bf17fa
add send_msgs to subsystemctx
rphmeier e05abd2
select logic
rphmeier ba005c9
transform different events into actions and handle
rphmeier 7572bba
implement remaining network bridge state machine
rphmeier 24a91c4
start test skeleton
rphmeier 064a00c
make network methods asynchronous
rphmeier c116061
extract subsystem out to subsystem crate
rphmeier e6162de
port over overseer to subsystem context trait
rphmeier 844a9d1
fix minimal example
rphmeier cae1561
fix overseer doc test
rphmeier 2c9be73
update network-bridge crate
rphmeier 534535f
write a subsystem test-helpers crate
rphmeier 8ac6269
write a network test helper for network-bridge
rphmeier 51ff607
set up (broken) view test
rphmeier 960029b
Revamp network to be more async-friendly and not require Sync
rphmeier eb52f9a
fix spacing
rphmeier f6526c4
fix test compilation
rphmeier 0f5a1b1
insert side-channel for actions
rphmeier 8f75746
Add some more message types to AllMessages
rphmeier 940216b
introduce a test harness
rphmeier 859bd8b
add some tests
rphmeier c504d12
Merge branch 'master' into rh-network-bridge
rphmeier 4343f5c
ensure service compiles and passes tests
rphmeier 98c4c54
fix typo
rphmeier d194838
fix service-new compilation
rphmeier d468a2b
Subsystem test helpers send messages synchronously
rphmeier b676adc
remove smelly action inspector
rphmeier 7d44a62
remove superfluous let binding
rphmeier 989e8b5
fix warnings
rphmeier 64792f7
Update node/network/bridge/src/lib.rs
rphmeier 50b51dd
fix compilation
rphmeier File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
make network methods asynchronous
- Loading branch information
commit 064a00c244c6c1c6a240e6998850fbe5ddc52edc
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the reason for sending a message to all but the first one to only then send the same message to the first one?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It prevents a
cloneif we are sending only to one peer, and these messages can be pretty large in practical situations.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was curious whether this loop unrolling would be more performant than the optimizations rustc and llvm do already.
I wrote a small benchmark https://github.com/mxinden/clone-trick/blob/master/benches/bench.rs distributing a message of 1 KB, 10 KB, 100 KB and 1 MB among 20 peers.
The manual loop unrolling does have a performance impact, but a small one. While the simple implementation takes 3.9 us to distribute a 10 KB message to 20 peers the optimized implementation takes 3.6 us (on a
i7-8550U).I would expect that if
write_notificationaccepts some type that allows sharing of the underlying allocation (e.g.BytesorArc<Vec<u8>>like we do forNotificationsReceivedthe entire memory allocation overhead would vanish.@rphmeier in case you want to keep the optimization in here (e.g. for the impact it has in case there is only a single peer and thus no
cloneneeded), would you mind adding a comment describing why this is not a single for loop?Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a memory optimization, not a performance one. Computers are pretty fast, but if I'm sending a 10MiB message to 20 peers I'd rather keep memory usage down by 5% while this is buffered. This would be solved by having the lower-level APIs take
Bytes, BTW, and the comment I added yesterday (but didn't push) notes that.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would also be addressed by the lower level APIs accepting a set of peers to send a message to. I don't view this optimization as premature. PoVs are likely to be in the range of 1-10 MiB and we gossip them to all our peers (because peer set management and validator authentication still isn't in a state where we can do something more targeted).
The underlying network and discovery deficiencies are the forest for the trees on this optimization - get those working, and we won't need to use tricks like this. Unfortunately, rustc and LLVM are not smart enough to do that for us...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you suggesting that this optimization keeps the resident set size in memory low? How does it do that?
Say we send a message to 20 peers. With the un-optimized implementation the message would be cloned 20 times, thus for a short amount of time the message would exist 21 times in memory. But this 21st (useless) copy of the message is dropped right at the end of the function scope, thus this optimization only reduces the total resident set size for the duration of the function scope, which I would guess is negligible.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, every little bit counts. Given that we're
awaiting here before dropping the last clone, there's no guarantee how long that will take.