Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: > On Thu, Jun 22, 2023 at 3:13 PM Stanislav Fomichev <sdf@xxxxxxxxxx> wrote: >> >> We want to provide common sane interfaces/abstractions via kfuncs. >> That will make most BPF programs portable from mlx to brcm (for >> example) without doing a rewrite. >> We're also exposing raw (readonly) descriptors (via that get_ctx >> helper) to the users who know what to do with them. >> Most users don't know what to do with raw descriptors; > > Why do you think so? > Who are those users? > I see your proposal and thumbs up from onlookers. > afaict there are zero users for rx side hw hints too. We have customers in various sectors that want to use rx hw timestamps. There are several use cases especially in Telco where they use DPDK today and want to move to AF_XDP but they need to be able to benefit from the hw capabilities of the NICs they purchase. Not having access to hw offloads on rx and tx is a barrier to AF_XDP adoption. The most notable gaps in AF_XDP are checksum offloads and multi buffer support. >> the specs are >> not public; things can change depending on fw version/etc/etc. >> So the progs that touch raw descriptors are not the primary use-case. >> (that was the tl;dr for rx part, seems like it applies here?) >> >> Let's maybe discuss that mlx5 example? Are you proposing to do >> something along these lines? >> >> void mlx5e_devtx_submit(struct mlx5e_tx_wqe *wqe); >> void mlx5e_devtx_complete(struct mlx5_cqe64 *cqe); >> >> If yes, I'm missing how we define the common kfuncs in this case. The >> kfuncs need to have some common context. We're defining them with: >> bpf_devtx_<kfunc>(const struct devtx_frame *ctx); > > I'm looking at xdp_metadata and wondering who's using it. > I haven't seen a single bug report. > No bugs means no one is using it. There is zero chance that we managed > to implement it bug-free on the first try. Nobody is using xdp_metadata today, not because they don't want to, but because there was no consensus for how to use it. We have internal POCs that use xdp_metadata and are still trying to build the foundations needed to support it consistently across different hardware. Jesper Brouer proposed a way to describe xdp_metadata with BTF and it was rejected. The current plan to use kfuncs for xdp hints is the most recent attempt to find a solution. > So new tx side things look like a feature creep to me. > rx side is far from proven to be useful for anything. > Yet you want to add new things. We have telcos and large enterprises that either use DPDK or use proprietary solutions for getting traffic to user space. They want to move to AF_XDP but without at least RX and TX checksum offloads they are paying a CPU tax for using AF_XDP. One customer is also waiting for multi-buffer support to land before they can adopt AF_XDP. So, no it's not feature creep, it's a set of required features to reach minimum viable product to be able to move out of a lab and replace legacy in production.
