Agree.


For the existing bpf_redirect_peer(ifindex, 0), there are two ways to
read what 0 means:

1. If we consider the operated object to be the peer of ifindex, then 0
means the peer does ingress.
2. If we consider the operated object to be ifindex itself, then 0 means
ifindex does egress
    (which results in its peer doing ingress).

This patch's new mode operates on the peer — on the host side, we want
to "write" to the dev inside the pod to
make the packet look like it leaves the pod. That fits reading (1), where
the flag describes the peer's direction: 0 is peer ingress, and this new
mode is peer egress.
So BPF_F_EGRESS would be the clearer name; reusing BPF_F_INGRESS for
what is really a
peer-egress action is what creates the ambiguity.

(2) is my original interpretation that makes BPF_F_INGRESS make sense;
you're operating on ifindex, so the flag matches the direction
relative to ifindex. Under that interpretation, 0 for "egress" (really
ingress on the peer side) and BPF_F_INGRESS for "ingress" (really
egress on the peer side) makes sense.

That said, I agree BPF_F_EGRESS is probably clearer, so I'll go with
that in the next version of the series.