Look into adding the fd= option to virtio-net
#24
Comments
jakecorrenti
changed the title
fd=option to virtio-netfd= option to virtio-net
|
Does libkrun itself support datagram sockets? We use |
|
Sorry, didn't mean to close issue. |
|
[1] https://github.com/containers/libkrun/blob/57a5a6bfbe5d2333d88fd88fcedb9c1d1fec9cc2/src/devices/src/virtio/net/passt.rs#L18 |
|
Ah, understood |
|
I think this should be easy change:
This is exactly what vmnet-helper is doing on the server side: |
|
gvproxy should also support passing file descriptors. Using unix socket on disk is nice for playing with it with shell scripts but for real usage by programs you want to pass file descriptors. |
Connecting to the socket set the remote address so we can use send()/recv() or write()/read() instead of sendto()/recvfrom(). Advantages: - Simpler code, no need to keep the remote address. - The server will want to connect to the client address to ensure it receives frames only from the connected client. Such server will want to remove the unix socket once the client connected[2], which doe snot work with current code. - Once the socket is connected, the same backend can be used to handle passed file descriptor[1]. Testing: - Tested with vmnet-helper - Not tested yet with gvproxy [1] containers/krunkit#24 [2] https://github.com/nirs/vmnet-helper/blob/5c6a595ba3e76314e1d0bef2b0160388439d69ec/helper.c#L475
Connecting to the socket set the remote address so we can use send()/recv() or write()/read() instead of sendto()/recvfrom(). Advantages: - Simpler code, no need to keep the remote address. - The server will want to connect to the client address to ensure it receives frames only from the connected client. Such server will want to remove the unix socket once the client connected[2], which doe snot work with current code. - Once the socket is connected, the same backend can be used to handle passed file descriptor[1]. Testing: - Tested with vmnet-helper - Not tested yet with gvproxy [1] containers/krunkit#24 [2] https://github.com/nirs/vmnet-helper/blob/5c6a595ba3e76314e1d0bef2b0160388439d69ec/helper.c#L475 Signed-off-by: Nir Soffer <[email protected]>
Connecting to the socket set the remote address so we can use send()/recv() or write()/read() instead of sendto()/recvfrom(). Advantages: - Simpler code, no need to keep the remote address. - The server will want to connect to the client address to ensure it receives frames only from the connected client. Such server will want to remove the unix socket once the client connected[2], which doe snot work with current code. - Once the socket is connected, the same backend can be used to handle passed file descriptor[1]. - iperf3 -R is 1.33 times faster (46.6 Gbits/s vs 35.0 Gbits/s). Tested with: - [x] gvproxy - [x] vmnet-helper For testing results see containers#264 (comment) [1] containers/krunkit#24 [2] https://github.com/nirs/vmnet-helper/blob/5c6a595ba3e76314e1d0bef2b0160388439d69ec/helper.c#L475 Signed-off-by: Nir Soffer <[email protected]>
Connecting to the socket set the remote address so we can use send()/recv() or write()/read() instead of sendto()/recvfrom(). Advantages: - Simpler code, no need to keep the remote address. - The server will want to connect to the client address to ensure it receives frames only from the connected client. Such server will want to remove the unix socket once the client connected[2], which doe snot work with current code. - Once the socket is connected, the same backend can be used to handle passed file descriptor[1]. - iperf3 -R is 1.33 times faster (46.6 Gbits/s vs 35.0 Gbits/s). Tested with: - [x] gvproxy - [x] vmnet-helper For testing results see containers#264 (comment) [1] containers/krunkit#24 [2] https://github.com/nirs/vmnet-helper/blob/5c6a595ba3e76314e1d0bef2b0160388439d69ec/helper.c#L475 Signed-off-by: Nir Soffer <[email protected]>
Connecting to the socket sets the remote address so we can use send()/recv() or write()/read() instead of sendto()/recvfrom(). Advantages: - Simpler code, no need to keep the remote address. - The server will want to connect to the client address to ensure it receives frames only from the connected client. Such server will want to remove the unix socket once the client connected[2], which doe snot work with current code. - Once the socket is connected, the same backend can be used to handle passed file descriptor[1]. - iperf3 -R is 1.33 times faster (46.6 Gbits/s vs 35.0 Gbits/s). Tested with: - [x] gvproxy - [x] vmnet-helper For testing results see containers#264 (comment) [1] containers/krunkit#24 [2] https://github.com/nirs/vmnet-helper/blob/5c6a595ba3e76314e1d0bef2b0160388439d69ec/helper.c#L475 Signed-off-by: Nir Soffer <[email protected]>
Connecting to the socket sets the remote address so we can use send()/recv() or write()/read() instead of sendto()/recvfrom(). Advantages: - Simpler code, no need to keep the remote address. - The server will want to connect to the client address to ensure it receives frames only from the connected client. Such server will want to remove the unix socket once the client connected[2], which doe snot work with current code. - Once the socket is connected, the same backend can be used to handle passed file descriptor[1]. - iperf3 -R is 1.33 times faster (46.6 Gbits/s vs 35.0 Gbits/s). Tested with: - [x] gvproxy - [x] vmnet-helper For testing results see containers#264 (comment) [1] containers/krunkit#24 [2] https://github.com/nirs/vmnet-helper/blob/5c6a595ba3e76314e1d0bef2b0160388439d69ec/helper.c#L475 Signed-off-by: Nir Soffer <[email protected]>
For the
virtio-netdevice, vfkit allows the user to specify either a Unix socket path or the file descriptor of a datagram socket. Krunkit, however, only supports a Unix socket path.We should look into whether we want to get closer to vfkit parity here.
The text was updated successfully, but these errors were encountered: