Message processing method and apparatus, chip, device, storage medium and program product

Abstract

A message processing method and apparatus, a chip, a device, a storage medium and a program product. The message processing method is applied to a message processing device, the message processing device comprising a receiving module (301), a transmitting module (302), a filtering module (303) and an algorithm execution module (304). The method comprises: the receiving module (301) receives a message to be processed and, on the basis of the type of said message, triggers a message processing event corresponding to said message; on the basis of prearranged event enabling information, the filtering module (303) filters out an unenabled event among the message processing event, and transmits an event request to the algorithm execution module (304), the event request comprising event information of the filtered message processing event; on the basis of the event information, the algorithm execution module executes a processing algorithm of the filtered message processing event so as to obtain event response information, and transmits the event response information to the transmitting module (302) by means of the filtering module; and, on the basis of the event response information, the transmitting module (302) adjusts a message transmitting behavior.

Description

Message processing method, device, chip, equipment, storage medium and program product

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on January 29, 2024, with application number 2024101230023 and invention name “Message processing method, device, chip, equipment, storage medium and program product”. The entire contents of the patent application are incorporated into this application by reference. Technical Field

[0003] The present application relates to the field of chip technology, and in particular to a message processing method, apparatus, chip, device, storage medium and program product. Background Art

[0004] The programmable congestion control (PCC) framework allows users to design and implement congestion control algorithms based on actual application scenarios, enabling the various event signals contained in the PCC framework. This gives users tremendous flexibility to implement optimal congestion control solutions to address congestion issues in server clusters.

[0005] In related technologies, devices that support the PCC framework operate based on an event response model. However, currently, all PCC event reporting is concentrated on the source end, and the PCC framework on the receiving end does not run. The processing algorithms corresponding to message processing events have low scalability, making it difficult for users to flexibly develop receiver-driven congestion control algorithms. Summary of the Invention

[0006] According to various embodiments of the present application, a message processing method, apparatus, chip, device, storage medium, and program product are provided.

[0007] In a first aspect, the present application provides a message processing method. Applied to a message processing device, the message processing device comprising a receiving module, a sending module, a filtering module, and an algorithm execution module, the method comprising:

[0008] The receiving module receives the message to be processed and triggers a message processing event corresponding to the message to be processed according to the type of the message to be processed;

[0009] The filtering module filters the disabled events in the message processing events according to the preset event enabling information, and sends an event request to the algorithm execution module, wherein the event request includes event information of the filtered message processing events;

[0010] The algorithm execution module executes the processing algorithm of the filtered message processing event according to the event information to obtain event response information, and sends the event response information to the sending module through the filtering module;

[0011] The sending module adjusts the message sending behavior according to the event response information.

[0012] In one embodiment, before sending the event request to the algorithm execution module, the method further includes:

[0013] The filtering module pre-processes the initial information of the filtered message processing event to generate event information of the filtered message processing event;

[0014] The preprocessing includes at least one of the following: calculation processing, clipping processing, merging processing, and discarding processing.

[0015] In one embodiment, the message to be processed includes congestion marking information and / or network telemetry information added by a network forwarding device, and the network forwarding device is used to forward messages between two message processing devices.

[0016] In one embodiment, the message processing device further includes a management and control module. Before the algorithm execution module executes the processing algorithm of the filtered message processing event based on the event information to obtain event response information, the method further includes:

[0017] The control module creates processing resources for the filtered message processing events and starts the algorithm process in the algorithm execution module through hot upgrade;

[0018] The algorithm execution module executes the processing algorithm of the filtered message processing event according to the event information to obtain event response information, including:

[0019] The algorithm execution module runs the processing algorithm of the filtered message processing event in the algorithm process according to the algorithm parameters and the event information to obtain the event response information.

[0020] In one embodiment, after the control module creates processing resources for the filtered message processing events and starts the algorithm process in the algorithm execution module through hot upgrade, the method further includes:

[0021] The management and control module obtains, through the congestion control queue, a congestion control entry of the algorithm execution module when running the processing algorithm, wherein the congestion control entry includes algorithm status information of the processing algorithm;

[0022] The control module adjusts the algorithm parameters according to the algorithm status information.

[0023] In one embodiment, the control module obtains, through the congestion control queue, the congestion control entry of the algorithm execution module when running the processing algorithm, including:

[0024] The algorithm execution module creates the congestion control entry;

[0025] The algorithm execution module determines whether the congestion control queue is in a full queue state according to the head pointer information and the tail pointer information of the congestion control queue;

[0026] If the congestion control queue is not in a full queue state, the algorithm execution module adds the congestion control entry to the end of the congestion control queue and flips the mark information of the congestion control queue;

[0027] The management and control module obtains the congestion control entry in the congestion control queue according to the marking information, and updates the head pointer information of the congestion control queue.

[0028] In one embodiment, after the management and control module obtains the algorithm state information of the algorithm process when running the processing algorithm through the congestion control queue, the method further includes:

[0029] If the algorithm status information is abnormal, the management and control module destroys the processing resources of the filtered message processing event and exits the algorithm process.

[0030] In one embodiment, the algorithm parameters include granularity configuration parameters, event enable parameters, feedback enable parameters, algorithm execution parameters, and hardware configuration parameters.

[0031] In one embodiment, the event response information includes the priority of each network path for message transmission and the message sending mode; the sending module adjusts the message sending behavior according to the event response information, including:

[0032] The sending module adjusts the message sending behavior according to the priority of the network path for each message transmission and the message sending mode;

[0033] The message sending mode includes a rate-based sending mode, a window-based sending mode, a token-based sending mode or a credit-based sending mode.

[0034] In one embodiment, the event response information is used to adjust the message sending behavior of the network path corresponding to the event response information, or the event response information is used to adjust the message sending behavior of all network paths corresponding to the message processing device.

[0035] In one embodiment, the event request is exchanged between the algorithm execution module and the filtering module via an event request queue, and the event response information is exchanged between the algorithm execution module and the filtering module via an event response queue.

[0036] In one embodiment, the event request queue includes an active subqueue and a submitted subqueue;

[0037] The sending of the event request to the algorithm execution module includes:

[0038] The filtering module sends the event request to the active sub-queue;

[0039] The filtering module aggregates the event requests through the active subqueue;

[0040] If the number of events in the submission subqueue is greater than or equal to a first number threshold, the filtering module controls the event requests in the active subqueue to block and wait until a blocking end condition is satisfied; the blocking end condition includes: the number of events in the submission subqueue is less than the first number threshold, or the number of events in the submission subqueue is not full and the number of event requests in the active subqueue is greater than or equal to a second number threshold;

[0041] If the number of events in the submission subqueue is less than a first number threshold, the filtering module sends the event requests in the active subqueue to the submission subqueue, so that the algorithm execution module reads the event requests in the submission subqueue.

[0042] In one embodiment, after the filtering module aggregates the event requests through the active sub-queue, the method further includes:

[0043] The filtering module generates event information of the aggregated event request according to the type of the event aggregation; wherein the type of the event aggregation includes an accumulation type and an overlay type.

[0044] In one embodiment, the method further comprises:

[0045] If the number of events in the event request queue is full, the filtering module discards the event request in the event request queue according to the event discard configuration information, or the filtering module sends an indication message to the receiving module, and the indication message is used to instruct the receiving module to stop sending the message processing event to the filtering module.

[0046] In one embodiment, starting the algorithm process in the algorithm execution module by hot upgrading includes:

[0047] The management and control module stores the compiled file corresponding to the processing algorithm in a target storage location, so that the processor of the message processing device starts the algorithm process by obtaining and loading the compiled file in the target storage location.

[0048] In a second aspect, the present application provides a message processing device. The message processing device includes a receiving module, a sending module, a filtering module, and an algorithm execution module;

[0049] The receiving module is used to receive a message to be processed and trigger a message processing event corresponding to the message to be processed according to the type of the message to be processed;

[0050] The filtering module is configured to filter the disabled events in the message processing events according to the preset event enabling information, and send an event request to the algorithm execution module, wherein the event request includes event information of the filtered message processing events;

[0051] The algorithm execution module is configured to execute the processing algorithm of the filtered message processing event according to the event information, obtain event response information, and send the event response information to the sending module through the filtering module;

[0052] The sending module is used to adjust the message sending behavior according to the event response information.

[0053] In a third aspect, the present application further provides a chip, which includes the message processing device as described in the second aspect.

[0054] In a fourth aspect, the present application further provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the message processing method of the first aspect when executing the computer program.

[0055] In a fifth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the message processing method of the first aspect.

[0056] In a sixth aspect, the present application further provides a computer program product, comprising a computer program, which, when executed by a processor, implements the message processing method of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, without paying any creative labor, obtaining other drawings based on these drawings still falls within the scope of the present application.

