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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/6/20 3:25 AM, Daniel Borkmann wrote:
>>
>> 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.



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux