Import CPU code #292
Import CPU code #292
Conversation
| }; | ||
|
|
||
| impl<N: NetworkTrait> IrisWorker<N> { | ||
| pub async fn async_rep3_dot( |
There was a problem hiding this comment.
do we want both async and sync variants of these functions? Also, do we even want both REP3 and Shamir dot products?
There was a problem hiding this comment.
I think for starters wanted to get the code going with rep3, then we could switch to Shamir. And regarding sync/vs async - would like to avoid blocking code, so prefer async instead of sync functions.
| async fn send(&mut self, id: PartyID, data: Bytes) -> Result<(), IoError>; | ||
| async fn send_next_id(&mut self, data: Bytes) -> Result<(), IoError>; | ||
| async fn send_prev_id(&mut self, data: Bytes) -> Result<(), IoError>; | ||
|
|
||
| async fn receive(&mut self, id: PartyID) -> Result<BytesMut, IoError>; | ||
| async fn receive_prev_id(&mut self) -> Result<BytesMut, IoError>; | ||
| async fn receive_next_id(&mut self) -> Result<BytesMut, IoError>; | ||
|
|
||
| async fn broadcast(&mut self, data: Bytes) -> Result<Vec<BytesMut>, IoError>; | ||
| //======= sync world ========= | ||
| fn blocking_send(&mut self, id: PartyID, data: Bytes) -> Result<(), IoError>; | ||
| fn blocking_send_next_id(&mut self, data: Bytes) -> Result<(), IoError>; | ||
| fn blocking_send_prev_id(&mut self, data: Bytes) -> Result<(), IoError>; | ||
|
|
||
| fn blocking_receive(&mut self, id: PartyID) -> Result<BytesMut, IoError>; | ||
| fn blocking_receive_prev_id(&mut self) -> Result<BytesMut, IoError>; | ||
| fn blocking_receive_next_id(&mut self) -> Result<BytesMut, IoError>; | ||
|
|
||
| fn blocking_broadcast(&mut self, data: Bytes) -> Result<Vec<BytesMut>, IoError>; |
There was a problem hiding this comment.
we should also maybe consider reducing this down to the actual networking impl set that we want to have (async/sync)
There was a problem hiding this comment.
Additionally, there is no concrete impl here other than the test-network right? What is the plan here
There was a problem hiding this comment.
Indeed, there's not concrete impl other than that. We were thinking that the plan could be to get in the Aby3Store implementation which uses the TestNetwork and then refactor the network according to needs.
See https://github.com/Inversed-Tech/iris-hawk/blob/main/src/aby3_store.rs for reference
There was a problem hiding this comment.
I guess this is something for the infra team to dictate, in our impl we used QUIC using the quinn library as a concrete impl, but I guess just standard TLS over TCP is also fine. I think there was some talk of actually using NCCL here, but I don't think the ergonomics (and probably also perf) are very nice
There was a problem hiding this comment.
there are ways to do that, I've done a few times using a DashMap https://docs.rs/dashmap/latest/dashmap/ https://github.com/tf-encrypted/moose/blob/main/moose/src/networking/local.rs
There was a problem hiding this comment.
I think why I like using &self instead of &mut self is that it gets rid of the locks when doing operations on a global network that I'm doing: https://github.com/Inversed-Tech/iris-hawk/blob/main/src/aby3_store.rs#L146
There was a problem hiding this comment.
I see, mostly because the interface of hawk-pack is &self. But there would still need to be a lot of syncing internally otherwise you cannot use the networking impl for MT code anyway, as concurrent calls to less_than would use the same networking and therefore may receive messages in the wrong order. So a correct implementation would need to separate the channels/multiplex the networking correctly anyway using internal locking etc. I think it would be easier to have the lock in there, and e.g., grab a new channel from the "global" network manager that can be used for the local execution here. The "global" network manager can then internally use the locks to allow a &self bound, get a new channel for the protocol and execute it on that Channel it exclusively owns.
There was a problem hiding this comment.
Yep, I agree. The global network manager should have the locking logic inside of it, rather than spilling into other parts of the code.
Is this already done somewhere, or do you reckon this would be part of a large refactoring?
There was a problem hiding this comment.
no sadly this is not implemented right now
|
@philsippl, @rdragos wants to merge this as a baseline to build the hawk-pack interface on, anything holding this back? |
|
@dkales sounds good, don't see see a reason not to merge> |
No description provided.