[0058] FIG1 is a schematic diagram of an application environment of a message processing method provided in an embodiment of the present application;

[0059] FIG2 is a schematic diagram of the structure of a message processing device provided in an embodiment of the present application;

[0060] FIG3 is a schematic diagram of a PCC framework endpoint operation process provided by an embodiment of the present application;

[0061] FIG4 is a schematic diagram of a process flow of an algorithm hot upgrade provided in an embodiment of the present application;

[0062] FIG5 is a schematic diagram of the interaction between a control module and an algorithm execution module according to an embodiment of the present application;

[0063] FIG6 is a schematic diagram of another interaction between a control module and an algorithm execution module according to an embodiment of the present application;

[0064] FIG7 is a schematic diagram of compiling an algorithm execution module provided in an embodiment of the present application;

[0065] FIG8 is a schematic diagram of compiling a control module provided in an embodiment of the present application;

[0066] FIG9 is a flow chart of a message processing method provided in an embodiment of the present application;

[0067] FIG10 is a structural block diagram of a message processing device provided in an embodiment of the present application;

[0068] FIG11 is a diagram showing the internal structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0069] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0070] First, the related technology will be described below.

[0071] In related technologies, devices that support the PCC framework operate based on an event-response model. Devices that support the PCC framework support six user-enabled event signals, including firmware signal (DOCA_PCC_DEV_EVNT_FW), congestion notification packet (CNP), message sending signal (DOCA_PCC_DEV_EVNT_ROCE_CNP), message acknowledgment signal (DOCA_PCC_DEV_EVNT_ROCE_ACK), unexpected message acknowledgment signal (DOCA_PCC_DEV_EVNT_ROCE_NACK), and network round-trip time (RTT) signal. For example, as shown in Table 1, different event signals correspond to different event meanings, data content, and data granularity.

[0072] Table 1

[0073] In addition to the data fields shown in Table 1, each event report also includes common data fields, including the port number (port_num), flow identifier (flow_tag), message sequence number (sn), and event reporting timestamp (timestamp). In related art, the response information of the event signal includes the rate (rate, in units of 10KB / s) and the RTT event detection indication (rtt_req, 1 indicates sending an RTT detection message, 0 indicates not sending an RTT detection message).

[0074] Related technologies also support hot upgrades of processing algorithms corresponding to message processing events. If a run algorithm command is executed, the algorithm may be in active, standby, stopped, or error states.

[0075] In the active state, the algorithm is the only active algorithm, receiving reported event requests and executing the corresponding event processing. In the standby state, the current algorithm is not actually running, and an active algorithm is already executing event processing. Only when the active algorithm exits, is deactivated, or an error occurs will the current standby algorithm switch to the active state. In the stopped state, the algorithm process is deactivated by the network card firmware, and the related resources are destroyed. In the error state, the current algorithm process encounters an error, and the related resources are destroyed.

[0076] However, currently, all PCC event reporting is centralized at the source (sender), while the PCC framework is not running at the destination (receiver). Consequently, the processing algorithms corresponding to message processing events have low scalability, making it difficult for users to flexibly develop receiver-driven congestion control algorithms (where the receiver informs the sender of the next congestion adjustment method).

[0077] To solve the above problems, the embodiments of the present application provide a message processing method, apparatus, device, storage medium and program product. The message processing method enables event processing at the message receiving end, so that the message receiving end supports a programmable congestion control framework and has event reporting and response capabilities, thereby effectively improving the scalability of the processing algorithm corresponding to the message processing event.

[0078] The message processing method provided in the embodiment of the present application can be applied to the application environment as shown in Figure 1. As shown in Figure 1, messages to be processed are transmitted between two message processing devices. Among them, one message processing device is a message sending end 101 (or, called a source end), and one message processing device is a message receiving end 102 (or, called a destination end). The message sending end 101 sends the message to be processed, which is forwarded by the network forwarding device 103 and sent to the message receiving end 102. Subsequently, the message receiving end 102 processes the message to be processed, generates event response information, and feeds it back to the message sending end 101 only through the network forwarding device 103.

[0079] The to-be-processed messages sent by the message sending end 101 may include data messages and probe request messages. The probe request messages include, but are not limited to, RTT probe requests, network telemetry (Telemetry, such as INT or IFA) probe requests, bandwidth probe requests, window probe requests, credit probe requests, token probe requests, etc.

[0080] The event response information sent by the message receiving end 102 can be an Acknowledgement (ACK) message, a Negative Acknowledgement (NAK) message, a CNP message, an Explicit Congestion Notification Echo (ECN-Echo) message, and a probe response message. Probe response messages include but are not limited to RTT probe responses, network telemetry information probe responses, bandwidth probe responses, window probe responses, credit probe responses, and token probe responses.

[0081] In some embodiments, the probe request message and the probe response message can be implemented in an in-band or out-of-band format. In the in-band format, the probe request message header can be carried in the data message, and in the out-of-band format, the probe request message can be an independent message.

[0082] It should be understood that in this application, any message processing device can be both a message sender and a message receiver. For example, the same message processing device can act as a message sender when sending a message to be processed and can act as a message receiver when receiving a message to be processed.

[0083] FIG2 is a schematic diagram of the structure of a message processing device provided in an embodiment of the present application. As shown in FIG2 , the message processing device includes a receiving module, a sending module, a filtering module, and an algorithm execution module. The filtering module is connected to the receiving module, the sending module, and the algorithm execution module respectively.

[0084] After receiving a message to be processed, the receiving module can perform corresponding processing based on the message type, triggering a message processing event. A message processing event that can be triggered by the receiving module can be a message receive (RX) event. Similarly, a message processing event can be triggered by the sending module, such as a message transmit (TX) event.

[0085] For example, Table 1 is a classification table of message processing events provided in an embodiment of the present application. As shown in Table 2, when a message processing device acts as a message sending end and a message receiving end, it can trigger different message processing events.

[0086] Table 2

[0087] As shown in Table 2, when the message processing device acts as a message sender, the sending module can trigger new flow events, message sent events, RTT probe message sent events, network telemetry probe message sent events, bandwidth probe message sent events, window probe message sent events, source token request events, token probe message sent events, credit probe message sent events, and timeout events. When the message processing device acts as a message sender, the receiving module can trigger message reception confirmation events, unexpected message confirmation events, congestion notification message events, ECN response message events, RTT probe response message reception events, network telemetry information probe response message reception events, bandwidth probe response message reception events, window probe response message reception events, token probe response message reception events, and credit probe response message reception events.

[0088] Continuing with Table 2, when the message processing device acts as a message receiver, the sending module can trigger events such as the bandwidth probe response message sending event, the window probe response message sending event, the token probe response message sending event, and the credit probe response message sending event. When the message processing device acts as a message receiver, the receiving module can trigger events such as the data message receiving event, the bandwidth probe request message receiving event, the window probe request message receiving event, the token probe request message receiving event, and the credit probe request message receiving event.

[0089] The following describes various messages to be processed involved in the embodiments of the present application.

[0090] The new stream event initializes the algorithm parameters and the initial configuration of the sending module. The main data field contained in this event is the event timestamp, the granularity of which is constrained by the algorithm parameters. For example, the event timestamp can be 1 nanosecond (ns).

[0091] In some embodiments, a new flow event is reported immediately after a flow or queue pair (QP) is successfully linked. In other embodiments, a new flow event may also be reported when an established flow has no messages sent for an interval exceeding a certain threshold.

[0092] The message-sent event is used to update the send window and the number of in-flight messages. The main data fields of the message-sent event are the event timestamp and the number of sent messages. The granularity is constrained by algorithm parameters. For example, the event timestamp granularity can be 1ns, and the number of sent messages granularity can be 1B or 1 message.

[0093] In some embodiments, after the sending module has sent a certain amount of messages and cannot send new messages due to algorithm response values ​​or configuration constraints, a message sent event is reported.

[0094] The RTT Probe Message Sent event is used to notify the algorithm execution module that an RTT probe has been executed, avoiding unnecessary repeated probes. The primary data field contained in the RTT Probe Message Sent event is the event timestamp, the granularity of which is constrained by algorithm parameters. For example, the event timestamp granularity can be 1 ns.

[0095] In some embodiments, after the sending module completes sending the RTT detection message, it reports an RTT detection message sent event.

[0096] The "Network Telemetry Probe Message Sent" event notifies the algorithm execution module that a network telemetry probe has been sent, preventing unnecessary repeated probes. The primary data field in the "Network Telemetry Probe Message Sent" event is the event timestamp, whose granularity is constrained by algorithm parameters. For example, the event timestamp granularity is 1 nanosecond.

