BPF Archive on lore.kernel.org
 help / color / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: bpf@vger.kernel.org
Cc: lsf-pc@lists.linux-foundation.org
Subject: [LSF/MM/BPF] BPF: various topics
Date: Fri, 14 Feb 2020 23:33:06 +0100
Message-ID: <853944be-2700-6a65-597f-9971707a3a47@iogearbox.net> (raw)

I'd like to propose various BPF core and networking related topics some of which we
also encountered during Cilium development, for example, during our recent BPF
kube-proxy replacement work:

- Cilium uses BPF cgroups programs for its Kubernetes Service implementation
   in order to select backends and directly connect to them instead of later
   having to perform NAT on the skb itself in lower layers. BPF cgroups hooks
   are not network namespace aware while Kubernetes pods are heavily built
   around network namespaces. In addition to getting BPF cgroups netns aware,
   I'd like to discuss various other needs Cilium has around its BPF cgroups
   usage in order to fix some short-comings we're facing today including
   the addition of new hooks.
- Another issue is the BPF fib lookup helper use in combination with our BPF
   based NodePort implementation, where goal is to discuss design proposals to
   enable the Cilium agent to push L3 addresses into the kernel for its backends
   and have the neighboring subsystem self-manage & maintain their resolution.
- Third topic is to discuss a BPF-based static keys proposal in order to
   dynamically allow to enable/disable functionality at runtime with very low
   overhead and without reloading programs through the verifier. This builds upon
   recent work that has been done around direct jumps for optimizing tail calls.
- Some of the LRU based maps in Cilium have interdependencies; currently, we
   use a band-aid through the means of a garbage collector in order to evict
   data from multiple maps, but what is needed is a LRU eviction callback that
   we can make use of in order to trigger deletion events in dependent maps.
   We'll discuss possible API options on how this could be addressed generically.

Thanks,
Daniel

                 reply index

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publically 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=853944be-2700-6a65-597f-9971707a3a47@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=bpf@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.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

BPF Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/bpf/0 bpf/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 bpf bpf/ https://lore.kernel.org/bpf \
		bpf@vger.kernel.org
	public-inbox-index bpf

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.bpf


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git