跳转至

msPTI Feature Design Specifications

SIG group: mstt-sig
Target Version: MindStudio 26.0.0
Designer: chenhao
Date: 2026.01.21

Copyright © 2022 openGauss Community

Your replication, use, modification, and distribution of this document are governed by the Creative Commons Attribution-ShareAlike 4.0 International Public License (CC BY-SA 4.0). You can visit https://creativecommons.org/licenses/by-sa/4.0/ to view a summary of (not a substitute for) CC BY-SA 4.0. For the complete CC BY-SA 4.0, visit https://creativecommons.org/licenses/by-sa/4.0/legalcode.

Change History

Date Version Description Author Reviewer
2026.01.21 1.0 Initial draft. chenhao

1. Feature Overview

The MindStudio Profiling Tools Interface (msPTI) is a set of profiling APIs provided by MindStudio for Ascend devices. You can use msPTI to build tools for NPU applications to analyze the performance of the applications. msPTI is a universal API. Profiling tools developed using msPTI APIs can be used in inference and training scenarios of various frameworks.

1.1 Scope

msPTI provides the following functions:

  • Tracing: In msPTI, tracing refers to the collection of timestamps and additional information about the execution and startup of CANN activities in CANN applications, such as CANN APIs, kernels, and memory copy. Identify performance issues of CANN by understanding the program running duration. You can use the Activity APIs and Callback APIs to collect tracing information.

  • Profiling: In msPTI, profiling refers to the collection of NPU performance metrics of one or a group of kernels.

1.2 Feature Requirement List

Table 1 List of feature requirements

Requirement No. Requirement Feature Description Remarks
1 Supports the collection capability of CANN Runtime APIs. Collects statistics on API calls and time consumption at the runtime level.

2. Requirement Scenario Analysis

2.1 Requirement Origin and Benefits

The external API collection capability of msPTI is extended to support the collection capability of CANN Runtime APIs.

2.2 Feature Scenario Analysis

Scenario triggering condition: For host-bound service processes, the factors that affect the CANN API performance analysis need to be analyzed.

The user needs to analyze the API performance on the CANN Runtime side, and obtain and analyze the API time consumption.

2.3 Feature Impact Analysis

2.3.1 Hardware Restrictions

Product Type Supported
Ascend 950 products
Atlas A3 training products/Atlas A3 inference products
Atlas A2 training products/Atlas A2 inference products
Atlas 200I/500 A2 inference products
Atlas inference products ×
Atlas training series products ×

2.3.2 Technical Restrictions

Operating system: Linux

Programming language: C/Python

3. Feature/Function Implementation Principles (Decomposable into Multiple Use Cases)

3.1 Objectives

Describe the specifications and objectives of the feature in different scenarios.

3.2 Overall Solution

Profiling scenario: The system measures the time consumed by key functions, key computing, and communication, collects data, flushes the data to disks, and performs offline parsing and visualized display.

image_1

Figure 1: Overall implementation principle of the msPTI solution

4. Supports the collection capability of CANN Runtime APIs.

4.1 Design Rationale

The msPTI enables the runtime API data collection capability through the msptiActivityEnable(msptiActivityKind kind) API and obtains the runtime API data through the callback API.

4.2 Constraints

No constraint

4.3 Detailed Implementation (Module- or Process-Level Message Sequence Diagrams from the User Entry)

Describe the implementation process of the use case in detail. Use timing diagrams and flowcharts to illustrate the interaction between modules.

Use brief words to describe the changes of module allocation requirements in the sequence diagrams and flowcharts. Structured language is preferred.

4.4 Inter-Subsystem Interfaces (Mainly Module Interface Definitions)

Extended interface capability: msptiActivityEnable(msptiActivityKind kind)

4.5 Detailed Subsystem Design

The msPTI enables the runtime API data collection capability through the msptiActivityEnable(msptiActivityKind kind) API and obtains the runtime API data through the callback API.

4.6 DFX Attribute Design

4.6.1 Performance Design

The impact on performance is limited. Only the enabling and obtaining of the API type are performed. The number of runtime APIs is controllable.

4.6.2 Upgrade and Capacity Expansion Design

Upgrade and capacity expansion scenarios are not involved.

4.6.3 Exception Handling Design

Describe the potential exception scenarios, whether workarounds exist, how users are notified, and how to minimize impact on user services.

4.6.4 Resource Management Design

The enabled runtime API uses the memory transferred by the user. The resource specifications can be maintained by the user's normal consumption. When the memory is used in the critical condition, the user can control the size of the requested memory.

The msPTI data is managed in the memory in a unified manner. The disk I/O is a post-processing procedure after the user consumes the data. Therefore, the consumption frequency can be considered.

4.6.5 Compact Design

There is no version design related to miniaturization. There is no impact.

4.6.7 Security Design

4.6.7.1 Security Design Confirmation

Confirm the security design by referring to the security design checklist.

