On 10/26/23 7:18 AM, Jiri Pirko wrote:
Wed, Oct 25, 2023 at 07:20:01PM CEST, daniel@xxxxxxxxxxxxx wrote:
On 10/25/23 5:47 PM, Jiri Pirko wrote:
Tue, Oct 24, 2023 at 11:48:58PM CEST, daniel@xxxxxxxxxxxxx wrote:
[...]
comes with a primary and a peer device. Only the primary device, typically
residing in hostns, can manage BPF programs for itself and its peer. The
peer device is designated for containers/Pods and cannot attach/detach
BPF programs. Upon the device creation, the user can set the default policy
to 'pass' or 'drop' for the case when no BPF program is attached.
It looks to me that you only need the host (primary) netdevice to be
used as a handle to attach the bpf programs. Because the bpf program
can (and probably in real use case will) redirect to uplink/another
pod netdevice skipping the host (primary) netdevice, correct?
If so, why can't you do just single device mode from start finding a
different sort of bpf attach handle? (not sure which)
The first point where we switch netns from a K8s Pod is out of the netdevice.
For the CNI case the vast majority has one but there could also be multi-
homing for Pods where there may be two or more, and from a troubleshooting
PoV aka tcpdump et al, it is the most natural point. Other attach handle
inside the Pod doesn't really fit given from policy PoV it also must be
unreachable for apps inside the Pod itself.
Okay. What is the usecase for the single device model then?
One immediate use case in the context of Cilium itself is to replace
and simplify our cilium_host/cilium_net pair which is in the hostns
and depending on the routing mode that Cilium is configured in handling
traffic/policy from host into Pods respectively from host or Pods into
collect_md encaps in order to route traffic E/W to other cluster nodes.
Going further, we were thinking also to have single dev and move it into
target netns with policy being configured from host.
Best,
Daniel
