Data Structures | |
| struct | m0_isc_comp_private |
| struct | m0_isc_comp_req |
Enumerations | |
| enum | m0_isc_comp_req_type { M0_ICRT_LOCAL, M0_ICRT_REMOTE } |
Functions | |
| M0_INTERNAL void | m0_isc_comp_req_init (struct m0_isc_comp_req *comp_req, const struct m0_buf *comp_args, const struct m0_fid *comp_fid, const struct m0_cookie *comp_cookie, enum m0_isc_comp_req_type comp_req_type, struct m0_reqh *reqh) |
| M0_INTERNAL void | m0_isc_comp_req_fini (struct m0_isc_comp_req *comp_req) |
| M0_INTERNAL int | m0_isc_comp_req_exec (struct m0_isc_comp_req *comp_req) |
| M0_INTERNAL int | m0_isc_comp_req_exec_sync (struct m0_isc_comp_req *comp_req) |
| M0_INTERNAL int | m0_isc_comp_register (int(*ftn)(struct m0_buf *arg_in, struct m0_buf *args_out, struct m0_isc_comp_private *comp_data, int *rc), const char *f_name, const struct m0_fid *ftn_fid) |
| M0_INTERNAL void | m0_isc_comp_unregister (const struct m0_fid *fid) |
| M0_INTERNAL int | m0_isc_comp_state_probe (const struct m0_fid *fid) |
| M0_INTERNAL int | m0_isc_lib_register (const char *libpath, struct m0_fid *profile, struct m0_reqh *reqh) |
| M0_INTERNAL int | m0_isc_io_launch (struct m0_stob_io *stio, struct m0_fid *cob, struct m0_io_indexvec *iv, struct m0_fom *fom) |
| M0_INTERNAL int64_t | m0_isc_io_res (struct m0_stob_io *stio, char **buf) |
| M0_INTERNAL void | m0_isc_io_fini (struct m0_stob_io *stio) |
Detailed Description
- See also
- Request handler
Design Highlights
The in-storage-compute service (iscs) provides a platform to perform computations on data stored with Motr. This enables Motr users to perform concurrent computation on stored data along with minimal network communication. The computations on data can range from linear algebraic operations or Fast Fourier Transform, to searching of a string (distributed grep) across Motr nodes. ISC service facilitates these computations by providing two types of interfaces:
- Low level interface
- Sandboxing
Low-level interface is designed for computations "trusted" by Motr. It can be thought of as a system call which after being invoked triggers a preregistered computation on Motr side. The Motr trusted applications can use the internal Motr infrastructure (fom scheduler/stob I/O etc.) and hence the ISC service does not perform any task on behalf of the computation.
Sandboxing is for applications not having a direct access to Motr internals. They can request data from Motr and can then apply the appropriate computation.
Low Level Interface
Low level interface can be used in two ways:
- m0_isc_comp_req_exec: this API supports a local invocation of a registered function. It's an asynchronous call which executes a registered callback on completion.
- Using fop/fom mechanism: supports remote invocation. Arguments and results to be returned are communicated over a network.
Computations registered with the service are stored in an in-memory hash table. It's worth noting that the service remains oblivious to the details of the function, including IO or network access. Since Motr uses a non-preemptive request handler, a service fom is expected to yield the cpu core whenever it's waiting on an external event. In order to be aligned with this semantics, a computation is expected to convey its state (see m0_fom_state) to its caller fom.
A typical use-case of isc service is described below: -All computations registered with ISC service low-level framework shall confine to the following signature:
int comp(struct m0_buf *args, struct m0_buf *out,
struct m0_isc_comp_private *comp_data, int *rc)- "out" holds the result of a computation while "rc" captures an error code if any. The returned value of computation shall be either of M0_FSO_AGAIN and M0_FSO_WAIT. In case the computation needs to be re-invoked, "rc" shall hold "-EAGAIN". A detailed semantics of return value and error code is available in "ISC Service user guide" (please see below for the link).
- While using external libraries it's necessary to prepare a wrapper over the library APIs to convert them to the above mentioned signature.
- A library is expected to have a function "motr_lib_init()". When library is linked (via m0_spiel_process_lib_load()), this function will be called which can then register relevant library APIs with Motr.
- An API is registered with Motr using m0_isc_comp_register(). A unique identifier (m0_fid) associated with the API is used to store it in the internal hash table.
- A user of the computation can invoke it either using m0_comp_req_exec() or by sending m0_fop_isc. In both cases a fid of the computation is provided to invoke the same. In the later case the results are communicated using RPC adaptive transmission buffers (m0_rpc_at_buf).
-ISC Service user guide: For documentation links, please refer to this file : doc/motr-design-doc-list.rst
Sandboxing
Sandboxing is used by applications that don't have an access to Motr internals. Computations involved in sandboxing will communicate with Motr instance over a shared memory segment (or POSIX message queues).
Layout Plans
File layout maps logical offset from a file to logical offset from available device(s). In order to schedule computations over data it's necessary to know the interdependency of operations, and this is where the layout access plan is required. Kindly refer "layout/plan.h" for detailed documentation.
Enumeration Type Documentation
◆ m0_isc_comp_req_type
| enum m0_isc_comp_req_type |
Function Documentation
◆ m0_isc_comp_register()
| M0_INTERNAL int m0_isc_comp_register | ( | int(*)(struct m0_buf *arg_in, struct m0_buf *args_out, struct m0_isc_comp_private *comp_data, int *rc) | ftn, |
| const char * | f_name, | ||
| const struct m0_fid * | ftn_fid | ||
| ) |
Registers a "trusted" computation with the service. A prospective caller of this API could be invoked via m0_spiel_process_lib_load(). For more details
- See also
- sss/process_foms.css_process_fom_tick.
- Parameters
-
[in] ftn An external computation. All computations are expected to follow the same signature. [in] f_name Human readable name of the computation. [in] ftn_fid A unique identifier associated with the computation.
- Return values
-
0 On success. -EEXIST When the fid provided already exists.
Definition at line 609 of file isc.c.
◆ m0_isc_comp_req_exec()
| M0_INTERNAL int m0_isc_comp_req_exec | ( | struct m0_isc_comp_req * | comp_req | ) |
Invokes the function locally. This is an asynchronous API, which on completion invokes the registered callback(s) from the channel embedded in m0_isc_comp_req.
- Parameters
-
[in] comp_req A request for computation.
- Return values
-
0 On success. -EINVAL If isc-service is not present with the Motr instance.
Definition at line 497 of file isc.c.
◆ m0_isc_comp_req_exec_sync()
| M0_INTERNAL int m0_isc_comp_req_exec_sync | ( | struct m0_isc_comp_req * | comp_req | ) |
Synchronous version of m0_isc_comp_req_exec(). The return value indicates error if any, associated with the launching of a computation, and actual result of computation shall be reflected by comp_req->icr_rc.
- Parameters
-
[in] comp_req A request for computation.
- Return values
-
0 On success. -EINVAL If isc-service is not present with the Motr instance.
Definition at line 517 of file isc.c.
◆ m0_isc_comp_req_fini()
| M0_INTERNAL void m0_isc_comp_req_fini | ( | struct m0_isc_comp_req * | comp_req | ) |
◆ m0_isc_comp_req_init()
| M0_INTERNAL void m0_isc_comp_req_init | ( | struct m0_isc_comp_req * | comp_req, |
| const struct m0_buf * | comp_args, | ||
| const struct m0_fid * | comp_fid, | ||
| const struct m0_cookie * | comp_cookie, | ||
| enum m0_isc_comp_req_type | comp_req_type, | ||
| struct m0_reqh * | reqh | ||
| ) |
Initializes the request for computation.
- Parameters
-
[in] comp_req Request to be initialized. [in] comp_args Arguments for the computation. This buffer is copied internally. [in] comp_fid Unique identifier for the computation. [in] comp_cookie Cookie for the computation. [in] comp_req_type Indicates if the request is local or remote. [in] reqh Request handler.
Definition at line 537 of file isc.c.
◆ m0_isc_comp_state_probe()
| M0_INTERNAL int m0_isc_comp_state_probe | ( | const struct m0_fid * | fid | ) |
Probes the state of a computation, with respect to its registration with service.
- Parameters
-
[in] fid Unique identifier of a computation.
- Return values
-
M0_ICS_REGISTERED If computation is registered. M0_ICS_UNREGISTERED If computation is present but marked unregistered. -ENOENT If computation is not present.
Definition at line 668 of file isc.c.
◆ m0_isc_comp_unregister()
| M0_INTERNAL void m0_isc_comp_unregister | ( | const struct m0_fid * | fid | ) |
Removes the function from service registry. It need not immediately remove the function from in-memory hash table, as there might be ongoing instances of it. But it ensures that no new execution request is accepted, as well as once all the ongoing instances are completed, the function is removed from the hash table.
- Parameters
-
[in] ftn_fid An identifier for a registered computation.
Definition at line 652 of file isc.c.
◆ m0_isc_io_fini()
| M0_INTERNAL void m0_isc_io_fini | ( | struct m0_stob_io * | stio | ) |
◆ m0_isc_io_launch()
| M0_INTERNAL int m0_isc_io_launch | ( | struct m0_stob_io * | stio, |
| struct m0_fid * | cob, | ||
| struct m0_io_indexvec * | iv, | ||
| struct m0_fom * | fom | ||
| ) |
◆ m0_isc_io_res()
| M0_INTERNAL int64_t m0_isc_io_res | ( | struct m0_stob_io * | stio, |
| char ** | buf | ||
| ) |
Retrieves the read I/O result after m0_isc_io_launch() into .
- Return values
-
number of bytes read or -error
Definition at line 913 of file isc.c.