Security Attribute Check Item Description Involved or Not Satisfied or Not
Access channel control Whether any listening port is added If any listening port is added, update the communication matrix. No
Access channel control Whether any process or inter-component communication method is added If any process or inter-component communication method is added, update the communication matrix. No
Access channel control Whether any authentication mode is added If any authentication mode is added, update the communication matrix and product documentation. No
Permission control Whether any file or directory needs to be created If any file or directory needs to be created, explicitly specify the access permission of the file or directory. No
Permission control Whether the account permission meets the principle of least privilege Assign the minimum permissions to each account in the system. No
Permission control Whether user privilege escalation exists User privilege escalation is prohibited. No
Undisclosed interface Whether any grand unified configuration (GUC) parameter is added If any GUC parameter is added, update the product documentation. No
Undisclosed interface Whether any function, view, or system table is added or modified If any function, view, or system table is added or modified, update the product documentation and consider updating the permission control policy. No
Undisclosed interface Whether any SQL syntax is added If any SQL syntax is added, update the product documentation and add support for recording audit logs. No
Undisclosed interface Whether any internal tool is added If any internal tool is added, update the product documentation. No
Undisclosed interface Whether the script contains commented-out code Commented-out code is prohibited in interpreted languages such as Shell and Python and must be deleted. No
Undisclosed interface Whether there are hidden access methods such as commands, parameters, and ports Access methods such as commands, parameters, and ports (including but not limited to those for product production, commissioning, and maintenance) that are not used during live network maintenance must be deleted (for example, by using macros). No
Undisclosed interface Whether the system has hidden backdoors No undocumented accounts may be reserved in the system. All accounts must be manageable by the system and documented accordingly. No
Undisclosed interface Whether any cracking or network sniffing tool is provided in the software (including software packages and patch packages) released to external users 1. Do not provide any function or tool that can change user passwords, perform exhaustive password search (including malicious cracking of passwords by exploiting system or algorithm vulnerabilities), or decrypt files containing sensitive data (such as configuration files and databases containing keys) in the software (including software packages and patch packages) released to external users. 2. Third-party network sniffing tools (such as tcpdump, gdb, strace, and readelf), debugging tools (such as cpp, gcc, dexdump, and mirror), JDK development or compilation tools, and proprietary debugging tools and scripts (such as encryption/decryption scripts, debugging functions, and privilege escalation commands) used only for commissioning must not be retained in the system. If retention is required for service needs, strict access control must be enforced. The scenarios, risks, and reasons for keeping them must also be explained in the product documentation. No
Sensitive data protection Whether authentication credentials are encrypted before being stored in the system Authentication credentials (such as passwords and private keys) must be encrypted for storage in the system. No
Sensitive data protection Whether keys for encrypting sensitive data during transmission are hard-coded Hard-coded passwords and keys are prohibited. No
Sensitive data protection Whether sensitive information such as passwords or keys is recorded in plaintext It is prohibited to display sensitive information (including passwords, private keys, and pre-shared keys) in plaintext in logs stored in the system, debugging information, error messages, and ps commands. No
Sensitive data protection Whether passwords are displayed in plaintext in command output It is prohibited to display passwords in plaintext in command output. No
Sensitive data protection Whether the default passwords of third-party and open source software are used It is prohibited to use the default passwords of third-party and open source software. For details, see section 1.5 in the Security Design Guide. No
Sensitive data protection Whether passwords are stored in plaintext in configuration files Passwords must not be written into configuration files in plaintext (except for scenarios where passwords must be specified during the installation, deployment, and use of the CLI tool). No
Sensitive data protection Whether any insecure encryption algorithm is used It is prohibited to use proprietary or insecure encryption algorithms known in the industry. For recommended encryption algorithms, see section 6.2 in Security Design Guide. No
Sensitive data protection Whether sensitive information such as passwords is transmitted through secure channels Sensitive information must be transmitted through secure channels or encrypted before transmission on untrusted networks. For details, see chapter 10 in Security Design Guide. No
Sensitive data protection Whether sensitive information such as passwords and keys in the memory is destroyed after use Sensitive information such as passwords and keys in the memory must be cleared immediately after use No
Sensitive data protection Whether random numbers used by cryptographic algorithms are cryptographically secure Random numbers used by cryptographic algorithms must be cryptographically secure. For details, see section 6.3 in Security Design Guide. No
Sensitive data protection Whether there are insecure examples in the documentation Examples in the documentation must be secure and provide correct guidance for users. If there are potential risks in the examples, describe the risks in the documentation. No
Authentication Whether an authentication mechanism is provided An authentication mechanism must be provided and enabled by default for the new system. No
Authentication Whether authentication is performed on the server Authentication must be performed on the server. No
Authentication Whether the server returns valid information upon an authentication failure Upon an authentication failure, the server must return detailed information of the failure to help the user locate the cause of the failure. No
External parameter verification Whether the validity of external input is verified 1. The use of external input data as parameters such as loop termination conditions, array indices, and memory allocation sizes may lead to system behaviors such as infinite loops, buffer overflows, memory out-of-bounds access, and denial of service. 2. The validity of external input such as file paths must be verified to prevent injection risks. Yes Yes
Third-party component introduction Whether any new third-party component is introduced 1. New third-party components must pass security compilation options, virus and vulnerability scanning, open source snippet detection, license compliance checks, and open source component scanning. For details, see the network security requirements for version releases. 2. Ensure new third-party components originate from trusted sources. No

4.6.7.2 Sensitive Data Analysis

1. Sensitive data list

No sensitive data is involved.

2. Sensitive operation check

There are no sensitive operations and no sensitive data is involved.

4.6.7.3 Design Implementation

The msPTI enables the runtime API data collection capability through the msptiActivityEnable(msptiActivityKind kind) API and obtains the runtime API data through the callback API.

The enabled runtime API uses the memory transferred by the user. The user can maintain the resource specifications by consuming the memory in a normal way. When the memory is used in the critical condition, the user can control the size of the requested memory.

The msPTI data is managed in the memory in a unified manner. The disk I/O is the post-processing procedure after the user consumes the data. The consumption frequency can be considered.

4.7 External Interfaces

The API data is obtained by reusing the API capability: msptiActivityEnable(msptiActivityKind kind)

5. (Optional) Data structure design

No structure change is involved. The runtime API data and other APIs at the CANN layer use the same data format and APIs for reporting.