[0097] In some embodiments, after the sending module completes sending the network telemetry detection message, it reports a network telemetry detection message sent event. The network telemetry can use in-band network telemetry (INT) or in-band flow analyzer (IFA) technology.

[0098] The Bandwidth Probe Message Sent event notifies the algorithm module that a bandwidth probe has been executed, avoiding unnecessary repeated probes. The primary data field in this event is the event timestamp, whose granularity is constrained by algorithm parameters. For example, the event timestamp granularity is 1ns.

[0099] In some embodiments, after the sending module completes sending the bandwidth detection message, it reports a bandwidth detection message sent event.

[0100] The Window Probe Message Sent event notifies the algorithm module that a window probe has been executed, thus avoiding unnecessary repeated probes. The primary data field in the Window Probe Message Sent event is the event timestamp, whose granularity is constrained by algorithm parameters. For example, the event timestamp granularity is 1 ns.

[0101] In some embodiments, after the sending module completes sending the window detection message, it reports a window detection message sent event.

[0102] The source token request event is used to request the algorithm execution module to issue a new token to allow the sending module to continue executing the sending task. The main data field contained in the source token request event is the event timestamp, the granularity of which is constrained by the algorithm parameters. For example, the event timestamp granularity is 1ns.

[0103] In some embodiments, when the sending module sends a message based on the token mode and schedules the current flow to perform a sending task but no token is available, a source-end token request event is reported.

[0104] The Token Probe Message Sent event notifies the algorithm module that a token send probe has been executed, thus avoiding unnecessary repeated probes. The primary data field in this event is the event timestamp, whose granularity is constrained by algorithm parameters. For example, the event timestamp granularity is 1ns.

[0105] In some embodiments, after the sending module completes sending the token detection message, it reports a token detection message sent event.

[0106] The Credit Probe Message Sent event notifies the algorithm execution module that a token send probe has been executed, thus avoiding unnecessary repeated probes. The primary data field in this event is the event timestamp, whose granularity is constrained by algorithm parameters. For example, the event timestamp granularity is 1ns.

[0107] In some embodiments, after the sending module completes sending the credit detection message, it reports a credit detection message sent event. In other embodiments, the algorithm level can consider directly using the token detection message sent event to refer to the credit detection message sent event.

[0108] The timeout event notifies the algorithm execution module of potential message loss, enabling it to constrain subsequent message sending by generating a corresponding event response. The primary data field contained in this event is the event timestamp, whose granularity is constrained by algorithm parameters. For example, the event timestamp granularity is 1ns.

[0109] In some embodiments, when the sending module detects that a data message sent has not received an acknowledgment within a certain period of time, the sending module may retransmit the message and report a timeout event. The certain period of time may be a set time (retransmission timeout, RTO)

[0110] The message reception confirmation event is used to update the send window and the number of in-flight messages. The main data fields of this event are the event timestamp and the number of confirmed received messages (pkt_ack_num). The granularity is constrained by algorithm parameters. For example, the event timestamp granularity is 1ns, and the number of confirmed received messages granularity is 1B or 1 message.

[0111] In some embodiments, after the receiving module at the source end receives the ACK message sent by the message sending module at the destination end, it reports a message reception confirmation event.

[0112] The unexpected message acknowledgment event notifies the algorithm execution module of potential message loss, enabling it to constrain subsequent message sending behavior by generating a corresponding event response. The main data fields included in this event are the event timestamp and the number of unexpected message acknowledgments (pkt_nak_num). The granularity is constrained by algorithm parameters. For example, the event timestamp granularity is 1ns, and the unexpected message acknowledgment granularity is 1B, or 1 message.

[0113] In some embodiments, a destination-side receiving module receiving a message with an out-of-sequence packet sequence number (PSN) triggers the sending module to send a NAK message. Upon receiving the NAK message, the source-side receiving module reports an unexpected message acknowledgment event. If selective retransmission is supported, the NAK signal may include a selective acknowledgment (SACK) sub-signal.

[0114] The congestion notification message event is used to notify the algorithm execution module of potential congestion, enabling it to generate a corresponding event response to constrain subsequent message sending behavior. The main data fields contained in this event are the event timestamp and the number of aggregated CNP messages (cnp_num). The granularity is constrained by algorithm parameters. For example, the event timestamp granularity is 1ns, and the aggregated CNP message granularity is 1.

[0115] In some embodiments, upon receiving an Explicit Congestion Notification (ECN) message marked by a network forwarding device as Congestion Experienced (CE), the destination receiving module can filter the message according to ECN filtering configuration parameters. If the filtering conditions are met, the sending module is triggered to send a Congestion Notification (CNP) message. Upon receiving the CNP message, the source receiving module reports a Congestion Notification (CNP) message event. ECN CE is represented by 11 bits.

[0116] The ECN response message event notifies the algorithm execution module of potential congestion, enabling it to constrain subsequent message sending behavior by generating a corresponding event response. The main data fields included in this event are the event timestamp and the number of aggregated ECN-Echo messages (ece_num). The granularity is constrained by algorithm parameters. For example, the event timestamp granularity is 1ns, and the ece_num granularity is 1.

[0117] In some embodiments, after receiving a message marked ECN CE by a network forwarding device, the receiving module at the destination triggers the message sending module to send an ECN-Echo message. After receiving the ECN-Echo message, the receiving module at the source reports an ECN response message event.

[0118] The RTT probe response message reception event is used to notify the algorithm execution module of the currently detected RTT value and to update the algorithm runtime state information, enabling it to adjust subsequent message transmission behavior by generating corresponding event responses. The main data fields contained in this event are the probe request sending timestamp (ts_rtt_req_sent), request receiving timestamp (ts_rtt_req_recv), response sending timestamp (ts_rtt_rsp_sent), and response receiving timestamp (ts_rtt_rsp_recv). The granularity is constrained by the algorithm parameters.

[0119] In some embodiments, the filtering module can further reduce the above four data fields to two, including: rtt_fabric and rtt_host, calculated as rtt_host = ts_rtt_rsp_sent - ts_rtt_req_recv, rtt_fabric = ts_rtt_rsp_recv - ts_rtt_req_sent - rtt_host. Exemplarily, the granularity of the above data fields is 1ns.

[0120] In some embodiments, the receiving module of the source end reports an RTT probe response message reception event after receiving the RTT probe response message sent by the sending module of the destination end.

[0121] Among them, the network telemetry information detection response message reception event is used to notify the algorithm execution module of the network telemetry information currently detected, and is used to update the algorithm runtime state information so that it can adjust the subsequent message sending behavior by generating corresponding event responses. The main data fields contained in this event are the valid telemetry number (valid_telemetry_num) and the telemetry data information array (telemetry_data). Each telemetry data information includes but is not limited to: TX forwarding byte number (tx_bytes), TX timestamp (tx_timestamp), and buffer queue length (queue_length). The granularity of the above data fields is subject to the configuration constraints of the network forwarding device. For example, the granularity of tx_bytes is 1B, the granularity of tx_timestamp is 1ns, and the granularity of queue_length is 256B.

[0122] In some embodiments, the receiving module at the source end reports a network telemetry information detection response message reception event after receiving the network telemetry information detection response message sent by the sending module at the destination end.

[0123] The bandwidth probe response message reception event notifies the algorithm execution module of the currently detected available bandwidth, which is used to update the algorithm rate, enabling it to adjust subsequent message transmission behavior by generating a corresponding event response. The main data fields contained in this event are the event timestamp and the probe bandwidth size (probe_bw). The granularity is constrained by the algorithm parameters. For example, the timestamp granularity is 1ns, and the probe_bw granularity is 1MB / s.

[0124] In some embodiments, the receiving module at the source end reports the event after receiving the bandwidth detection response message sent by the sending module at the destination end.

[0125] The window probe response message reception event is used to notify the algorithm execution module of the currently detected available window size, which is used to update the algorithm's congestion window, allowing it to adjust subsequent message sending behavior by generating a corresponding event response. The main data fields contained in this event are the event timestamp and the probe window size (probe_wnd). The granularity is constrained by the algorithm parameters. For example, the timestamp granularity is 1ns, and the probe_wnd granularity is 1B or 1 message.

[0126] In some embodiments, the receiving module at the source end reports a window probe response message reception event after receiving the window probe response message sent by the sending module at the destination end.

[0127] The token probe response message reception event notifies the algorithm execution module of the currently detected available token size, which is used to update the algorithm's token count, enabling it to adjust subsequent message sending behavior by generating a corresponding event response. The main data fields contained in this event are the event timestamp and the probe token size (probe_token). The granularity is constrained by algorithm parameters. Typically, the timestamp granularity is 1ns, and the probe_token granularity is 1B or 1 message.

