Thread (35 messages) 35 messages, 9 authors, 2021-06-02

Re: [RFC PATCH bpf-next] bpf: Introduce bpf_timer

From: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Date: 2021-06-02 18:31:38
Also in: bpf

On Wed, Jun 02, 2021 at 11:56:40PM IST, Alexei Starovoitov wrote:
On Wed, Jun 2, 2021 at 11:14 AM Kumar Kartikeya Dwivedi
[off-list ref] wrote:
quoted
On Wed, Jun 02, 2021 at 11:24:36PM IST, Martin KaFai Lau wrote:
quoted
On Wed, Jun 02, 2021 at 10:48:02AM +0200, Toke Høiland-Jørgensen wrote:
quoted
Alexei Starovoitov [off-list ref] writes:
quoted
quoted
quoted
In general the garbage collection in any form doesn't scale.
The conntrack logic doesn't need it. The cillium conntrack is a great
example of how to implement a conntrack without GC.
That is simply not a conntrack. We expire connections based on
its time, not based on the size of the map where it residents.
Sounds like your goal is to replicate existing kernel conntrack
as bpf program by doing exactly the same algorithm and repeating
the same mistakes. Then add kernel conntrack functions to allow list
of kfuncs (unstable helpers) and call them from your bpf progs.
FYI, we're working on exactly this (exposing kernel conntrack to BPF).
Hoping to have something to show for our efforts before too long, but
it's still in a bit of an early stage...
Just curious, what conntrack functions will be made callable to BPF?
Initially we're planning to expose the equivalent of nf_conntrack_in and
nf_conntrack_confirm to XDP and TC programs (so XDP one works without an skb,
and TC one works with an skb), to map these to higher level lookup/insert.
To make sure we're on the same page...
I still strongly prefer to avoid exposing conntrack via stable helpers.
Pls use kfunc and unstable interface.
Correct, that is the idea.

--
Kartikeya
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help