From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp1.cs.Stanford.EDU (smtp1.cs.stanford.edu [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BF1011EF39F for ; Thu, 24 Jul 2025 18:43:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=171.64.64.25 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753382625; cv=none; b=P/ss4mjzaqMaatLCOimlwHqMavfEr2aL38MjDyDHXqm8vKbz4hdCAWoOdYqUjYcZVlMFvN/fQQyuPItAn8iWH9O13DROcSf16Zns2c/9gCBAfr1ZzjDf25YY0QAgcsgHp0vAFiaP4YU0/wYmTlHj+1GuJ2WSF2ra79zTsyMMXys= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753382625; c=relaxed/simple; bh=1c0KRKfpLYsPSfmgoKBb7lmAryKvkuxu2sSo9ErHEX8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tS6roerXz7cPeDqJvGn/Jl+uPrzbcVNVRH1dG6FWmiKTdhXeDBP61LHEV9Bh1l+/Z3DWBEbay/NoEVZpKoh13hOGVCsMn3dAO+NNkX+4CWzmEkgDxsz1RcCjL3f1mYliE8eeps7F3CeKRT8VgqEWTLL2WhMpLKaPs74GJ0za6L8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cs.stanford.edu; spf=pass smtp.mailfrom=cs.stanford.edu; dkim=pass (2048-bit key) header.d=cs.stanford.edu header.i=@cs.stanford.edu header.b=Ma24+sll; arc=none smtp.client-ip=171.64.64.25 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cs.stanford.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cs.stanford.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cs.stanford.edu header.i=@cs.stanford.edu header.b="Ma24+sll" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.stanford.edu; s=cs2308; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To: Content-Type:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kHuGjZ3i+j5L8sd6aGObLkpzjhQFiAffrM0kZL8v7OY=; t=1753382623; x=1754246623; b=Ma24+sll+ljsCDwwsgzdMELerlvd9sWvA2uYGRaeC06xF21t5tG2f7u3rMAOSmBKkm8O3sAeCnr CVCgu91k6uGw20Qu4pIuuYZzoG1+GKrFWHDdIZrP2H6wUO5aJC6JXHz9LTsg4wFOMpfR7X40v115I /mv1yoVL+PFZ0tVfljDBMfwDyfmE9aAzgrPP+zvwYsh2Zb8LyL0yl/W3e6PkSs9sT1Fic0CV3KMTP q+8xYZRAls9KYPjdgvc4vSgLyrVLlbC2i6yUzfpw0d4Yzpe/iIASfOgIO1M6qpE/0tJ1RUIQtq473 JRoHPLIu2K6T5VS/KDP8yiSMCO/i1RXnZLTQ==; Received: from 70-228-78-207.lightspeed.sntcca.sbcglobal.net ([70.228.78.207]:55641 helo=localhost.localdomain) by smtp1.cs.Stanford.EDU with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uf0sT-0006eP-SF; Thu, 24 Jul 2025 11:41:14 -0700 From: John Ousterhout To: netdev@vger.kernel.org Cc: pabeni@redhat.com, edumazet@google.com, horms@kernel.org, kuba@kernel.org, John Ousterhout Subject: [PATCH net-next v12 01/15] net: homa: define user-visible API for Homa Date: Thu, 24 Jul 2025 11:40:34 -0700 Message-ID: <20250724184050.3130-2-ouster@cs.stanford.edu> X-Mailer: git-send-email 2.45.1 In-Reply-To: <20250724184050.3130-1-ouster@cs.stanford.edu> References: <20250724184050.3130-1-ouster@cs.stanford.edu> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: -1.0 X-Scan-Signature: 6b558d507b279d87cf03e63f8dc9a39b Note: for man pages, see the Homa Wiki at: https://homa-transport.atlassian.net/wiki/spaces/HOMA/overview Signed-off-by: John Ousterhout --- Changes for v11: * Add explicit padding to struct homa_recvmsg_args to fix problems compiling on 32-bit machines. Changes for v9: * Eliminate use of _Static_assert * Remove declarations related to now-defunct homa_api.c Changes for v7: * Add HOMA_SENDMSG_NONBLOCKING flag for sendmsg * API changes for new mechanism for waiting for incoming messages * Add setsockopt SO_HOMA_SERVER (enable incoming requests) * Use u64 and __u64 properly --- MAINTAINERS | 7 ++ include/uapi/linux/homa.h | 158 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 165 insertions(+) create mode 100644 include/uapi/linux/homa.h diff --git a/MAINTAINERS b/MAINTAINERS index c3f7fbd0d67a..d6665c532f7e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11015,6 +11015,13 @@ F: lib/test_hmm* F: mm/hmm* F: tools/testing/selftests/mm/*hmm* +HOMA PROTOCOL +M: John Ousterhout +S: Maintained +B: mailto:ouster@cs.stanford.edu +F: include/uapi/linux/homa.h +F: net/homa/ + HONEYWELL HSC030PA PRESSURE SENSOR SERIES IIO DRIVER M: Petre Rodan L: linux-iio@vger.kernel.org diff --git a/include/uapi/linux/homa.h b/include/uapi/linux/homa.h new file mode 100644 index 000000000000..adf1dcc16906 --- /dev/null +++ b/include/uapi/linux/homa.h @@ -0,0 +1,158 @@ +/* SPDX-License-Identifier: BSD-2-Clause */ + +/* This file defines the kernel call interface for the Homa + * transport protocol. + */ + +#ifndef _UAPI_LINUX_HOMA_H +#define _UAPI_LINUX_HOMA_H + +#include +#ifndef __KERNEL__ +#include +#include +#endif + +/* IANA-assigned Internet Protocol number for Homa. */ +#define IPPROTO_HOMA 146 + +/** + * define HOMA_MAX_MESSAGE_LENGTH - Maximum bytes of payload in a Homa + * request or response message. + */ +#define HOMA_MAX_MESSAGE_LENGTH 1000000 + +/** + * define HOMA_BPAGE_SIZE - Number of bytes in pages used for receive + * buffers. Must be power of two. + */ +#define HOMA_BPAGE_SIZE (1 << HOMA_BPAGE_SHIFT) +#define HOMA_BPAGE_SHIFT 16 + +/** + * define HOMA_MAX_BPAGES - The largest number of bpages that will be required + * to store an incoming message. + */ +#define HOMA_MAX_BPAGES ((HOMA_MAX_MESSAGE_LENGTH + HOMA_BPAGE_SIZE - 1) >> \ + HOMA_BPAGE_SHIFT) + +/** + * define HOMA_MIN_DEFAULT_PORT - The 16 bit port space is divided into + * two nonoverlapping regions. Ports 1-32767 are reserved exclusively + * for well-defined server ports. The remaining ports are used for client + * ports; these are allocated automatically by Homa. Port 0 is reserved. + */ +#define HOMA_MIN_DEFAULT_PORT 0x8000 + +/** + * struct homa_sendmsg_args - Provides information needed by Homa's + * sendmsg; passed to sendmsg using the msg_control field. + */ +struct homa_sendmsg_args { + /** + * @id: (in/out) An initial value of 0 means a new request is + * being sent; nonzero means the message is a reply to the given + * id. If the message is a request, then the value is modified to + * hold the id of the new RPC. + */ + __u64 id; + + /** + * @completion_cookie: (in) Used only for request messages; will be + * returned by recvmsg when the RPC completes. Typically used to + * locate app-specific info about the RPC. + */ + __u64 completion_cookie; + + /** + * @flags: (in) OR-ed combination of bits that control the operation. + * See below for values. + */ + __u32 flags; + + /** @reserved: Not currently used, must be 0. */ + __u32 reserved; +}; + +/* Flag bits for homa_sendmsg_args.flags (see man page for documentation): + */ +#define HOMA_SENDMSG_PRIVATE 0x01 +#define HOMA_SENDMSG_VALID_FLAGS 0x01 + +/** + * struct homa_recvmsg_args - Provides information needed by Homa's + * recvmsg; passed to recvmsg using the msg_control field. + */ +struct homa_recvmsg_args { + /** + * @id: (in/out) Initial value is 0 to wait for any shared RPC; + * nonzero means wait for that specific (private) RPC. Returns + * the id of the RPC received. + */ + __u64 id; + + /** + * @completion_cookie: (out) If the incoming message is a response, + * this will return the completion cookie specified when the + * request was sent. For requests this will always be zero. + */ + __u64 completion_cookie; + + /** + * @num_bpages: (in/out) Number of valid entries in @bpage_offsets. + * Passes in bpages from previous messages that can now be + * recycled; returns bpages from the new message. + */ + __u32 num_bpages; + + /** @reserved: Not currently used, must be 0. */ + __u32 reserved; + + /** + * @bpage_offsets: (in/out) Each entry is an offset into the buffer + * region for the socket pool. When returned from recvmsg, the + * offsets indicate where fragments of the new message are stored. All + * entries but the last refer to full buffer pages (HOMA_BPAGE_SIZE + * bytes) and are bpage-aligned. The last entry may refer to a bpage + * fragment and is not necessarily aligned. The application now owns + * these bpages and must eventually return them to Homa, using + * bpage_offsets in a future recvmsg invocation. + */ + __u32 bpage_offsets[HOMA_MAX_BPAGES]; +}; + +/** define SO_HOMA_RCVBUF: setsockopt option for specifying buffer region. */ +#define SO_HOMA_RCVBUF 10 + +/** + * define SO_HOMA_SERVER: setsockopt option for specifying whether a + * socket will act as server. + */ +#define SO_HOMA_SERVER 11 + +/** struct homa_rcvbuf_args - setsockopt argument for SO_HOMA_RCVBUF. */ +struct homa_rcvbuf_args { + /** @start: Address of first byte of buffer region in user space. */ + __u64 start; + + /** @length: Total number of bytes available at @start. */ + size_t length; +}; + +/* Meanings of the bits in Homa's flag word, which can be set using + * "sysctl /net/homa/flags". + */ + +/** + * define HOMA_FLAG_DONT_THROTTLE - disable the output throttling mechanism + * (always send all packets immediately). + */ +#define HOMA_FLAG_DONT_THROTTLE 2 + +/* I/O control calls on Homa sockets. These are mapped into the + * SIOCPROTOPRIVATE range of 0x89e0 through 0x89ef. + */ + +#define HOMAIOCFREEZE _IO(0x89, 0xef) + +#endif /* _UAPI_LINUX_HOMA_H */ -- 2.43.0