[0128] In some embodiments, the receiving module at the source end reports a token detection response message reception event after receiving the token detection response message sent by the sending module at the destination end.

[0129] The Credit Probe Response Message Receipt event notifies the algorithm execution module of the currently detected available token size, which is used to update the algorithm's token count, enabling it to adjust subsequent message sending behavior by generating a corresponding event response. The main data fields contained in this event are the event timestamp and the probe credit size (probe_credit). The granularity is constrained by algorithm parameters. Typically, the timestamp granularity is 1ns, and the probe_credit granularity is 1B or 1 message.

[0130] In some embodiments, the algorithm level may consider directly using the token probe response message reception event to refer to the credit probe response message reception event.

[0131] In some embodiments, the receiving module at the source end reports a credit probe response message reception event after receiving the credit probe response message sent by the sending module at the destination end.

[0132] The Bandwidth Probe Response Packet Sending event notifies the algorithm execution module that the bandwidth probe response has been executed, thus avoiding unnecessary repeated responses within a certain period of time. The primary data field contained in this event is the event timestamp, the granularity of which is constrained by algorithm parameters. For example, the timestamp granularity is 1ns.

[0133] In some embodiments, the sending module of the destination end reports a bandwidth detection response message sending event after sending the bandwidth detection response message.

[0134] The Window Probe Response message sending event notifies the algorithm execution module that the window probe response has been executed, thus avoiding unnecessary repeated responses within a certain period of time. The primary data field contained in this event is the event timestamp, the granularity of which is constrained by algorithm parameters. For example, the timestamp granularity is 1ns.

[0135] In some embodiments, the sending module of the destination end reports the window probe response message sending event after sending the window probe response message.

[0136] The Token Probe Response message sent event notifies the algorithm execution module that the token probe response has been executed, thus avoiding unnecessary repeated responses within a certain period of time. The primary data field contained in this event is the event timestamp, the granularity of which is constrained by algorithm parameters. For example, the timestamp granularity is 1ns.

[0137] In some embodiments, the sending module of the destination end reports the token detection response message sending event after sending the token detection response message.

[0138] The Credit Probe Response Message Sent event notifies the algorithm execution module that a credit probe response has been executed, thus avoiding unnecessary repeated responses over a period of time. The primary data field in this event is the event timestamp, whose granularity is constrained by algorithm parameters. For example, the timestamp granularity is 1ns. Alternatively, the algorithm can consider directly using the Token Probe Response Message Sent event to refer to the Credit Probe Response Message Sent event.

[0139] The data packet reception event is used to update the algorithm's running status information on the destination end to support various detection events sent by the source end. The main data fields contained in this event are the event timestamp and the number of received packets (pkt_recv_num). The granularity is constrained by the algorithm parameters. For example, the timestamp granularity is 1ns, and the pkt_recv_num granularity is 1B or 1 packet.

[0140] In some embodiments, after the receiving module at the destination end receives the data message sent by the sending module at the source end, it reports a data message reception event.

[0141] The bandwidth probe request message reception event triggers the destination's algorithm to calculate the available bandwidth and generate a bandwidth probe response. The primary data field in this event is the event timestamp, whose granularity is constrained by algorithm parameters. For example, the timestamp granularity is 1ns.

[0142] In some embodiments, after receiving the bandwidth detection request message sent by the sending module at the source end, the receiving module at the destination end reports a bandwidth detection request message reception event.

[0143] The Window Probe Request message reception event triggers the destination-side algorithm to calculate the available window size and generate a Window Probe Response. The primary data field in this event is the event timestamp, whose granularity is constrained by algorithm parameters. For example, the timestamp granularity is 1ns.

[0144] In some embodiments, after receiving the window detection request message sent by the sending module at the source end, the receiving module at the destination end reports a window detection request message reception event.

[0145] The Token Probe Request message reception event triggers the destination's algorithm to calculate the available token size and generate a Token Probe Response. The primary data field in this event is the event timestamp, whose granularity is constrained by algorithm parameters. For example, the timestamp granularity is 1ns.

[0146] In some embodiments, after receiving the token detection request message sent by the sending module at the source end, the receiving module at the destination end reports the token detection request message reception event.

[0147] The Credit Probe Request Message Received event triggers the destination algorithm to activate the credit distribution mechanism and generate a Credit Probe Response for the current or subsequent event. The primary data field in this event is the event timestamp, with a granularity constrained by algorithm parameters. For example, the timestamp granularity is 1ns. Alternatively, the algorithm can directly use the Token Probe Request Message Received event to refer to the Credit Probe Request Message Received event.

[0148] In some embodiments, after receiving the credit detection request message sent by the sending module at the source end, the receiving module at the destination end reports a credit detection request message reception event.

[0149] Continuing to refer to Figure 2, the filtering module is used to collect the initial information of the sending module and the receiving module, filter the disabled events according to the event enable information preset by the user, and pre-process the initial information of the enabled events to generate the event information of the filtered message processing event.

[0150] The preprocessing includes at least one of the following: calculation processing, cropping processing, merging processing, and discarding processing.

[0151] The algorithm execution module is used to execute the processing algorithm of the filtered message processing event according to the event information reported by the filtering module, obtain event response information, and send the event response information to the sending module through the filtering module.

[0152] In some embodiments, before the filtering module sends the event response information returned by the algorithm execution module to the sending module, it may also perform appropriate conversion processing similar to the above-mentioned preprocessing process.

[0153] In some embodiments, the sending module may adjust the message sending behavior based on the event response information. It should be understood that the embodiments of the present application do not limit how the sending module adjusts the message sending behavior. In some embodiments, adjusting the message sending behavior may include changing the sending rate or sending window size, changing the sending path priority, sending a probe request or response message, etc.

[0154] 2 , when two message processing devices transmit messages to be processed, they can be forwarded by the network forwarding device. In some embodiments, when the network forwarding device forwards the messages to be processed, it can add congestion marking information and / or network telemetry information to the messages to be processed.

[0155] For example, the congestion marking information may be an ECN mark, where a value of 1 indicates congestion, and a value of 0 indicates no congestion. The network telemetry information may be network telemetry metadata. For example, the network forwarding device may be a switch or a router.

[0156] The following describes how to execute a processing algorithm for filtering message processing events according to event information to obtain event response information.

[0157] In some embodiments, the message processing device further includes a management and control module. The management and control module may first create processing resources for the filtered message processing events and initiate an algorithm process in the algorithm execution module through a hot upgrade. Subsequently, the algorithm execution module executes the processing algorithm for the filtered message processing events in the algorithm process based on algorithm parameters and event information, obtaining event response information.

[0158] The processing resources are resources used by the algorithm process during runtime, and may include local storage space of the host for binary algorithm files corresponding to the processing algorithm, a congestion control queue (CCQ), and the like.

[0159] Figure 3 is a schematic diagram of the PCC framework endpoint operation process provided by an embodiment of the present application. As shown in Figure 3, the control module is responsible for control plane tasks, and the algorithm processing module is responsible for data plane tasks. The control module runs on the host side or the DPU side. If the control module runs on the host side, the message processing device can be a server with a DPU. If the control module runs on the DPU side, the message processing device can be the DPU itself.

[0160] The control module can first create resources and interact with the algorithm execution module to start the algorithm process through hot upgrade. Subsequently, the algorithm execution module runs the processing algorithm of the filtered message processing event in the algorithm process based on the algorithm parameters and event information to obtain the event response information.

[0161] It should be understood that the embodiments of the present application do not limit how to start the algorithm process through hot upgrade. In some embodiments, the management and control module can store the compiled file corresponding to the processing algorithm in the target storage location, so that the processor of the message processing device can start the algorithm process by obtaining and loading the compiled file in the target storage location.

[0162] The processor of the message processing device, or the message processing device itself, may be a DPU, which may include a system on a chip (SoC). The compiled file may be a compiled binary algorithm code file, and the target storage location may be a specified location under a file system path.

[0163] For example, FIG4 is a flow chart of an algorithm hot upgrade process provided by an embodiment of the present application. As shown in FIG4 , the PCC hot upgrade is triggered when the control module executes the startup algorithm process. When the host-side control module executes the startup algorithm process, it loads the compiled binary algorithm code file from the file system path specified by the function parameter to a specific location in the host memory and notifies the SoC of the memory address and size. After receiving the memory address and size of the algorithm file, the SoC reads the contents of the binary algorithm code file through direct memory access operations and obtains it from the SoC local memory.

[0164] The SoC then records the binary algorithm code file into the firmware to persist the algorithm version. The SoC determines whether an algorithm process is currently running. If so, it loads the new algorithm from the firmware, switches the algorithm instruction data in the instruction cache to the new algorithm instruction data, and then executes the subsequent process to start the algorithm.

