netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matt Johnston <matt@codeconstruct.com.au>
To: "David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org
Cc: Jeremy Kerr <jk@codeconstruct.com.au>
Subject: [PATCH net-next 08/10] doc/mctp: Add a little detail about kernel internals
Date: Wed, 29 Sep 2021 15:26:12 +0800	[thread overview]
Message-ID: <20210929072614.854015-9-matt@codeconstruct.com.au> (raw)
In-Reply-To: <20210929072614.854015-1-matt@codeconstruct.com.au>

From: Jeremy Kerr <jk@codeconstruct.com.au>

Describe common flows and refcounting behaviour.

Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
---
 Documentation/networking/mctp.rst | 59 +++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)

diff --git a/Documentation/networking/mctp.rst b/Documentation/networking/mctp.rst
index 6100cdc220f6..2c54b029f990 100644
--- a/Documentation/networking/mctp.rst
+++ b/Documentation/networking/mctp.rst
@@ -211,3 +211,62 @@ 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.
+
+Kernel internals
+================
+
+There are a few possible packet flows in the MCTP stack:
+
+1. local TX to remote endpoint, message <= MTU::
+
+	sendmsg()
+	 -> mctp_local_output()
+	    : route lookup
+	    -> rt->output() (== mctp_route_output)
+	       -> dev_queue_xmit()
+
+2. local TX to remote endpoint, message > MTU::
+
+	sendmsg()
+	-> mctp_local_output()
+	    -> mctp_do_fragment_route()
+	       : creates packet-sized skbs. For each new skb:
+	       -> rt->output() (== mctp_route_output)
+	          -> dev_queue_xmit()
+
+3. remote TX to local endpoint, single-packet message::
+
+	mctp_pkttype_receive()
+	: route lookup
+	-> rt->output() (== mctp_route_input)
+	   : sk_key lookup
+	   -> sock_queue_rcv_skb()
+
+4. remote TX to local endpoint, multiple-packet message::
+
+	mctp_pkttype_receive()
+	: route lookup
+	-> rt->output() (== mctp_route_input)
+	   : sk_key lookup
+	   : stores skb in struct sk_key->reasm_head
+
+	mctp_pkttype_receive()
+	: route lookup
+	-> rt->output() (== mctp_route_input)
+	   : sk_key lookup
+	   : finds existing reassembly in sk_key->reasm_head
+	   : appends new fragment
+	   -> sock_queue_rcv_skb()
+
+Key refcounts
+-------------
+
+ * keys are refed by:
+
+   - a skb: during route output, stored in ``skb->cb``.
+
+   - netns and sock lists.
+
+ * keys can be associated with a device, in which case they hold a
+   reference to the dev (set through ``key->dev``, counted through
+   ``dev->key_count``). Multiple keys can reference the device.
-- 
2.30.2


  parent reply	other threads:[~2021-09-29  7:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-29  7:26 [PATCH net-next 00/10] Updates to MCTP core Matt Johnston
2021-09-29  7:26 ` [PATCH net-next 01/10] mctp: Allow MCTP on tun devices Matt Johnston
2021-09-29  7:26 ` [PATCH net-next 02/10] mctp: Allow local delivery to the null EID Matt Johnston
2021-09-29  7:26 ` [PATCH net-next 03/10] mctp: locking, lifetime and validity changes for sk_keys Matt Johnston
2021-09-29  7:26 ` [PATCH net-next 04/10] mctp: Add refcounts to mctp_dev Matt Johnston
2021-09-29  7:26 ` [PATCH net-next 05/10] mctp: Implement a timeout for tags Matt Johnston
2021-09-29  7:26 ` [PATCH net-next 06/10] mctp: Add tracepoints for tag/key handling Matt Johnston
2021-09-29  7:26 ` [PATCH net-next 07/10] mctp: Do inits as a subsys_initcall Matt Johnston
2021-09-29  7:26 ` Matt Johnston [this message]
2021-09-29  7:26 ` [PATCH net-next 09/10] mctp: Set route MTU via netlink Matt Johnston
2021-09-29  7:26 ` [PATCH net-next 10/10] mctp: Warn if pointer is set for a wrong dev type Matt Johnston
2021-09-29 10:10 ` [PATCH net-next 00/10] Updates to MCTP core patchwork-bot+netdevbpf

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=20210929072614.854015-9-matt@codeconstruct.com.au \
    --to=matt@codeconstruct.com.au \
    --cc=davem@davemloft.net \
    --cc=jk@codeconstruct.com.au \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).