Licensing strictness

[vcunat]

Question: some code seems quite reusable to me, but it's licensed as GPL-2.0 (only) – would you consider changing (some of) these to, say, GPL-2.0-or-later? (My particular project is GPL-3.0-or-later.)

It's not a big deal, and I could write similar functionality anew, but it feels better to avoid that. Most notably parsing_helpers.h seems nice; majority of lines there was written by @tohojo.

Side note: SPDX identifier "GPL-2.0" is deprecated now, apparently in favor of the more clear "GPL-2.0-only".

[tohojo]

Vladimír Čunát notifications@github.com writes:

Question: some code seems quite reusable to me, but it's licensed as GPL-2.0 (only) – would you consider changing (some of) these to, say, GPL-2.0-or-later? (My particular project is GPL-3.0-or-later.)

It's not a big deal, and I could write similar functionality anew, but it feels better to avoid that. Most notably parsing_helpers.h seems nice; majority of lines there was written by @tohojo.

Hmm, that's a good question! The plan is definitely to encourage reuse of this code, so I guess we should consider the license. Maybe it should even be dual-licensed to a BSD-style permissive license...

@netoptimizer and @aspsk any objections to relicensing the parts of the parsing helper that you guys have written?

We to plan to keep reusable bits in a separate repo, though: https://github.com/xdp-project/xdp-tools - haven't gotten around to moving things over yet, but it's nearing the top of my to-do list ;)

What's your use case for knot-resolver, BTW?

Side note: SPDX identifier "GPL-2.0" is deprecated now, apparently in favor of the more clear "GPL-2.0-only".

Noted, thanks!

[aspsk]

Hmm, that's a good question! The plan is definitely to encourage reuse of this code, so I guess we should consider the license. Maybe it should even be dual-licensed to a BSD-style permissive license... @netoptimizer and @aspsk any objections to relicensing the parts of the parsing helper that you guys have written?

@tohojo I am ok with a BSD-style license

[vcunat]

What's your use case for knot-resolver, BTW?

Well, we're getting off-topic, but you can move the post later or whatever :-)

For our knot-dns (authoritative-only) and knot-resolver we observe in some usual benchmarking scenarios (direct UDP answer from local data) that roughly half of CPU time is spent in network syscalls for UDP, even after batching via sendmmsg and recvmmsg. It might be interesting for you that sending answers seems to be roughly three times more expensive than receiving requests (with Intel X7?? card). (I tried with another DNS vendor using different syscalls, and the numbers were similar.)

We don't understand kernel networking internals, but I was looking at what can be done about that, and in prototype tests using AF_XDP reduced the expense of TX to a small fraction and the whole throughput increased accordingly. I haven't benchmarked after switching the RX as well, but I expect it will be similar and it only needed some 14% to begin with. It's very nice that I can relatively easily choose DNS-over-UDP to go directly and leave the tiny remaining traffic to the usual networking stack, e.g. I want to avoid doing TCP in user-space, at least for now. Fortunately handling UDP manually isn't complicated, given some hopefully-mild assumptions (symmetric routing, anything else in netfilter, etc.).

[netoptimizer]

I think we should relicense to same licence as libbpf, which is dual GPL and BSD. We want this code to be reused as much as possible.

[tohojo]

Vladimír Čunát notifications@github.com writes:

What's your use case for knot-resolver, BTW?

Well, we're getting off-topic, but you can move the post later or whatever :-)

For our knot-dns (authoritative-only) and knot-resolver we observe in some usual benchmarking scenarios (direct UDP answer from local data) that roughly half of CPU time is spent in network syscalls for UDP, even after batching via sendmmsg and recvmmsg. It might be interesting for you that sending answers seems to be roughly three times more expensive than receiving requests (with Intel X7?? card). (I tried with another DNS vendor using different syscalls, and the numbers were similar.)

We don't understand kernel networking internals, but I was looking at what can be done about that, and in prototype tests using AF_XDP reduced the expense of TX to a small fraction and the whole throughput increased accordingly. I haven't benchmarked after switching the RX as well, but I expect it will be similar and it only needed some 14% to begin with. It's very nice that I can relatively easily choose DNS-over-UDP to go directly and leave the tiny remaining traffic to the usual networking stack, e.g. I want to avoid doing TCP in user-space, at least for now. Fortunately handling UDP manually isn't complicated, given some hopefully-mild assumptions (symmetric routing, anything else in netfilter, etc.).

This makes sense! And being able to do this kind of selective-bypass of the kernel is exactly what we have been envisioning for AF_XDP. So great that you are looking into this! :)

[vcunat]

Perhaps also "pull" updates like this one? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=929ffa6e9

[tohojo]

Vladimír Čunát notifications@github.com writes:

Perhaps also "pull" updates like https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=929ffa6e9

Oh, certainly. However, that commit is a precursor to the files moving into libbpf itself, so when that is complete we'll stop carrying those files in this repository anyway... :)

[vcunat]

Yes, that will be even better.