Daniel Borkmann <daniel@xxxxxxxxxxxxx> writes: >> 2). We can't redirect ingress packet to ifb with bpf >> By trying to analyze if it is possible to redirect the ingress packet to >> ifb with a bpf program, we find that the ifb device is not supported by >> bpf redirect yet. > > You actually can: Just let BPF program return TC_ACT_UNSPEC for this > case and then add a matchall with higher prio (so it runs after bpf) > that contains an action with mirred egress redirect that pushes to ifb > dev - there is no change needed. I wasn't aware that BPF couldn't redirect directly to an IFB; any reason why we shouldn't merge this patch in any case? >> This patch tries to resolve it by supporting redirecting to ifb with bpf >> program. >> >> Ingress bandwidth limit is useful in some scenarios, for example, for the >> TCP-based service, there may be lots of clients connecting it, so it is >> not wise to limit the clients' egress. After limiting the server-side's >> ingress, it will lower the send rate of the client by lowering the TCP >> cwnd if the ingress bandwidth limit is reached. If we don't limit it, >> the clients will continue sending requests at a high rate. > > Adding artificial queueing for the inbound traffic, aren't you worried > about DoS'ing your node? Just as an aside, the ingress filter -> ifb -> qdisc on the ifb interface does work surprisingly well, and we've been using that over in OpenWrt land for years[0]. It does have some overhead associated with it, but I wouldn't expect it to be a source of self-DoS in itself (assuming well-behaved TCP traffic). -Toke [0] https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm
