Hi,
I used below ugly way to benchmark the performance roughly. In POC,
confirmed the hardware crypto engine is the bottleneck and not very
fast
for packet not over than 1500 bytes. Overhead is required for queuing
the data to crypto engine and sending data back to kernel.
Hi Antonio,
I am porting ovpn-dco to embedded ARMv8 device with hardware crypto
engine. However the performance is not very good.
It's about 130-140Mbps. I expect more. The SDK already provides kernel
CryptoAPI(CFI) interface to access the crypto engine.
I want to know if the crypto operation is
These two new methods can be used to create and delete a tun or an
ovpn-dco interface via networking API.
Implementations for SITNL and iproute2 are provided
Signed-off-by: Arne Schwabe
Signed-off-by: Antonio Quartulli
---
src/openvpn/networking.h | 27
Implement the data-channel offloading using the ovpn-dco kernel
module. See README.dco.md for more details.
Signed-off-by: Arne Schwabe
Signed-off-by: Antonio Quartulli
---
Changes.rst| 7 +
README.dco.md | 129 +++
configure.ac
Signed-off-by: Antonio Quartulli
---
.github/workflows/build.yaml | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/.github/workflows/build.yaml b/.github/workflows/build.yaml
index 579bbb5d..0225daea 100644
--- a/.github/workflows/build.yaml
+++
From: Arne Schwabe
The net_ctx_init/reset/free methods of sitnl are the same dummy
methods that are already defined for non-Linux platforms in the
networking.h header.
Signed-off-by: Arne Schwabe
Signed-off-by: Antonio Quartulli
---
src/openvpn/networking.h | 7 ++-
In the net_ctx_init() stub definition, arguments are not used and
therefore they should be explicitly marked to avoid compiler
warnings.
Signed-off-by: Antonio Quartulli
---
src/openvpn/networking.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/openvpn/networking.h
Hi all,
this is the first official submission of the ovpn-dco support for
OpenVPN 2. This patchset is ready for review (and possible merge).
Please have a look, test and try to break it!
What has changed from the RFCv2 (sent on Jan 14th):
* DCO API has been modified to allow specifying a value
From: Arne Schwabe
This moves closing the tun handle into its own function and also prints
the adapter type we are operating on, instead hardcoding it to
tap-windows.
Signed-off-by: Arne Schwabe
Signed-off-by: Antonio Quartulli
---
src/openvpn/tun.c | 75
