All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bagas Sanjaya <bagasdotme@gmail.com>
To: Mina Almasry <almasrymina@google.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, kvm@vger.kernel.org,
	virtualization@lists.linux.dev, linux-kselftest@vger.kernel.org
Cc: "Donald Hunter" <donald.hunter@gmail.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Simon Horman" <horms@kernel.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Andrew Lunn" <andrew+netdev@lunn.ch>,
	"Jeroen de Borst" <jeroendb@google.com>,
	"Harshitha Ramamurthy" <hramamurthy@google.com>,
	"Kuniyuki Iwashima" <kuniyu@amazon.com>,
	"Willem de Bruijn" <willemb@google.com>,
	"David Ahern" <dsahern@kernel.org>,
	"Neal Cardwell" <ncardwell@google.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
	"Eugenio Pérez" <eperezma@redhat.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Stefano Garzarella" <sgarzare@redhat.com>,
	"Shuah Khan" <shuah@kernel.org>,
	sdf@fomichev.me, asml.silence@gmail.com, dw@davidwei.uk,
	"Jamal Hadi Salim" <jhs@mojatatu.com>,
	"Victor Nogueira" <victor@mojatatu.com>,
	"Pedro Tammela" <pctammela@mojatatu.com>,
	"Samiullah Khawaja" <skhawaja@google.com>
Subject: Re: [PATCH net-next v6 4/8] net: add devmem TCP TX documentation
Date: Thu, 27 Feb 2025 14:59:57 +0700	[thread overview]
Message-ID: <Z8AbfZg98HS_QQjb@archie.me> (raw)
In-Reply-To: <20250227041209.2031104-5-almasrymina@google.com>

