On Tue, 2019-03-12 at 15:21 +0000, Phillips, Tony wrote: > + 48.50% 0.08% lt-openconnect [kernel.vmlinux] [k] system_call_fastpath > + 19.57% 0.10% lt-openconnect [kernel.vmlinux] [k] sys_write > + 19.37% 0.15% lt-openconnect [kernel.vmlinux] [k] vfs_write > + 18.22% 0.00% lt-openconnect libpthread-2.17.so [.] __write_nocancel > + 17.74% 0.08% lt-openconnect [kernel.vmlinux] [k] do_sync_write > + 17.67% 0.08% lt-openconnect [tun] [k] tun_chr_aio_write > + 17.52% 0.45% lt-openconnect [tun] [k] tun_get_user Well, that certainly seems like I've done a fair job of getting OpenConnect's own code out of the way, and making sure it's all about the necessary system call overhead. It'd certainly be interesting to see what we get if we use the kernel's ESP support. OpenConnect will dump the keys, and we should be able to hack out its own ESP implementation and just configure the kernel instead. Might need some experimentation to send the empty 'probe' packets and to make OpenConnect send the switch command over the TCP connection, but coming up with a hackish way of doing that just to test should be simple enough.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
