Lines Matching +full:application +full:- +full:specific
1 .. SPDX-License-Identifier: GPL-2.0
11 The core code provides a socket-based interface to send and receive MCTP
21 (as defined by DSP0236, section 3.2.47), likely connected to a specific hardware
24 A network defines a unique address space for MCTP endpoints by endpoint-ID
25 (described by DSP0236, section 3.2.31). A network has a user-visible identifier
26 to allow references from userspace. Route definitions are specific to one
39 --------------------
41 MCTP uses ``AF_MCTP`` / ``PF_MCTP`` for the address- and protocol- families.
42 Since MCTP is message-based, only ``SOCK_DGRAM`` sockets are supported.
44 .. code-block:: C
51 specified with a ``sockaddr`` type, with a single-byte endpoint address:
53 .. code-block:: C
74 -----------------
76 The following sections describe the MCTP-specific behaviours of the standard
86 .. code-block:: C
107 ``MCTP_TAG_OWNER`` is set, the 3 least-significant bits of ``smctp_tag`` are not
111 receive incoming packets from any locally-connected network. A specific network
120 most-significant IC bit is not part of the match). This results in the socket
129 .. code-block:: C
142 /* arbitrary message to send, with message-type header */
144 memcpy(buf + 1, "hello, world!", sizeof(buf) - 1);
156 The application must provide the message type byte as the first byte of the
159 buffer, and the most-significant bit of the message type byte must be 1.
162 message buffer to be specified as a scatter-gather list. At present no ancillary
168 allocated for that destination. The (destination-eid,tag) tuple acts as an
179 An MCTP message can be received by an application using one of the
183 .. code-block:: C
209 remote address to the application. Therefore, these are only useful if the
220 allocating a per-message tag at ``sendmsg()`` time.
230 .. code-block:: C
238 ``SIOCMCTPALLOCTAG`` allocates a tag for a specific peer, which an application
239 can use in future ``sendmsg()`` calls. The application populates the
245 - ``MCTP_TAG_OWNER``: it only makes sense to allocate tags if you're the tag
248 - ``MCTP_TAG_PREALLOC``: to indicate to ``sendmsg()`` that this is a
251 - ... and the actual tag value, within the least-significant three bits
254 The tag value should be used as-is for the ``smctp_tag`` member of ``struct
271 -> mctp_local_output()
273 -> rt->output() (== mctp_route_output)
274 -> dev_queue_xmit()
279 -> mctp_local_output()
280 -> mctp_do_fragment_route()
281 : creates packet-sized skbs. For each new skb:
282 -> rt->output() (== mctp_route_output)
283 -> dev_queue_xmit()
285 3. remote TX to local endpoint, single-packet message::
289 -> rt->output() (== mctp_route_input)
291 -> sock_queue_rcv_skb()
293 4. remote TX to local endpoint, multiple-packet message::
297 -> rt->output() (== mctp_route_input)
299 : stores skb in struct sk_key->reasm_head
303 -> rt->output() (== mctp_route_input)
305 : finds existing reassembly in sk_key->reasm_head
307 -> sock_queue_rcv_skb()
310 -------------
314 - a skb: during route output, stored in ``skb->cb``.
316 - netns and sock lists.
319 reference to the dev (set through ``key->dev``, counted through
320 ``dev->key_count``). Multiple keys can reference the device.