[-- Attachment #1: Type: text/plain, Size: 6056 bytes --]

On Thu, Feb 27, 2025 at 04:12:05AM +0000, Mina Almasry wrote:
> diff --git a/Documentation/networking/devmem.rst b/Documentation/networking/devmem.rst
> index d95363645331..1c476522d6f5 100644
> --- a/Documentation/networking/devmem.rst
> +++ b/Documentation/networking/devmem.rst
> @@ -62,15 +62,15 @@ More Info
>      https://lore.kernel.org/netdev/20240831004313.3713467-1-almasrymina@google.com/
>  
>  
> -Interface
> -=========
> +RX Interface
> +============
>  
>  
>  Example
>  -------
>  
> -tools/testing/selftests/net/ncdevmem.c:do_server shows an example of setting up
> -the RX path of this API.
> +./tools/testing/selftests/drivers/net/hw/ncdevmem:do_server shows an example of
> +setting up the RX path of this API.
>  
>  
>  NIC Setup
> @@ -235,6 +235,148 @@ can be less than the tokens provided by the user in case of:
>  (a) an internal kernel leak bug.
>  (b) the user passed more than 1024 frags.
>  
> +TX Interface
> +============
> +
> +
> +Example
> +-------
> +
> +./tools/testing/selftests/drivers/net/hw/ncdevmem:do_client shows an example of
> +setting up the TX path of this API.
> +
> +
> +NIC Setup
> +---------
> +
> +The user must bind a TX dmabuf to a given NIC using the netlink API::
> +
> +        struct netdev_bind_tx_req *req = NULL;
> +        struct netdev_bind_tx_rsp *rsp = NULL;
> +        struct ynl_error yerr;
> +
> +        *ys = ynl_sock_create(&ynl_netdev_family, &yerr);
> +
> +        req = netdev_bind_tx_req_alloc();
> +        netdev_bind_tx_req_set_ifindex(req, ifindex);
> +        netdev_bind_tx_req_set_fd(req, dmabuf_fd);
> +
> +        rsp = netdev_bind_tx(*ys, req);
> +
> +        tx_dmabuf_id = rsp->id;
> +
> +
> +The netlink API returns a dmabuf_id: a unique ID that refers to this dmabuf
> +that has been bound.
> +
> +The user can unbind the dmabuf from the netdevice by closing the netlink socket
> +that established the binding. We do this so that the binding is automatically
> +unbound even if the userspace process crashes.
> +
> +Note that any reasonably well-behaved dmabuf from any exporter should work with
> +devmem TCP, even if the dmabuf is not actually backed by devmem. An example of
> +this is udmabuf, which wraps user memory (non-devmem) in a dmabuf.
> +
> +Socket Setup
> +------------
> +
> +The user application must use MSG_ZEROCOPY flag when sending devmem TCP. Devmem
> +cannot be copied by the kernel, so the semantics of the devmem TX are similar
> +to the semantics of MSG_ZEROCOPY::
> +
> +	setsockopt(socket_fd, SOL_SOCKET, SO_ZEROCOPY, &opt, sizeof(opt));
> +
> +It is also recommended that the user binds the TX socket to the same interface
> +the dma-buf has been bound to via SO_BINDTODEVICE::
> +
> +	setsockopt(socket_fd, SOL_SOCKET, SO_BINDTODEVICE, ifname, strlen(ifname) + 1);
> +
> +
> +Sending data
> +------------
> +
> +Devmem data is sent using the SCM_DEVMEM_DMABUF cmsg.
> +
> +The user should create a msghdr where,
> +
> +* iov_base is set to the offset into the dmabuf to start sending from
> +* iov_len is set to the number of bytes to be sent from the dmabuf
> +
> +The user passes the dma-buf id to send from via the dmabuf_tx_cmsg.dmabuf_id.
> +
> +The example below sends 1024 bytes from offset 100 into the dmabuf, and 2048
> +from offset 2000 into the dmabuf. The dmabuf to send from is tx_dmabuf_id::
> +
> +       char ctrl_data[CMSG_SPACE(sizeof(struct dmabuf_tx_cmsg))];
> +       struct dmabuf_tx_cmsg ddmabuf;
> +       struct msghdr msg = {};
> +       struct cmsghdr *cmsg;
> +       struct iovec iov[2];
> +
> +       iov[0].iov_base = (void*)100;
> +       iov[0].iov_len = 1024;
> +       iov[1].iov_base = (void*)2000;
> +       iov[1].iov_len = 2048;
> +
> +       msg.msg_iov = iov;
> +       msg.msg_iovlen = 2;
> +
> +       msg.msg_control = ctrl_data;
> +       msg.msg_controllen = sizeof(ctrl_data);
> +
> +       cmsg = CMSG_FIRSTHDR(&msg);
> +       cmsg->cmsg_level = SOL_SOCKET;
> +       cmsg->cmsg_type = SCM_DEVMEM_DMABUF;
> +       cmsg->cmsg_len = CMSG_LEN(sizeof(struct dmabuf_tx_cmsg));
> +
> +       ddmabuf.dmabuf_id = tx_dmabuf_id;
> +
> +       *((struct dmabuf_tx_cmsg *)CMSG_DATA(cmsg)) = ddmabuf;
> +
> +       sendmsg(socket_fd, &msg, MSG_ZEROCOPY);
> +
> +
> +Reusing TX dmabufs
> +------------------
> +
> +Similar to MSG_ZEROCOPY with regular memory, the user should not modify the
> +contents of the dma-buf while a send operation is in progress. This is because
> +the kernel does not keep a copy of the dmabuf contents. Instead, the kernel
> +will pin and send data from the buffer available to the userspace.
> +
> +Just as in MSG_ZEROCOPY, the kernel notifies the userspace of send completions
> +using MSG_ERRQUEUE::
> +
> +        int64_t tstop = gettimeofday_ms() + waittime_ms;
> +        char control[CMSG_SPACE(100)] = {};
> +        struct sock_extended_err *serr;
> +        struct msghdr msg = {};
> +        struct cmsghdr *cm;
> +        int retries = 10;
> +        __u32 hi, lo;
> +
> +        msg.msg_control = control;
> +        msg.msg_controllen = sizeof(control);
> +
> +        while (gettimeofday_ms() < tstop) {
> +                if (!do_poll(fd)) continue;
> +
> +                ret = recvmsg(fd, &msg, MSG_ERRQUEUE);
> +
> +                for (cm = CMSG_FIRSTHDR(&msg); cm; cm = CMSG_NXTHDR(&msg, cm)) {
> +                        serr = (void *)CMSG_DATA(cm);
> +
> +                        hi = serr->ee_data;
> +                        lo = serr->ee_info;
> +
> +                        fprintf(stdout, "tx complete [%d,%d]\n", lo, hi);
> +                }
> +        }
> +
> +After the associated sendmsg has been completed, the dmabuf can be reused by
> +the userspace.
> +
> +
>  Implementation & Caveats
>  ========================
>  

Looks good, thanks!

Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2025-02-27  8:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-27  4:12 [PATCH net-next v6 0/8] Device memory TCP TX Mina Almasry
2025-02-27  4:12 ` [PATCH net-next v6 1/8] net: add get_netmem/put_netmem support Mina Almasry
2025-03-01  0:38   ` Jakub Kicinski
2025-03-01  1:29     ` Mina Almasry
2025-03-04  0:20       ` Jakub Kicinski
2025-03-05  1:39         ` Mina Almasry
2025-03-06 21:40           ` Jakub Kicinski
2025-03-06 22:44             ` Mina Almasry
2025-03-06 23:02               ` Jakub Kicinski
2025-03-06 23:22                 ` Willem de Bruijn
2025-02-27  4:12 ` [PATCH net-next v6 2/8] net: devmem: TCP tx netlink api Mina Almasry
2025-02-27  4:12 ` [PATCH net-next v6 3/8] net: devmem: Implement TX path Mina Almasry
2025-03-04 20:44   ` Pranjal Shrivastava
2025-02-27  4:12 ` [PATCH net-next v6 4/8] net: add devmem TCP TX documentation Mina Almasry
2025-02-27  7:59   ` Bagas Sanjaya [this message]
2025-02-27  4:12 ` [PATCH net-next v6 5/8] net: enable driver support for netmem TX Mina Almasry
2025-02-27  4:12 ` [PATCH net-next v6 6/8] gve: add netmem TX support to GVE DQO-RDA mode Mina Almasry
2025-02-27  4:12 ` [PATCH net-next v6 7/8] net: check for driver support in netmem TX Mina Almasry
2025-03-01  0:43   ` Jakub Kicinski
2025-03-01  1:53     ` Mina Almasry
2025-03-04  0:29       ` Jakub Kicinski
2025-03-04  3:53         ` Mina Almasry
2025-03-05  0:17           ` Jakub Kicinski
2025-02-27  4:12 ` [PATCH net-next v6 8/8] selftests: ncdevmem: Implement devmem TCP TX Mina Almasry
2025-02-28 14:25 ` [PATCH net-next v6 0/8] Device memory " Lei Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z8AbfZg98HS_QQjb@archie.me \
    --to=bagasdotme@gmail.com \
    --cc=almasrymina@google.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=asml.silence@gmail.com \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=donald.hunter@gmail.com \
    --cc=dsahern@kernel.org \
    --cc=dw@davidwei.uk \
    --cc=edumazet@google.com \
    --cc=eperezma@redhat.com \
    --cc=horms@kernel.org \
    --cc=hramamurthy@google.com \
    --cc=jasowang@redhat.com \
    --cc=jeroendb@google.com \
    --cc=jhs@mojatatu.com \
    --cc=kuba@kernel.org \
    --cc=kuniyu@amazon.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pctammela@mojatatu.com \
    --cc=sdf@fomichev.me \
    --cc=sgarzare@redhat.com \
    --cc=shuah@kernel.org \
    --cc=skhawaja@google.com \
    --cc=stefanha@redhat.com \
    --cc=victor@mojatatu.com \
    --cc=virtualization@lists.linux.dev \
    --cc=willemb@google.com \
    --cc=xuanzhuo@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.