From: ummeegge <ummeegge@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Correct installation for kernel modules
Date: Thu, 19 Oct 2023 09:46:54 +0200 [thread overview]
Message-ID: <d5d303bb6b6668399bcffed397c4c58515b60903.camel@ipfire.org> (raw)
In-Reply-To: <593D97C4-1CF8-407C-8F4D-C777C4EDD25C@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]
Hello Michael,
Am Mittwoch, dem 18.10.2023 um 19:42 +0100 schrieb Michael Tremer:
> Hello Erik,
>
> This is interesting, because OpenVPN probably needs some
> acceleration.
>
> Throughput has always been poor because of the badly implemented
> fragmentation code, that is as far as I know also deprecated and
> therefore won’t be improved, but we all depend on it right now.
>
> However, we have only made very bad experiences with out of tree
> kernel modules. Especially since we now only have two years on the
> LTS kernels, we need to be able to rely on those maintainers to keep
> up. I don’t want to say anything bad about them at all, but in the
> past, even projects that have been moving well suddenly stalled and
> became a large headache for us.
>
> And there might be an alternative that should be an option for
> OpenVPN (at least theoretically): KTLS.
Interesting haven´t heared of that before.
>
> I did a quick Google search and could not find anything. But do you
> know how this module relates to KTLS? Can KTLS not be used in this
> case?
Will give it also a research but haven´t see a concept for KTLS as a
substitution for ovpn-dco or speed acceleration for OpenVPN in general.
Another point is the limitations of ovpn-dco by design since it needs a
subnet topology but IPFire uses net30 and to implement this for
Roadwarriors we would need to change this which is a bigger task. We
spoke about that longer time ago.
What would work out of the box are Net-to-Net connections since they
use a p2p topology and the speed boost from the diagrams looks good so
far --> https://openvpn.net/blog/openvpn-data-channel-offload/ .
Anyways, will research in terms of KTLS for OpenVPN a little more and
come then back in here again.
>
> -Michael
Best,
Erik
>
> > On 18 Oct 2023, at 10:50, ummeegge <ummeegge(a)ipfire.org> wrote:
> >
> > Hi all,
> > wanted to open a testing scenario for the OpenVPN data channel
> > offload
> > (DCO) -->
> > https://github.com/OpenVPN/openvpn/blob/master/README.dco.md
> > kernel module. So far i have been used this LFS -->
> > https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=blob;f=lfs/ovpn-dco;h=8b056518fa7a638dddb39955248ac5b626b9b4cd;hb=5f85ecb7b26628fccbed65c08b54e35c7f249ee5
> > but i wanted to ask for a proper or correct way, in special the
> > installation paths of such modules but in general if i can handle
> > it in
> > such way.
> >
> > Best,
> >
> > Erik
>
next prev parent reply other threads:[~2023-10-19 7:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 9:50 ummeegge
2023-10-18 18:42 ` Michael Tremer
2023-10-19 7:46 ` ummeegge [this message]
2023-10-20 7:37 ` ummeegge
2023-10-20 8:51 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d5d303bb6b6668399bcffed397c4c58515b60903.camel@ipfire.org \
--to=ummeegge@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox