On 5/2/25 1:47 PM, Paolo Abeni wrote: > On 4/29/25 5:26 AM, Mina Almasry wrote: >> Augment dmabuf binding to be able to handle TX. Additional to all the RX >> binding, we also create tx_vec needed for the TX path. >> >> Provide API for sendmsg to be able to send dmabufs bound to this device: >> >> - Provide a new dmabuf_tx_cmsg which includes the dmabuf to send from. >> - MSG_ZEROCOPY with SCM_DEVMEM_DMABUF cmsg indicates send from dma-buf. >> >> Devmem is uncopyable, so piggyback off the existing MSG_ZEROCOPY >> implementation, while disabling instances where MSG_ZEROCOPY falls back >> to copying. >> >> We additionally pipe the binding down to the new >> zerocopy_fill_skb_from_devmem which fills a TX skb with net_iov netmems >> instead of the traditional page netmems. >> >> We also special case skb_frag_dma_map to return the dma-address of these >> dmabuf net_iovs instead of attempting to map pages. >> >> The TX path may release the dmabuf in a context where we cannot wait. >> This happens when the user unbinds a TX dmabuf while there are still >> references to its netmems in the TX path. In that case, the netmems will >> be put_netmem'd from a context where we can't unmap the dmabuf, Resolve >> this by making __net_devmem_dmabuf_binding_free schedule_work'd. >> >> Based on work by Stanislav Fomichev <sdf@xxxxxxxxxxx>. A lot of the meat >> of the implementation came from devmem TCP RFC v1[1], which included the >> TX path, but Stan did all the rebasing on top of netmem/net_iov. >> >> Cc: Stanislav Fomichev <sdf@xxxxxxxxxxx> >> Signed-off-by: Kaiyuan Zhang <kaiyuanz@xxxxxxxxxx> >> Signed-off-by: Mina Almasry <almasrymina@xxxxxxxxxx> >> Acked-by: Stanislav Fomichev <sdf@xxxxxxxxxxx> > > I'm sorry for the late feedback. A bunch of things I did not notice > before... The rest LGTM, and my feedback here ranges from nit to corner-cases, so we are probably better off with a follow-up than with a repost, other opinions welcome! /P
