On Fri, Jun 23, 2023 at 3:16 AM Maryam Tahhan <mtahhan@xxxxxxxxxx> wrote: > > On 23/06/2023 03:35, Alexei Starovoitov wrote: > > 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. > > > >> 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. > > 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. > > > > Hi folks > > We in CNDP (https://github.com/CloudNativeDataPlane/cndp) have been with TCP stack in user space over af_xdp... > looking to use xdp_metadata to relay receive side offloads from the NIC > to our AF_XDP applications. We see this is a key feature that is > essential for the viability of AF_XDP in the real world. We would love > to see something adopted for the TX side alongside what's on the RX > side. We don't want to waste cycles do everything in software when the > NIC HW supports many features that we need. Please specify "many features". If that means HW TSO to accelerate your TCP in user space, then sorry, but no.