[0165] In some embodiments, the above-mentioned switching scheme uses a dual instruction cache mechanism. The new algorithm instruction data does not overwrite the algorithm instruction data being run, but is placed in the standby instruction cache. Only when the new algorithm instruction data is completely loaded, the SoC switches to the standby instruction cache, making it the default instruction cache, and the original instruction cache is downgraded to the standby instruction cache. If there is no running algorithm process, the binary algorithm code file is directly loaded into the default instruction cache to execute the algorithm process. Subsequent events are processed by the new algorithm process and a response is generated and returned to the message processing module. Finally, the SoC also needs to burn the algorithm binary file into the firmware to persist the algorithm version.

[0166] In some embodiments, if the algorithm binary file is specified as a null value (NULL) when the management and control module starts the algorithm, subsequent hot upgrade actions may not be performed and the current algorithm process may be used directly. Alternatively, the binary algorithm code file (if any) in the default path may be used to perform subsequent hot upgrade actions.

[0167] In this application, based on the hot upgrade mechanism, it supports imperceptible algorithm switching, minimizing the impact on business traffic. In addition, the algorithm switch is executed when the control module loads the algorithm, eliminating the need for other tedious configuration steps, minimizing the user's learning and management costs.

[0168] It should be understood that the embodiments of the present application do not limit the above-mentioned algorithm parameters. In some embodiments, when starting the algorithm process, the default algorithm parameter configuration can be used preferentially, and the configuration of the relevant algorithm parameters can also be adjusted in real time after the algorithm is running.

[0169] After modifying the configuration of the algorithm parameters, the configuration takes effect on the network card hardware and affects the event reporting behavior.

[0170] The following describes how the control module adjusts the algorithm parameters.

[0171] In some embodiments, the management and control module obtains congestion control entries from the algorithm execution module when running the processing algorithm through the congestion control queue, and the congestion control entries include algorithm status information of the processing algorithm. Subsequently, the management and control module adjusts the algorithm parameters according to the algorithm status information.

[0172] The congestion control entry (CCE) is a user-defined data structure when implementing the algorithm code. This embodiment of the application does not limit the size and data structure of the CCE data. For example, the CCE data structure size is 32 bytes, and the CCE data structure can be as shown in Table 3.

[0173] Table 3

[0174] Exemplarily, Figure 5 is a schematic diagram of the interaction between a control module and an algorithm execution module provided in an embodiment of the present application. As shown in Figure 5, the congestion control queue (CCQ) can be a first-in-first-out queue implemented based on an array of CCE structures, which can be logically abstracted as a circular buffer on the host memory. Both the head pointer (Head) and the tail pointer (Tail) pointer move forward (to the right in the figure). If the current Head or Tail pointer is at the end of the queue, it will move to the head of the queue next time. In the initial state, both the Head and Tail pointers point to the first CCE element at the head of the queue. Record is a pre-allocated fixed-size buffer used to store Head pointer information, also on the host memory.

[0175] In some embodiments, the algorithm execution module creates a congestion control entry. Subsequently, the algorithm execution module determines whether the congestion control queue is full based on the head pointer information and tail pointer information of the congestion control queue. If the congestion control queue is not full, the algorithm execution module adds a congestion control entry to the end of the congestion control queue and flips the marking information of the congestion control queue. Finally, the management and control module retrieves the congestion control entry from the congestion control queue based on the marking information and updates the head pointer information of the congestion control queue.

[0176] For example, each time the algorithm completes an event processing, it creates a new CCE structure instance and populates its fields. It attempts to add the CCE to the end of the CCQ queue and flips the flag information (e.g., the CCE owner flag bit). Only when the CCQ queue is not full can the algorithm execution module successfully add the CCE to the CCQ and update the Tail pointer, moving it forward one position. The algorithm execution module can obtain the latest Head pointer information from the record buffer and compare it with the Tail pointer to determine whether the queue is full.

[0177] For example, the control process can periodically or poll the CCE pointed to by the head pointer in the CCQ. If the owner flag in the CCE flips, the CCE is determined to be valid data. The control module obtains this data, analyzes it, and advances the head pointer by one position. Finally, the control process also updates the head pointer information to the record based on, for example, the offset size, so that the algorithm process can calculate whether the new CCE element can be added to the CCQ queue.

[0178] The flipping of the mark information of the congestion control queue may be from 0 to 1, or from 1 to 0.

[0179] It should be understood that the embodiments of the present application do not limit how to adjust the algorithm parameters according to the algorithm status information. In some embodiments, artificial intelligence models such as machine learning or deep learning can be used to adaptively adjust the algorithm parameters according to the algorithm status information contained in the CCE, thereby achieving better congestion control effects.

[0180] In some embodiments, if the algorithm status information is abnormal, the management and control module destroys the processing resources of the filtered message processing event and exits the algorithm process.

[0181] In this application, the control module can obtain the congestion control entries of the algorithm execution module when running the processing algorithm through the congestion control queue, and then obtain the algorithm status information. Based on the algorithm status information, the algorithm parameters are adjusted and configured to the network card hardware. The algorithm parameters are then used to constrain the hardware event reporting behavior and update the algorithm behavior. In this way, users can design more intelligent algorithms.

[0182] The following describes the algorithm parameters involved in the embodiments of the present application.

[0183] In some embodiments, the algorithm parameters include granularity configuration parameters, event enable parameters, feedback enable parameters, algorithm execution parameters, and hardware configuration parameters. These algorithm parameters can affect the hardware's event reporting behavior, message sending behavior, and algorithm execution behavior.

[0184] The granularity configuration parameter is used to determine the basic unit of each data field of the event report and response. For example, Table 4 is a schematic table of granularity configuration parameters provided in an embodiment of the present application, which includes information such as the names of the various parameter names of the granularity configuration parameters.

[0185] Table 4

[0186] It should be noted that if the message processing event is a network telemetry detection message sent event, the granularity of the field depends on the network forwarding device configuration and is not constrained by the above granularity configuration parameters.

[0187] The event enable parameter is used to configure the event signal. Only when an event signal is enabled can the algorithm module receive the corresponding event information reported by the hardware, and the sending module or receiving module can process the detection request or response of the corresponding event.

[0188] In some embodiments, the event enable parameter can be set as a 32-bit data field (enable_event), where each bit corresponds to the enablement status of an event. If the bit is 1, it is enabled, and if it is 0, it is disabled, so that multiple events can be enabled at the same time.

[0189] In some embodiments, a 32-bit event drop enable data field (drop_event) may be provided, with each bit corresponding to the drop configuration of an event. A bit of 1 indicates dropability, while a bit of 0 indicates non-dropability. Only when an event is enabled does one need to pay attention to the drop enable type corresponding to the event.

[0190] Among them, the feedback enable parameter is the algorithm feedback configuration parameter, which is used to require the hardware to perform the message sending action in what form. The feedback enable parameter may include a multi-path enable parameter (multi_path_enable) and a message sending mode parameter (packet_send_mode). The multi-path enable parameter is used to indicate whether the message sending uses multiple available network paths. If enabled, different messages of the same flow can use different network paths. Otherwise, all messages of the same flow only use one fixed (default) network path. The message sending mode parameter is used to indicate how the hardware controls the speed or quantity of sending messages on a single network path. Exemplarily, the message sending mode includes a rate-based sending mode, a window-based sending mode, a token-based sending mode, or a credit-based sending mode.

[0191] In some embodiments, the multipath enabling parameters described above can support hardware multipath message sending. The sending module adjusts the message sending behavior based on the priority of each network path for message transmission and the message sending mode.

[0192] For example, when multipath support is enabled through the multipath enablement parameter, the algorithm execution module can constrain the packet transmission speed or quantity of multiple paths in response to any event. The algorithm module provides feedback including the priority and packet transmission mode of each network path. Packet transmission tasks are executed based on the corresponding priority and packet transmission mode of each path.

[0193] For example, the sending module first uses the network path with the highest priority to send the message until the path no longer meets the message sending conditions, then uses the next best network path to send the message, and so on. When all network paths can no longer send messages, the current flow needs to be suspended and wait for the next scheduling.

[0194] In some embodiments, in the rate-based sending mode, the sending module constrains message sending according to the rate value fed back by the algorithm execution module.

[0195] For example, in a rate-based sending mode, the sending module may convert the rate into a message sending interval, and the next message (or message segment) may be sent only when the calculated time interval is satisfied after the previous message (or message segment) is sent.

[0196] Exemplarily, in the rate-based sending mode, the sending module can also convert the rate into tokens through the formula token = rate * interval, and then use the token mode to constrain the message sending, where rate is the sending rate, interval is the interval time between two sending schedules, and token is the number of available tokens.

