Thread (50 messages) 50 messages, 8 authors, 2020-03-10

Re: [PATCH bpf-next 0/3] Introduce pinnable bpf_link kernel abstraction

From: David Ahern <hidden>
Date: 2020-03-06 18:09:30
Also in: bpf

On 3/6/20 3:25 AM, Daniel Borkmann wrote:
quoted
Presumably the XDP EGRESS hook that David Ahern is working on will make
this doable for XDP on veth as well?
I'm not sure I see a use-case for XDP egress for Cilium yet, but maybe
I'm still
lacking a clear picture on why one should use it. We currently use various
layers where we orchestrate our BPF programs from the agent. XDP/rx on
the phys
nic on the one end, BPF sock progs attached to cgroups on the other end
of the
spectrum. The processing in between on virtual devices is mainly
tc/BPF-based
since everything is skb based anyway and more flexible also with
interaction
with the rest of the stack. There is also not this pain of having to
linearize
all the skbs, but at least there's a path to tackle that.

{ veth-host } <----> { veth-container }

If you are currently putting an XDP program on veth-container, it is run
on the "Rx" of the packet from the host. That program is visible to the
container, but is managed by the host.

With XDP Tx you can put the same program on veth-host.

For containers, sure, maybe you don't care since you control all aspects
of the networking devices. For VMs, the host does not have access to or
control of the "other end" in the guest. Putting a program on the tap's
"Tx" side allows host managed, per-VM programs.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help