From: Jiayuan Chen <jiayuan.chen@linux.dev>
To: Jordan Rife <jordan@jrife.io>, bpf@vger.kernel.org
Cc: netdev@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Stanislav Fomichev <sdf@fomichev.me>,
Jiayuan Chen <jiayuan.chen@linux.dev>,
Paul Chaignon <paul.chaignon@gmail.com>
Subject: Re: [PATCH v2 bpf-next 1/2] bpf: Support BPF_F_EGRESS with bpf_redirect_peer
Date: Thu, 25 Jun 2026 11:37:34 +0800 [thread overview]
Message-ID: <184b1d3c-a9cd-436a-b2b2-c5bac488859b@linux.dev> (raw)
In-Reply-To: <20260618182035.43811-2-jordan@jrife.io>
On 6/19/26 2:20 AM, Jordan Rife wrote:
> We have several use cases where a pod injects traffic into the datapath
> of another so that the traffic appears to have originated from that
> pod. One such use case is a synthetic flow generator which injects
> synthetic traffic into a pod's datapath to enable dynamic probing and
> debugging. Another is a transparent proxy where connections originating
> from one pod are redirected towards another which proxies that
> connection. The new connection is bound to the IP of the original pod
> using IP_TRANSPARENT and its traffic is injected into that pod's
> datapath and handled as if it had originated there. This can be used for
> mTLS, etc.
>
[...]
>
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-60.00 sec 272 GBytes 38.9 Gbits/sec 0 sender
> [ 5] 0.00-60.00 sec 272 GBytes 38.9 Gbits/sec receiver
>
> In this test, using bpf_redirect_peer(BPF_F_EGRESS) for the hop from
> [iperf pod] to [pod b] led to ~18% more throughput compared to
> bpf_redirect(BPF_F_INGRESS).
>
> Signed-off-by: Jordan Rife <jordan@jrife.io>
> ---
> include/uapi/linux/bpf.h | 19 +++++++++++--------
> net/core/filter.c | 12 +++++++-----
> tools/include/uapi/linux/bpf.h | 19 +++++++++++--------
> 3 files changed, 29 insertions(+), 21 deletions(-)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 89b36de5fdbb..c91b5a4bda03 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -5079,17 +5079,19 @@ union bpf_attr {
> * Description
> * Redirect the packet to another net device of index *ifindex*.
> * This helper is somewhat similar to **bpf_redirect**\ (), except
> - * that the redirection happens to the *ifindex*' peer device and
> - * the netns switch takes place from ingress to ingress without
> - * going through the CPU's backlog queue.
> + * that the redirection happens to the *ifindex*' peer device. If
> + * *flags* is 0, the netns switch takes place from ingress to
> + * ingress without going through the CPU's backlog queue. If the
> + * **BPF_F_EGRESS** flag is provided then redirection happens in
> + * the egress direction of the peer device.
> *
> * *skb*\ **->mark** and *skb*\ **->tstamp** are not cleared during
> * the netns switch.
> *
> - * The *flags* argument is reserved and must be 0. The helper is
> - * currently only supported for tc BPF program types at the
> - * ingress hook and for veth and netkit target device types. The
> - * peer device must reside in a different network namespace.
> + * If the *flags* argument is 0, the helper is currently only
> + * supported for tc BPF program types at the ingress hook and for
> + * veth and netkit target device types. The peer device must reside
> + * in a different network namespace.
> * Return
> * The helper returns **TC_ACT_REDIRECT** on success or
> * **TC_ACT_SHOT** on error.
> @@ -6336,9 +6338,10 @@ enum {
> /* Flags for bpf_redirect and bpf_redirect_map helpers */
> enum {
> BPF_F_INGRESS = (1ULL << 0), /* used for skb path */
> + BPF_F_EGRESS = (1ULL << 1), /* used for skb path */
> BPF_F_BROADCAST = (1ULL << 3), /* used for XDP path */
> BPF_F_EXCLUDE_INGRESS = (1ULL << 4), /* used for XDP path */
> -#define BPF_F_REDIRECT_FLAGS (BPF_F_INGRESS | BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS)
> +#define BPF_F_REDIRECT_FLAGS (BPF_F_INGRESS | BPF_F_EGRESS | BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS)
> };
>
Thanks, BPF_F_EGRESS is clearer.
Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev>
next prev parent reply other threads:[~2026-06-25 3:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-18 18:20 [PATCH v2 bpf-next 0/2] bpf: bpf_redirect_peer egress redirection Jordan Rife
2026-06-18 18:20 ` [PATCH v2 bpf-next 1/2] bpf: Support BPF_F_EGRESS with bpf_redirect_peer Jordan Rife
2026-06-24 17:53 ` Daniel Borkmann
2026-06-24 21:58 ` Paul Chaignon
2026-06-25 3:37 ` Jiayuan Chen [this message]
2026-06-18 18:20 ` [PATCH v2 bpf-next 2/2] selftests/bpf: Add tests for bpf_redirect_peer with BPF_F_EGRESS Jordan Rife
2026-06-24 17:54 ` Daniel Borkmann
2026-06-24 21:59 ` Paul Chaignon
Reply instructions:
You may reply publicly 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=184b1d3c-a9cd-436a-b2b2-c5bac488859b@linux.dev \
--to=jiayuan.chen@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=jordan@jrife.io \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=paul.chaignon@gmail.com \
--cc=sdf@fomichev.me \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.