[0197] For example, in rate-based transmission mode, the message sender can determine the transmission rate based on the driver of the message receiver (meaning the message receiver notifies the message sender of the next transmission rate adjustment). (The following events must be enabled: bandwidth probe message sent event, bandwidth probe response message received event, bandwidth probe response message sent event, and bandwidth probe request message received event). That is, the message sender periodically performs bandwidth probes according to the instructions of the algorithm execution module, waits for the message receiver to send back a bandwidth probe response message, and sets the transmission rate based on the value contained in the response message and returns it to the sending module.

[0198] In some embodiments, in window-based sending mode, the sending module constrains the number of in-flight packets according to the congestion window value reported by the algorithm execution module. New packets can be sent only when the number of in-flight packets is less than the current congestion window size. Otherwise, the current flow is suspended pending the next scheduled event. Packet transmission can resume when an ACK packet updates the in-flight packet size or the algorithm module reports a larger congestion window value.

[0199] Exemplarily, the window mode can be implemented by the message receiving end driver (meaning that the message receiving end informs the message sending end of the window size to be adjusted next time) (the following events need to be enabled: window detection message sent event, window detection response message received event, window detection response message sent event, window detection request message received event), that is, the sender performs window detection periodically according to the instructions of the algorithm execution module, waits for the receiver to send back the window detection response message, and returns it to the sending module according to the value contained in the response message to set the congestion window size.

[0200] In some embodiments, in token-based transmission mode, the sending module constrains message transmission according to the token value reported by the algorithm execution module. The sending module can only execute message transmission when there is an available token and the token size is larger than the size of the message to be sent. If the token size is insufficient, a source token request event is reported to the algorithm execution module to request the issuance of a new available token. If the message sending conditions are still not met using the newly issued token, the current flow is suspended and awaits the next scheduling. The algorithm execution module responds to token issuance only after receiving a source token request event; token issuance is not requested for other events.

[0201] Exemplarily, the token mode can be implemented in a receiver-driven manner (meaning that the message receiving end informs the message sending end of the token size to be adjusted next time) (the following events need to be enabled: token detection message sent event, token detection response message received event, token detection response message sent event, token detection request message received event), that is, the sender performs token detection periodically according to the instructions of the algorithm execution module, waits for the receiver to send back the token detection response message, and returns it to the sending module based on the value contained in the response message to add the available token size.

[0202] In some embodiments, in credit-based transmission mode, the sending module constrains message transmission according to the credit value provided by the algorithm execution module. Similar to token mode, the sending module can only send messages when there is available credit and the credit is greater than the size of the message to be sent. If the credit is insufficient, the current flow must be suspended and await the next scheduling opportunity.

[0203] For example, there are two main differences between the credit-based sending mode and the token-based sending mode: first, in the credit-based sending mode, the source end needs to wait for the destination end to authorize the credit value before sending a message, while the token mode has no such constraint and can be calculated by both the source end and the destination end; second, in the credit-based sending mode, the algorithm execution module can respond to credit authorization (i.e., credit issuance) after receiving any event, and the sending module needs to accumulate the valid response credit value to limit the number of messages sent, while the token mode can only obtain a new available token after initiating a token request to the algorithm module.

[0204] Exemplarily, the credit mode can be implemented in a receiver-driven manner (meaning that the message receiving end informs the message sending end of the credit value for the next adjustment) (the following events need to be enabled: credit probe message sent event, credit probe response message received event, credit probe response message sent event, credit probe request message received event), that is, after the sender sends the credit probe message request for the first time, it waits for multiple credit probe response messages sent back by the receiver, and returns the value contained in the response message to the sending module to add the available credit size.

[0205] For example, at the algorithm level, token mode-related event signals can be used to refer to credit mode-related signals and implement the credit mode. For example, the above working mode only constrains the sending of data messages and does not constrain probe request / response messages and ACK, NAK, CNP, ECN-Echo, and other messages.

[0206] Among them, the algorithm execution parameters are configurable and adjustable parameters required for the algorithm to run, which can also be called template parameters. Different algorithms have different corresponding algorithm execution parameters. For example, Table 5 is a schematic table of the algorithm execution parameters of a Data Center Quantized Congestion Notification (DCQCN) algorithm provided in an embodiment of the present application. As shown in Table 5, users can configure the template parameters of the custom algorithm into the hardware register domain segment as needed to support real-time dynamic algorithm adjustment.

[0207] Table 5

[0208] Among them, hardware configuration parameters are other parameters that constrain the hardware message sending behavior in addition to the algorithm response value. Table 6 below lists typical hardware configuration parameters and functions. More parameters can also be introduced as needed.

[0209] Table 6

[0210] In this application, based on a large number of user-configurable algorithm configuration parameters, such as granularity configuration parameters, event enable parameters, feedback enable parameters, algorithm execution parameters and hardware configuration parameters, users can flexibly adjust parameter configurations according to actual algorithm application scenarios to support efficient development of scenario-adaptive congestion control algorithms and improve the effectiveness of the algorithms.

[0211] The following describes the event interaction model in the message processing device.

[0212] In the present application, the event interaction model in the message processing device may be a request-response model. In the request-response model, for each request reported by the filtering module, the algorithm execution module must generate a corresponding event response information.

[0213] For example, Table 7 is a schematic diagram of the structure of an event request provided in an embodiment of the present application, and Table 8 is a schematic diagram of the structure of event response information provided in an embodiment of the present application.

[0214] Table 7

[0215] Table 8

[0216] In some embodiments, the event response information is used to adjust the message sending behavior of the network path corresponding to the event response information, or the event response information is used to adjust the message sending behavior of all network paths corresponding to the message processing device.

[0217] For example, data fields numbered 5 to 13 can be added to the data structure of the event response information for each network path. That is, an event request for any network path of a flow can respond to all network paths, constraining the priorities and message sending behaviors of different network paths.

[0218] In some embodiments, event requests are exchanged between the algorithm execution module and the filtering module via an event request queue, and event response information is exchanged between the algorithm execution module and the filtering module via an event response queue.

[0219] The event request queue includes an active subqueue and a submitted subqueue. Accordingly, the filtering module sends event requests to the active subqueue. The filtering module aggregates event requests through the active subqueue. If the number of events in the submitted subqueue is greater than or equal to a first threshold, the filtering module controls the event requests in the active subqueue to block and wait until a blocking end condition is met. If the number of events in the submitted subqueue is less than the first threshold, the filtering module sends the event requests in the active subqueue to the submitted subqueue, allowing the algorithm execution module to read the event requests in the submitted subqueue.

[0220] Exemplarily, Figure 6 is a schematic diagram of the interaction between another management and control module and the algorithm execution module proposed in an embodiment of the present application. As shown in Figure 6, the event request first enters the active sub-queue and then enters the submission sub-queue. The active queue can aggregate event requests, while the event requests in the submission queue cannot be changed. The algorithm execution module only reads event requests from the submission queue, processes them and generates event response information, and puts them into the event response queue. As shown in Figure 6, the new event is the event signal of stream 1, which can be aggregated into the existing events of stream 1 in the active sub-queue. When the depth of the submission sub-queue is less than the first quantity threshold M, each new event in the active sub-queue can be put into the tail of the submission sub-queue without blocking. When the number of queues in the submission sub-queue is greater than or equal to M, the new event in the active sub-queue blocks and waits, allowing the new events of the stream to be merged until the following conditions can end the blocking and enter the submission sub-queue.

[0221] The blocking end condition includes: the number of events in the submitted subqueue is less than a first quantity threshold, or the number of events in the submitted subqueue is not full and the number of event requests in the active subqueue is greater than or equal to a second quantity threshold.

[0222] It should be understood that the embodiments of the present application do not limit the first quantity threshold and the second quantity threshold. In some embodiments, the first quantity threshold is M, and the second quantity threshold can be N, where both N and M are integers greater than 0. For example, the depth of the submission subqueue and the active subqueue can be set to 32, and M and N can be set to 16 and 24, respectively.

[0223] In some optional implementations, when the SoC on the DPU is a multi-core or multi-threaded architecture, multiple event request queues and event response queues can be implemented to improve event processing performance. Different algorithm cores can process event requests on multiple event queues in parallel.

[0224] The following describes how to aggregate event requests.

[0225] In some embodiments, after the filtering module aggregates the event requests through the active sub-queue, the filtering module may generate event information of the aggregated event requests according to the type of event aggregation.

[0226] It should be understood that event aggregation can reduce the computing power dependence on the algorithm core, reduce computing power loss, save resources and costs. This application supports both the aggregation of a single event signal of the same stream and the aggregation of multiple different event signals of the same stream.

