* [PATCH net-next v4 15/15] mctp: Add MCTP overview document
2021-07-29 2:20 [PATCH net-next v4 00/15] Add Management Component Transport Protocol support Jeremy Kerr
@ 2021-07-29 2:20 ` Jeremy Kerr
2021-10-15 13:10 ` Eugene Syromiatnikov
2021-07-29 14:30 ` [PATCH net-next v4 00/15] Add Management Component Transport Protocol support patchwork-bot+netdevbpf
1 sibling, 1 reply; 4+ messages in thread
From: Jeremy Kerr @ 2021-07-29 2:20 UTC (permalink / raw)
To: netdev
Cc: Matt Johnston, Andrew Jeffery, Jakub Kicinski, David S. Miller,
linux-doc, Jonathan Corbet
This change adds a brief document about the sockets API provided for
sending and receiving MCTP messages from userspace.
This is roughly based on the OpenBMC design document, at:
https://github.com/openbmc/docs/blob/master/designs/mctp/mctp-kernel.md
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
---
v2:
- Controller -> component
---
Documentation/networking/index.rst | 1 +
Documentation/networking/mctp.rst | 213 +++++++++++++++++++++++++++++
MAINTAINERS | 1 +
3 files changed, 215 insertions(+)
create mode 100644 Documentation/networking/mctp.rst
diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index a91a2739f8ed..58bc8cd367c6 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -69,6 +69,7 @@ Contents:
l2tp
lapb-module
mac80211-injection
+ mctp
mpls-sysctl
mptcp-sysctl
multiqueue
diff --git a/Documentation/networking/mctp.rst b/Documentation/networking/mctp.rst
new file mode 100644
index 000000000000..6100cdc220f6
--- /dev/null
+++ b/Documentation/networking/mctp.rst
@@ -0,0 +1,213 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============================================
+Management Component Transport Protocol (MCTP)
+==============================================
+
+net/mctp/ contains protocol support for MCTP, as defined by DMTF standard
+DSP0236. Physical interface drivers ("bindings" in the specification) are
+provided in drivers/net/mctp/.
+
+The core code provides a socket-based interface to send and receive MCTP
+messages, through an AF_MCTP, SOCK_DGRAM socket.
+
+Structure: interfaces & networks
+================================
+
+The kernel models the local MCTP topology through two items: interfaces and
+networks.
+
+An interface (or "link") is an instance of an MCTP physical transport binding
+(as defined by DSP0236, section 3.2.47), likely connected to a specific hardware
+device. This is represented as a ``struct netdevice``.
+
+A network defines a unique address space for MCTP endpoints by endpoint-ID
+(described by DSP0236, section 3.2.31). A network has a user-visible identifier
+to allow references from userspace. Route definitions are specific to one
+network.
+
+Interfaces are associated with one network. A network may be associated with one
+or more interfaces.
+
+If multiple networks are present, each may contain endpoint IDs (EIDs) that are
+also present on other networks.
+
+Sockets API
+===========
+
+Protocol definitions
+--------------------
+
+MCTP uses ``AF_MCTP`` / ``PF_MCTP`` for the address- and protocol- families.
+Since MCTP is message-based, only ``SOCK_DGRAM`` sockets are supported.
+
+.. code-block:: C
+
+ int sd = socket(AF_MCTP, SOCK_DGRAM, 0);
+
+The only (current) value for the ``protocol`` argument is 0.
+
+As with all socket address families, source and destination addresses are
+specified with a ``sockaddr`` type, with a single-byte endpoint address:
+
+.. code-block:: C
+
+ typedef __u8 mctp_eid_t;
+
+ struct mctp_addr {
+ mctp_eid_t s_addr;
+ };
+
+ struct sockaddr_mctp {
+ unsigned short int smctp_family;
+ int smctp_network;
+ struct mctp_addr smctp_addr;
+ __u8 smctp_type;
+ __u8 smctp_tag;
+ };
+
+ #define MCTP_NET_ANY 0x0
+ #define MCTP_ADDR_ANY 0xff
+
+
+Syscall behaviour
+-----------------
+
+The following sections describe the MCTP-specific behaviours of the standard
+socket system calls. These behaviours have been chosen to map closely to the
+existing sockets APIs.
+
+``bind()`` : set local socket address
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Sockets that receive incoming request packets will bind to a local address,
+using the ``bind()`` syscall.
+
+.. code-block:: C
+
+ struct sockaddr_mctp addr;
+
+ addr.smctp_family = AF_MCTP;
+ addr.smctp_network = MCTP_NET_ANY;
+ addr.smctp_addr.s_addr = MCTP_ADDR_ANY;
+ addr.smctp_type = MCTP_TYPE_PLDM;
+ addr.smctp_tag = MCTP_TAG_OWNER;
+
+ int rc = bind(sd, (struct sockaddr *)&addr, sizeof(addr));
+
+This establishes the local address of the socket. Incoming MCTP messages that
+match the network, address, and message type will be received by this socket.
+The reference to 'incoming' is important here; a bound socket will only receive
+messages with the TO bit set, to indicate an incoming request message, rather
+than a response.
+
+The ``smctp_tag`` value will configure the tags accepted from the remote side of
+this socket. Given the above, the only valid value is ``MCTP_TAG_OWNER``, which
+will result in remotely "owned" tags being routed to this socket. Since
+``MCTP_TAG_OWNER`` is set, the 3 least-significant bits of ``smctp_tag`` are not
+used; callers must set them to zero.
+
+A ``smctp_network`` value of ``MCTP_NET_ANY`` will configure the socket to
+receive incoming packets from any locally-connected network. A specific network
+value will cause the socket to only receive incoming messages from that network.
+
+The ``smctp_addr`` field specifies a local address to bind to. A value of
+``MCTP_ADDR_ANY`` configures the socket to receive messages addressed to any
+local destination EID.
+
+The ``smctp_type`` field specifies which message types to receive. Only the
+lower 7 bits of the type is matched on incoming messages (ie., the
+most-significant IC bit is not part of the match). This results in the socket
+receiving packets with and without a message integrity check footer.
+
+``sendto()``, ``sendmsg()``, ``send()`` : transmit an MCTP message
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+An MCTP message is transmitted using one of the ``sendto()``, ``sendmsg()`` or
+``send()`` syscalls. Using ``sendto()`` as the primary example:
+
+.. code-block:: C
+
+ struct sockaddr_mctp addr;
+ char buf[14];
+ ssize_t len;
+
+ /* set message destination */
+ addr.smctp_family = AF_MCTP;
+ addr.smctp_network = 0;
+ addr.smctp_addr.s_addr = 8;
+ addr.smctp_tag = MCTP_TAG_OWNER;
+ addr.smctp_type = MCTP_TYPE_ECHO;
+
+ /* arbitrary message to send, with message-type header */
+ buf[0] = MCTP_TYPE_ECHO;
+ memcpy(buf + 1, "hello, world!", sizeof(buf) - 1);
+
+ len = sendto(sd, buf, sizeof(buf), 0,
+ (struct sockaddr_mctp *)&addr, sizeof(addr));
+
+The network and address fields of ``addr`` define the remote address to send to.
+If ``smctp_tag`` has the ``MCTP_TAG_OWNER``, the kernel will ignore any bits set
+in ``MCTP_TAG_VALUE``, and generate a tag value suitable for the destination
+EID. If ``MCTP_TAG_OWNER`` is not set, the message will be sent with the tag
+value as specified. If a tag value cannot be allocated, the system call will
+report an errno of ``EAGAIN``.
+
+The application must provide the message type byte as the first byte of the
+message buffer passed to ``sendto()``. If a message integrity check is to be
+included in the transmitted message, it must also be provided in the message
+buffer, and the most-significant bit of the message type byte must be 1.
+
+The ``sendmsg()`` system call allows a more compact argument interface, and the
+message buffer to be specified as a scatter-gather list. At present no ancillary
+message types (used for the ``msg_control`` data passed to ``sendmsg()``) are
+defined.
+
+Transmitting a message on an unconnected socket with ``MCTP_TAG_OWNER``
+specified will cause an allocation of a tag, if no valid tag is already
+allocated for that destination. The (destination-eid,tag) tuple acts as an
+implicit local socket address, to allow the socket to receive responses to this
+outgoing message. If any previous allocation has been performed (to for a
+different remote EID), that allocation is lost.
+
+Sockets will only receive responses to requests they have sent (with TO=1) and
+may only respond (with TO=0) to requests they have received.
+
+``recvfrom()``, ``recvmsg()``, ``recv()`` : receive an MCTP message
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+An MCTP message can be received by an application using one of the
+``recvfrom()``, ``recvmsg()``, or ``recv()`` system calls. Using ``recvfrom()``
+as the primary example:
+
+.. code-block:: C
+
+ struct sockaddr_mctp addr;
+ socklen_t addrlen;
+ char buf[14];
+ ssize_t len;
+
+ addrlen = sizeof(addr);
+
+ len = recvfrom(sd, buf, sizeof(buf), 0,
+ (struct sockaddr_mctp *)&addr, &addrlen);
+
+ /* We can expect addr to describe an MCTP address */
+ assert(addrlen >= sizeof(buf));
+ assert(addr.smctp_family == AF_MCTP);
+
+ printf("received %zd bytes from remote EID %d\n", rc, addr.smctp_addr);
+
+The address argument to ``recvfrom`` and ``recvmsg`` is populated with the
+remote address of the incoming message, including tag value (this will be needed
+in order to reply to the message).
+
+The first byte of the message buffer will contain the message type byte. If an
+integrity check follows the message, it will be included in the received buffer.
+
+The ``recv()`` system call behaves in a similar way, but does not provide a
+remote address to the application. Therefore, these are only useful if the
+remote address is already known, or the message does not require a reply.
+
+Like the send calls, sockets will only receive responses to requests they have
+sent (TO=1) and may only respond (TO=0) to requests they have received.
diff --git a/MAINTAINERS b/MAINTAINERS
index 4ca73465e690..73beb91891ee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11037,6 +11037,7 @@ M: Jeremy Kerr <jk@codeconstruct.com.au>
M: Matt Johnston <matt@codeconstruct.com.au>
L: netdev@vger.kernel.org
S: Maintained
+F: Documentation/networking/mctp.rst
F: drivers/net/mctp/
F: include/net/mctp.h
F: include/net/mctpdevice.h
--
2.30.2
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH net-next v4 00/15] Add Management Component Transport Protocol support
2021-07-29 2:20 [PATCH net-next v4 00/15] Add Management Component Transport Protocol support Jeremy Kerr
2021-07-29 2:20 ` [PATCH net-next v4 15/15] mctp: Add MCTP overview document Jeremy Kerr
@ 2021-07-29 14:30 ` patchwork-bot+netdevbpf
1 sibling, 0 replies; 4+ messages in thread
From: patchwork-bot+netdevbpf @ 2021-07-29 14:30 UTC (permalink / raw)
To: Jeremy Kerr
Cc: netdev, matt, andrew, kuba, davem, linux-doc, corbet, paul,
stephen.smalley.work, eparis, selinux
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Thu, 29 Jul 2021 10:20:38 +0800 you wrote:
> This series adds core MCTP support to the kernel. From the Kconfig
> description:
>
> Management Component Transport Protocol (MCTP) is an in-system
> protocol for communicating between management controllers and
> their managed devices (peripherals, host processors, etc.). The
> protocol is defined by DMTF specification DSP0236.
>
> [...]
Here is the summary with links:
- [net-next,v4,01/15] mctp: Add MCTP base
https://git.kernel.org/netdev/net-next/c/bc49d8169aa7
- [net-next,v4,02/15] mctp: Add base socket/protocol definitions
https://git.kernel.org/netdev/net-next/c/8f601a1e4f8c
- [net-next,v4,03/15] mctp: Add base packet definitions
https://git.kernel.org/netdev/net-next/c/2c8e2e9aec79
- [net-next,v4,04/15] mctp: Add sockaddr_mctp to uapi
https://git.kernel.org/netdev/net-next/c/60fc63981693
- [net-next,v4,05/15] mctp: Add initial driver infrastructure
https://git.kernel.org/netdev/net-next/c/4b2e69305cbb
- [net-next,v4,06/15] mctp: Add device handling and netlink interface
https://git.kernel.org/netdev/net-next/c/583be982d934
- [net-next,v4,07/15] mctp: Add initial routing framework
https://git.kernel.org/netdev/net-next/c/889b7da23abf
- [net-next,v4,08/15] mctp: Add netlink route management
https://git.kernel.org/netdev/net-next/c/06d2f4c583a7
- [net-next,v4,09/15] mctp: Add neighbour implementation
https://git.kernel.org/netdev/net-next/c/4d8b9319282a
- [net-next,v4,10/15] mctp: Add neighbour netlink interface
https://git.kernel.org/netdev/net-next/c/831119f88781
- [net-next,v4,11/15] mctp: Populate socket implementation
https://git.kernel.org/netdev/net-next/c/833ef3b91de6
- [net-next,v4,12/15] mctp: Implement message fragmentation & reassembly
https://git.kernel.org/netdev/net-next/c/4a992bbd3650
- [net-next,v4,13/15] mctp: Add dest neighbour lladdr to route output
https://git.kernel.org/netdev/net-next/c/26ab3fcaf235
- [net-next,v4,14/15] mctp: Allow per-netns default networks
https://git.kernel.org/netdev/net-next/c/03f2bbc4ee57
- [net-next,v4,15/15] mctp: Add MCTP overview document
https://git.kernel.org/netdev/net-next/c/6a2d98b18900
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply [flat|nested] 4+ messages in thread