Re: [PATCH v5 bpf-next 00/11] net: Add support for XDP in egress path

["Toke Høiland-Jørgensen" <toke@redhat.com>]

David Ahern <dsahern@kernel.org> writes:

> From: David Ahern <dahern@digitalocean.com>
>
> This series adds support for XDP in the egress path by introducing
> a new XDP attachment type, BPF_XDP_EGRESS, and adding a UAPI to
> if_link.h for attaching the program to a netdevice and reporting
> the program. This allows bpf programs to be run on redirected xdp
> frames with the context showing the Tx device.
>
> This is a missing primitive for XDP allowing solutions to build small,
> targeted programs properly distributed in the networking path allowing,
> for example, an egress firewall/ACL/traffic verification or packet
> manipulation based on data specific to the egress device.
>
> Nothing about running a program in the Tx path requires driver specific
> resources like the Rx path has. Thus, programs can be run in core
> code and attached to the net_device struct similar to skb mode. The
> egress attach is done using the new XDP_FLAGS_EGRESS_MODE flag, and
> is reported by the kernel using the XDP_ATTACHED_EGRESS_CORE attach
> flag with IFLA_XDP_EGRESS_PROG_ID making the api similar to existing
> APIs for XDP.
>
> The egress program is run in bq_xmit_all before invoking ndo_xdp_xmit.
> This is similar to cls_bpf programs which run before the call to
> ndo_dev_xmit. Together the 2 locations cover all packets about to be
> sent to a device for Tx.
>
> xdp egress programs are not run on skbs, so a cls-bpf counterpart
> should also be attached to the device to cover all packets -
> xdp_frames and skbs.
>
> v5:
> - rebased to top of bpf-next
> - dropped skb path; cls-bpf provides an option for the same functionality
>   without having to take a performance hit (e.g., disabling GSO).

I don't like this. I makes the egress hook asymmetrical with the ingress
hook (ingress hook sees all traffic, egress only some of it). If the
performance hit of disabling GSO is the concern, maybe it's better to
wait until we figure out how to deal with that (presumably by
multi-buffer XDP)?

-Toke