[0227] Among them, event aggregation types include cumulative and overlay types. Cumulative type accumulates the event data field to generate event information for the aggregated event request, while overlay type directly overwrites the old value of the event data field with the new value to generate event information for the aggregated event request. For example, Table 9 is a schematic table of a single event aggregation provided in an embodiment of the present application.

[0228] Table 9

[0229] It should be noted that, during the event aggregation process, the aggregation of multiple event requests uses different data fields of the event request structure shown in Table 9, and only the event timestamp is overwritten with the latest event timestamp.

[0230] The event discarding mechanism is described below.

[0231] In some embodiments, if the number of events in the event request queue is full, the filtering module discards the event request in the event request queue according to the event discard configuration information, or the filtering module sends an indication message to the receiving module, and the indication message is used to instruct the receiving module to stop sending message processing events to the filtering module.

[0232] It should be understood that due to the limited depth of the event request queue, when the event request queue is full, if the filter module needs to report a new event, it cannot be directly added to the event request queue. It can only choose to discard the event or backpressure the upstream to stop sending new events. The above-mentioned discard configuration information can be used to discard events in the event request queue, and the above-mentioned indication information can be used to implement backpressure to stop the upstream from sending new events.

[0233] For example, selecting back pressure upstream may result in a gradual amplification of back pressure, leading to hardware event processing failure and unpredictable risks. Therefore, discard configuration information can be used to discard events. The discard configuration information can be shown in Table 10.

[0234] Table 10

[0235] In this application, based on the event aggregation and event discard mechanism, the throughput requirements of the algorithm core can be significantly reduced, thereby effectively controlling the cost of the algorithm core while supporting a large number of event signals, without the need to purchase and deploy a large number of high-performance algorithm cores.

[0236] In some embodiments, the algorithm execution module and the control module can be compiled separately. For example, FIG7 is a schematic diagram of the compilation of an algorithm execution module provided in an embodiment of the present application, and FIG8 is a schematic diagram of the compilation of a control module provided in an embodiment of the present application.

[0237] As shown in Figure 7, the algorithm module is compiled on the SoC. The user-written congestion control algorithm code (including custom .h and .c files) is linked to the static library provided by the PCC framework during compilation to generate a binary executable file. As shown in Figure 8, the control module is compiled on the host side. The user-written control code (including custom .h and .c files) is linked to the static library provided by the PCC framework during compilation to generate a binary executable file.

[0238] In some embodiments, the DPU includes a SoC, and the algorithm execution module runs on the SoC small core, wherein the SoC small core can be based on the Advanced RISC Machine (ARM) architecture or the RISC-V Instruction Set Architecture (RISC-V) architecture.

[0239] In this application, rich event signals, multiple event response feedback modes, and receiving-end event reporting and response capabilities can support users in designing more flexible and diverse algorithms, effectively ensuring the scalability of algorithm design and implementation, and supporting customers with different scenarios and business needs to select or design appropriate algorithms.

[0240] In one embodiment, as shown in FIG9 , a message processing method is provided. The method is described by taking the application of the above-mentioned message processing device as an example. The message processing device includes a receiving module, a sending module, a filtering module, and an algorithm execution module. The message processing method includes S201-S204:

[0241] S201: The receiving module receives a message to be processed and triggers a message processing event corresponding to the message to be processed according to the type of the message to be processed.

[0242] In some embodiments, before sending the event request to the algorithm execution module, the method further includes: the filtering module pre-processing the initial information of the filtered message processing event to generate event information of the filtered message processing event.

[0243] The preprocessing includes at least one of the following: calculation processing, cropping processing, merging processing, and discarding processing.

[0244] In some embodiments, the message to be processed includes congestion marking information and / or network telemetry information added by a network forwarding device, and the network forwarding device is used to forward messages between two message processing devices.

[0245] S202: The filtering module filters disabled events in the message processing events according to preset event enabling information, and sends an event request to the algorithm execution module. The event request includes event information of the filtered message processing events.

[0246] S203: The algorithm execution module executes the processing algorithm of the filtered message processing event according to the event information, obtains event response information, and sends the event response information to the sending module through the filtering module.

[0247] In some embodiments, the message processing device also includes a management and control module. Before the algorithm execution module executes the processing algorithm of the filtered message processing event based on the event information and obtains the event response information, the management and control module creates processing resources for the filtered message processing event and starts the algorithm process in the algorithm execution module through hot upgrade; the algorithm execution module runs the processing algorithm of the filtered message processing event in the algorithm process based on the algorithm parameters and event information to obtain the event response information.

[0248] In some embodiments, the management and control module obtains congestion control entries of the algorithm execution module when running the processing algorithm through the congestion control queue, and the congestion control entries include algorithm status information of the processing algorithm; the management and control module adjusts the algorithm parameters according to the algorithm status information.

[0249] In some embodiments, the algorithm execution module creates a congestion control entry; the algorithm execution module determines whether the congestion control queue is in a full queue state based on the head pointer information and tail pointer information of the congestion control queue; if the congestion control queue is not in a full queue state, the algorithm execution module adds a congestion control entry to the tail of the congestion control queue and flips the mark information of the congestion control queue; the management and control module obtains the congestion control entry in the congestion control queue based on the mark information and updates the head pointer information of the congestion control queue.

[0250] In some embodiments, if the algorithm status information is abnormal, the management and control module destroys the processing resources of the filtered message processing event and exits the algorithm process.

[0251] In some embodiments, the algorithm parameters include granularity configuration parameters, event enable parameters, feedback enable parameters, algorithm execution parameters, and hardware configuration parameters.

[0252] S204: The sending module adjusts the message sending behavior according to the event response information.

[0253] In some embodiments, the event response information includes the priority of the network path for each message transmission and the message sending mode; the sending module adjusts the message sending behavior according to the priority of the network path for each message transmission and the message sending mode.

[0254] The message sending mode includes a rate-based sending mode, a window-based sending mode, a token-based sending mode, or a credit-based sending mode.

[0255] In some embodiments, the event response information is used to adjust the message sending behavior of the network path corresponding to the event response information, or the event response information is used to adjust the message sending behavior of all network paths corresponding to the message processing device.

[0256] In some embodiments, event requests are exchanged between the algorithm execution module and the filtering module via an event request queue, and event response information is exchanged between the algorithm execution module and the filtering module via an event response queue.

[0257] In some embodiments, the event request queue includes an active sub-queue and a submitted sub-queue.

[0258] Sending an event request to the algorithm execution module includes: the filtering module sending the event request to the active sub-queue; the filtering module aggregating the event requests through the active sub-queue; if the number of events in the submission sub-queue is greater than or equal to a first quantity threshold, the filtering module controlling the event requests in the active sub-queue to block and wait until a blocking end condition is met; the blocking end condition includes: the number of events in the submission sub-queue is less than the first quantity threshold, or the number of events in the submission sub-queue is not full and the event requests in the active sub-queue are greater than or equal to a second quantity threshold; if the number of events in the submission sub-queue is less than the first quantity threshold, the filtering module sending the event requests in the active sub-queue to the submission sub-queue, so that the algorithm execution module reads the event requests in the submission sub-queue.

[0259] In some embodiments, the filtering module generates event information of the aggregated event request according to the type of event aggregation; wherein the types of event aggregation include cumulative type and overlay type.

[0260] In some embodiments, if the number of events in the event request queue is full, the filtering module discards the event request in the event request queue according to the event discard configuration information, or the filtering module sends an indication message to the receiving module, and the indication message is used to instruct the receiving module to stop sending message processing events to the filtering module.

[0261] The message processing method provided in an embodiment of the present application is applied to a message processing device, which includes a receiving module, a sending module, a filtering module, and an algorithm execution module. The receiving module receives a message to be processed and, based on the type of the message to be processed, triggers a message processing event corresponding to the message to be processed. The filtering module filters out disabled events in the message processing events based on preset event enable information and sends an event request to the algorithm execution module, wherein the event request includes event information of the filtered message processing events. The algorithm execution module executes a processing algorithm for the filtered message processing events based on the event information, obtains event response information, and sends the event response information to the sending module through the filtering module. The sending module adjusts the message sending behavior based on the event response information. Since the message processing device can include a message receiving end, event processing is performed at the message receiving end, so that the message receiving end supports a programmable congestion control framework and has event reporting and response capabilities, thereby effectively improving the scalability of the processing algorithm corresponding to the message processing event.

