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