From: Alexandra Winter <wintera@linux.ibm.com>
To: Wenjia Zhang <wenjia@linux.ibm.com>,
Jan Karcher <jaka@linux.ibm.com>,
Gerd Bayer <gbayer@linux.ibm.com>,
Alexandra Winter <wintera@linux.ibm.com>,
Halil Pasic <pasic@linux.ibm.com>,
"D. Wythe" <alibuda@linux.alibaba.com>,
Tony Lu <tonylu@linux.alibaba.com>,
Wen Gu <guwen@linux.alibaba.com>,
Peter Oberparleiter <oberpar@linux.ibm.com>,
David Miller <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
Andrew Lunn <andrew+netdev@lunn.ch>
Cc: Julian Ruess <julianr@linux.ibm.com>,
Niklas Schnelle <schnelle@linux.ibm.com>,
Thorsten Winkler <twinkler@linux.ibm.com>,
netdev@vger.kernel.org, linux-s390@vger.kernel.org,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
Simon Horman <horms@kernel.org>
Subject: [RFC net-next 4/7] net/ism: Add kernel-doc comments for ism functions
Date: Wed, 15 Jan 2025 20:55:24 +0100 [thread overview]
Message-ID: <20250115195527.2094320-5-wintera@linux.ibm.com> (raw)
In-Reply-To: <20250115195527.2094320-1-wintera@linux.ibm.com>
Note that in this RFC this patch is not complete, future versions
of this patch need to contain comments for all ism_ops.
Especially signal_event() and handle_event() need a good generic
description.
Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
---
include/linux/ism.h | 115 ++++++++++++++++++++++++++++++++++++++++----
1 file changed, 105 insertions(+), 10 deletions(-)
diff --git a/include/linux/ism.h b/include/linux/ism.h
index 50975847248f..bc165d077071 100644
--- a/include/linux/ism.h
+++ b/include/linux/ism.h
@@ -13,11 +13,26 @@
#include <linux/workqueue.h>
#include <linux/uuid.h>
-/* The remote peer rgid can use dmb_tok to write into this buffer. */
+/*
+ * DMB - Direct Memory Buffer
+ * ==========================
+ * An ism client provides an DMB as input buffer for a local receiving
+ * ism device for exactly one (remote) sending ism device. Only this
+ * sending device can send data into this DMB using move_data(). Sender
+ * and receiver can be the same device.
+ * TODO: Alignment and length rules (CPU and DMA). Device specific?
+ */
struct ism_dmb {
+ /* dmb_tok - Token for this dmb
+ * Used by remote sender to address this dmb.
+ * Provided by ism fabric in register_dmb().
+ * Unique per ism fabric.
+ */
u64 dmb_tok;
+ /* rgid - GID of designated remote sending device */
u64 rgid;
u32 dmb_len;
+ /* sba_idx - Index of this DMB on this receiving device */
u32 sba_idx;
u32 vlan_valid;
u32 vlan_id;
@@ -25,6 +40,8 @@ struct ism_dmb {
dma_addr_t dma_addr;
};
+/* ISM event structure (currently device type specific) */
+// TODO: Define and describe generic event properties
struct ism_event {
u32 type;
u32 code;
@@ -33,38 +50,89 @@ struct ism_event {
u64 info;
};
+//TODO: use enum typedef
#define ISM_EVENT_DMB 0
#define ISM_EVENT_GID 1
#define ISM_EVENT_SWR 2
struct ism_dev;
+/*
+ * ISM clients
+ * ===========
+ * All ism clients have access to all ism devices
+ * and must provide the following functions to be called by
+ * ism device drivers:
+ */
struct ism_client {
+ /* client name for logging and debugging purposes */
const char *name;
+ /**
+ * add() - add an ism device
+ * @dev: device that was added
+ *
+ * Will be called during ism_register_client() for all existing
+ * ism devices and whenever a new ism device is registered.
+ * *dev is valid until ism_client->remove() is called.
+ */
void (*add)(struct ism_dev *dev);
+ /**
+ * remove() - remove an ism device
+ * @dev: device to be removed
+ *
+ * Will be called whenever an ism device is unregistered.
+ * Before this call the device is already inactive: It will
+ * no longer call client handlers.
+ * The client must not access *dev after this call.
+ */
void (*remove)(struct ism_dev *dev);
+ /**
+ * handle_event() - Handle control information sent by device
+ * @dev: device reporting the event
+ * @event: ism event structure
+ */
void (*handle_event)(struct ism_dev *dev, struct ism_event *event);
- /* Parameter dmbemask contains a bit vector with updated DMBEs, if sent
- * via ism_move_data(). Callback function must handle all active bits
- * indicated by dmbemask.
+ /**
+ * handle_irq() - Handle signalling of a DMB
+ * @dev: device owns the dmb
+ * @bit: sba_idx=idx of the ism_dmb that got signalled
+ * TODO: Pass a priv pointer to ism_dmb instead of 'bit'(?)
+ * @dmbemask: ism signalling mask of the dmb
+ *
+ * Handle signalling of a dmb that was registered by this client
+ * for this device.
+ * The ism device can coalesce multiple signalling triggers into a
+ * single call of handle_irq(). dmbemask can be used to indicate
+ * different kinds of triggers.
*/
void (*handle_irq)(struct ism_dev *dev, unsigned int bit, u16 dmbemask);
- /* Private area - don't touch! */
+ /* client index - provided by ism layer */
u8 id;
};
int ism_register_client(struct ism_client *client);
int ism_unregister_client(struct ism_client *client);
+//TODO: Pair descriptions with functions
+/*
+ * ISM devices
+ * ===========
+ */
/* Mandatory operations for all ism devices:
* int (*query_remote_gid)(struct ism_dev *dev, uuid_t *rgid,
* u32 vid_valid, u32 vid);
* Query whether remote GID rgid is reachable via this device and this
* vlan id. Vlan id is only checked if vid_valid != 0.
+ * Returns 0 if remote gid is reachable.
*
* int (*register_dmb)(struct ism_dev *dev, struct ism_dmb *dmb,
* void *client);
- * Register an ism_dmb buffer for this device and this client.
+ * Allocate and register an ism_dmb buffer for this device and this client.
+ * The following fields of ism_dmb must be valid:
+ * rgid, dmb_len, vlan_*; Optionally:requested sba_idx (non-zero)
+ * Upon return the following fields will be valid: dmb_tok, sba_idx
+ * cpu_addr, dma_addr (if applicable)
+ * Returns zero on success
*
* int (*unregister_dmb)(struct ism_dev *dev, struct ism_dmb *dmb);
* Unregister an ism_dmb buffer
@@ -81,10 +149,15 @@ int ism_unregister_client(struct ism_client *client);
* u16 (*get_chid)(struct ism_dev *dev);
* Returns ism fabric identifier (channel id) of this device.
* Only devices on the same ism fabric can communicate.
- * chid is unique per HW system, except for 0xFFFF, which denotes
- * an ism_loopback device that can only communicate with itself.
- * Use chid for fast negative checks, but only query_remote_gid()
- * can give a reliable positive answer.
+ * chid is unique per HW system. Use chid for fast negative checks,
+ * but only query_remote_gid() can give a reliable positive answer:
+ * Different chid: ism is not possible
+ * Same chid: ism traffic may be possible or not
+ * (e.g. different HW systems)
+ * EXCEPTION: A value of 0xFFFF denotes an ism_loopback device
+ * that can only communicate with itself. Use GID or
+ * query_remote_gid()to determine whether sender and
+ * receiver use the same ism_loopback device.
*
* struct device* (*get_dev)(struct ism_dev *dev);
*
@@ -109,6 +182,28 @@ struct ism_ops {
int (*register_dmb)(struct ism_dev *dev, struct ism_dmb *dmb,
struct ism_client *client);
int (*unregister_dmb)(struct ism_dev *dev, struct ism_dmb *dmb);
+ /**
+ * move_data() - write into a remote dmb
+ * @dev: Local sending ism device
+ * @dmb_tok: Token of the remote dmb
+ * @idx: signalling index
+ * @sf: signalling flag;
+ * if true, idx will be turned on at target ism interrupt mask
+ * and target device will be signalled, if required.
+ * @offset: offset within target dmb
+ * @data: pointer to data to be sent
+ * @size: length of data to be sent
+ *
+ * Use dev to write data of size at offset into a remote dmb
+ * identified by dmb_tok. Data is moved synchronously, *data can
+ * be freed when this function returns.
+ *
+ * If signalling flag (sf) is true, bit number idx bit will be
+ * turned on in the ism signalling mask, that belongs to the
+ * target dmb, and handle_irq() of the ism client that owns this
+ * dmb will be called, if required. The target device may chose to
+ * coalesce multiple signalling triggers.
+ */
int (*move_data)(struct ism_dev *dev, u64 dmb_tok, unsigned int idx,
bool sf, unsigned int offset, void *data,
unsigned int size);
--
2.45.2
next prev parent reply other threads:[~2025-01-15 19:55 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-15 19:55 [RFC net-next 0/7] Provide an ism layer Alexandra Winter
2025-01-15 19:55 ` [RFC net-next 1/7] net/ism: Create net/ism Alexandra Winter
2025-01-16 20:08 ` Andrew Lunn
2025-01-17 12:06 ` Alexandra Winter
2025-01-15 19:55 ` [RFC net-next 2/7] net/ism: Remove dependencies between ISM_VPCI and SMC Alexandra Winter
2025-01-15 19:55 ` [RFC net-next 3/7] net/ism: Use uuid_t for ISM GID Alexandra Winter
2025-01-20 17:18 ` Simon Horman
2025-01-22 14:46 ` Alexandra Winter
2025-01-15 19:55 ` Alexandra Winter [this message]
2025-01-15 22:06 ` [RFC net-next 4/7] net/ism: Add kernel-doc comments for ism functions Halil Pasic
2025-01-20 6:32 ` Dust Li
2025-01-20 9:56 ` Alexandra Winter
2025-01-20 10:07 ` Julian Ruess
2025-01-20 11:35 ` Alexandra Winter
2025-01-20 10:34 ` Niklas Schnelle
2025-01-22 15:02 ` Dust Li
2025-01-15 19:55 ` [RFC net-next 5/7] net/ism: Move ism_loopback to net/ism Alexandra Winter
2025-01-20 3:55 ` Dust Li
2025-01-20 9:31 ` Alexandra Winter
2025-02-06 17:36 ` Julian Ruess
2025-02-10 10:39 ` Alexandra Winter
2025-01-15 19:55 ` [RFC net-next 6/7] s390/ism: Define ismvp_dev Alexandra Winter
2025-01-15 19:55 ` [RFC net-next 7/7] net/smc: Use only ism_ops Alexandra Winter
2025-01-16 9:32 ` [RFC net-next 0/7] Provide an ism layer Dust Li
2025-01-16 11:55 ` Julian Ruess
2025-01-16 16:17 ` Alexandra Winter
2025-01-16 17:08 ` Julian Ruess
2025-01-17 2:13 ` Dust Li
2025-01-17 10:38 ` Niklas Schnelle
2025-01-17 15:02 ` Andrew Lunn
2025-01-17 16:00 ` Niklas Schnelle
2025-01-17 16:33 ` Andrew Lunn
2025-01-17 16:57 ` Niklas Schnelle
2025-01-17 20:29 ` Andrew Lunn
2025-01-20 6:21 ` Dust Li
2025-01-20 12:03 ` Alexandra Winter
2025-01-20 16:01 ` Andrew Lunn
2025-01-20 17:25 ` Alexandra Winter
2025-01-18 15:31 ` Dust Li
2025-01-28 16:04 ` Alexandra Winter
2025-02-10 5:08 ` Dust Li
2025-02-10 9:38 ` Alexandra Winter
2025-02-11 1:57 ` Dust Li
2025-02-16 15:40 ` Wen Gu
2025-02-19 11:25 ` [RFC net-next 0/7] Provide an ism layer - naming Alexandra Winter
2025-02-25 1:36 ` Dust Li
2025-02-25 8:40 ` Alexandra Winter
2025-01-17 13:00 ` [RFC net-next 0/7] Provide an ism layer Alexandra Winter
2025-01-17 15:10 ` Andrew Lunn
2025-01-17 16:20 ` Alexandra Winter
2025-01-20 10:28 ` Alexandra Winter
2025-01-22 3:04 ` Dust Li
2025-01-22 12:02 ` Alexandra Winter
2025-01-22 12:05 ` Alexandra Winter
2025-01-22 14:10 ` Dust Li
2025-01-17 15:06 ` Andrew Lunn
2025-01-17 15:38 ` Alexandra Winter
2025-02-16 15:38 ` Wen Gu
2025-01-17 11:04 ` Alexandra Winter
2025-01-18 15:24 ` Dust Li
2025-01-20 11:45 ` Alexandra Winter
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=20250115195527.2094320-5-wintera@linux.ibm.com \
--to=wintera@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=alibuda@linux.alibaba.com \
--cc=andrew+netdev@lunn.ch \
--cc=borntraeger@linux.ibm.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gbayer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=guwen@linux.alibaba.com \
--cc=hca@linux.ibm.com \
--cc=horms@kernel.org \
--cc=jaka@linux.ibm.com \
--cc=julianr@linux.ibm.com \
--cc=kuba@kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=oberpar@linux.ibm.com \
--cc=pabeni@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=schnelle@linux.ibm.com \
--cc=svens@linux.ibm.com \
--cc=tonylu@linux.alibaba.com \
--cc=twinkler@linux.ibm.com \
--cc=wenjia@linux.ibm.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 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).