[0262] It should be understood that, although the steps in the flowcharts of the above embodiments are shown in sequence as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be performed in other orders. Moreover, at least a portion of the steps in the flowcharts of the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily performed at the same time, but can be performed at different times. The execution order of these steps or stages is not necessarily to be performed in sequence, but can be performed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0263] Based on the same inventive concept, embodiments of the present application further provide a message processing device for implementing the aforementioned message processing method. The implementation solution provided by the device is similar to the implementation solution described in the aforementioned method. Therefore, the specific limitations of one or more message processing device embodiments provided below can be found in the above-mentioned limitations of the message processing method and will not be repeated here.

[0264] In one embodiment, as shown in FIG10 , a message processing device 300 is provided, including: a receiving module 301 , a sending module 302 , a filtering module 303 and an algorithm execution module 304 .

[0265] The receiving module 301 is configured to receive a message to be processed and trigger a message processing event corresponding to the message to be processed according to the type of the message to be processed.

[0266] The filtering module 302 is configured to filter disabled events in the message processing events according to preset event enabling information, and send an event request to the algorithm executing module 303 , wherein the event request includes event information of the filtered message processing events.

[0267] The algorithm execution module 303 is used to execute the processing algorithm of the filtered message processing event according to the event information, obtain event response information, and send the event response information to the sending module 304 through the filtering module 302.

[0268] The sending module 304 is configured to adjust the message sending behavior according to the event response information.

[0269] Each module in the above-mentioned message processing device can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in the computer device in the form of software, so that the processor can call and execute the corresponding operations of each module.

[0270] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be shown in Figure 11. The computer device includes a processor, a memory, an input / output interface (I / O), and a communication interface. The processor, memory, and input / output interface are connected via a system bus, and the communication interface is connected to the system bus via the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a message processing method is implemented. The computer device may also include a DPU chip.

[0271] Those skilled in the art will understand that the structure shown in FIG11 is merely a block diagram of a portion of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different arrangement of components.

[0272] In one embodiment, a chip is provided, wherein the chip includes the above-mentioned message processing device. The chip may be a DPU chip.

[0273] In one embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor implements the above-mentioned message processing method when executing the computer program.

[0274] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the above-mentioned message processing method is implemented.

[0275] In one embodiment, a computer program product is provided, including a computer program, which implements the above-mentioned message processing method when executed by a processor.

[0276] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, database or other media used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processor involved in the various embodiments provided herein may be, but are not limited to, a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic unit, a data processing logic unit based on quantum computing, and the like.

[0277] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0278] The above embodiments merely illustrate several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art may make various modifications and improvements without departing from the spirit of the present invention, all of which fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A message processing method, characterized in that: Applied to a message processing device, the message processing device includes a receiving module, a sending module, a filtering module and an algorithm execution module, and the method includes: The receiving module receives the message to be processed and triggers a message processing event corresponding to the message to be processed according to the type of the message to be processed; The filtering module filters the disabled events in the message processing events according to the preset event enabling information, and sends an event request to the algorithm execution module, wherein the event request includes event information of the filtered message processing events; The algorithm execution module executes the processing algorithm of the filtered message processing event according to the event information to obtain event response information, and sends the event response information to the sending module through the filtering module; The sending module adjusts the message sending behavior according to the event response information.

2. The method according to claim 1, characterized in that Before sending the event request to the algorithm execution module, the method further includes: The filtering module pre-processes the initial information of the filtered message processing event to generate event information of the filtered message processing event; The preprocessing includes at least one of the following: calculation processing, clipping processing, merging processing, and discarding processing.

3. The method according to claim 1 or 2, characterized in that The message to be processed includes congestion marking information and / or network telemetry information added by a network forwarding device, and the network forwarding device is used to forward messages between two message processing devices.

4. The method according to any one of claims 1 to 3, characterized in that The message processing device further includes a management and control module. Before the algorithm execution module executes the processing algorithm of the filtered message processing event according to the event information and obtains event response information, the method further includes: The control module creates processing resources for the filtered message processing events and starts the algorithm process in the algorithm execution module through hot upgrade; The algorithm execution module executes the processing algorithm of the filtered message processing event according to the event information to obtain event response information, including: The algorithm execution module runs the processing algorithm of the filtered message processing event in the algorithm process according to the algorithm parameters and the event information to obtain the event response information.

5. The method according to claim 4, characterized in that After the control module creates processing resources for the filtered message processing events and starts the algorithm process in the algorithm execution module through hot upgrade, the method further includes: The management and control module obtains, through the congestion control queue, a congestion control entry of the algorithm execution module when running the processing algorithm, wherein the congestion control entry includes algorithm status information of the processing algorithm; The control module adjusts the algorithm parameters according to the algorithm status information.

6. The method according to claim 5, characterized in that The control module obtains, through the congestion control queue, a congestion control entry when the algorithm execution module runs the processing algorithm, including: The algorithm execution module creates the congestion control entry; The algorithm execution module determines whether the congestion control queue is in a full queue state according to the head pointer information and the tail pointer information of the congestion control queue; If the congestion control queue is not in a full queue state, the algorithm execution module adds the congestion control entry to the end of the congestion control queue and flips the mark information of the congestion control queue; The management and control module obtains the congestion control entry in the congestion control queue according to the marking information, and updates the head pointer information of the congestion control queue.

7. The method according to claim 5 or 6, characterized in that After the control module obtains, through the congestion control queue, the algorithm state information of the algorithm process when running the processing algorithm, the method further includes: If the algorithm status information is abnormal, the management and control module destroys the processing resources of the filtered message processing event and exits the algorithm process.

8. The method according to any one of claims 4 to 7, characterized in that: The algorithm parameters include granularity configuration parameters, event enable parameters, feedback enable parameters, algorithm execution parameters and hardware configuration parameters.

9. The method according to claim 1, characterized in that The event response information includes the priority of the network path for each message transmission and the message sending mode; The sending module adjusts the message sending behavior according to the event response information, including: The sending module adjusts the message sending behavior according to the priority of the network path for each message transmission and the message sending mode; The message sending mode includes a rate-based sending mode, a window-based sending mode, a token-based sending mode or a credit-based sending mode.

10. The method according to claim 1 or 9, characterized in that The event response information is used to adjust the message sending behavior of the network path corresponding to the event response information, or the event response information is used to adjust the message sending behavior of all network paths corresponding to the message processing device.

11. The method according to claim 1, wherein The event request is exchanged between the algorithm execution module and the filtering module via an event request queue, and the event response information is exchanged between the algorithm execution module and the filtering module via an event response queue.

12. The method according to claim 11, characterized in that The event request queue includes an active subqueue and a submitted subqueue; The sending of the event request to the algorithm execution module includes: The filtering module sends the event request to the active sub-queue; The filtering module aggregates the event requests through the active subqueue; If the number of events in the submission subqueue is greater than or equal to a first number threshold, the filtering module controls the event requests in the active subqueue to block and wait until a blocking end condition is satisfied; the blocking end condition includes: the number of events in the submission subqueue is less than the first number threshold, or the number of events in the submission subqueue is not full and the number of event requests in the active subqueue is greater than or equal to a second number threshold; If the number of events in the submission subqueue is less than a first number threshold, the filtering module sends the event requests in the active subqueue to the submission subqueue, so that the algorithm execution module reads the event requests in the submission subqueue.

13. The method according to claim 12, characterized in that After the filtering module aggregates the event requests through the active subqueue, the method further includes: The filtering module generates event information of the aggregated event request according to the type of the event aggregation; wherein the type of the event aggregation includes an accumulation type and an overlay type.

14. The method according to claim 11 or 12, characterized in that The method further comprises: If the number of events in the event request queue is full, the filtering module discards the event request in the event request queue according to the event discard configuration information, or the filtering module sends an indication message to the receiving module, and the indication message is used to instruct the receiving module to stop sending the message processing event to the filtering module.

15. The method according to claim 11 or 12, characterized in that The starting of the algorithm process in the algorithm execution module by hot upgrading includes: The management and control module stores the compiled file corresponding to the processing algorithm in a target storage location, so that the processor of the message processing device starts the algorithm process by obtaining and loading the compiled file in the target storage location.

16. A message processing device, characterized in that: The message processing device includes a receiving module, a sending module, a filtering module and an algorithm execution module; The receiving module is used to receive a message to be processed and trigger a message processing event corresponding to the message to be processed according to the type of the message to be processed; The filtering module is configured to filter the disabled events in the message processing events according to the preset event enabling information, and send an event request to the algorithm execution module, wherein the event request includes event information of the filtered message processing events; The algorithm execution module is configured to execute the processing algorithm of the filtered message processing event according to the event information, obtain event response information, and send the event response information to the sending module through the filtering module; The sending module is used to adjust the message sending behavior according to the event response information.

17. A chip, characterized in that: The chip includes the message processing device according to claim 16.

18. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 15 are implemented.

19. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 15 are implemented.

20. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 15 are implemented.

Images