Task ownership negotiation method and system between an intelligent network card and a host

Abstract

The application provides a task attribution negotiation method and system between an intelligent network card and a host. A target negotiation link is established through an out-of-band management channel, and real-time hardware resource state information (programmable processing unit, pipeline slot, storage capacity, and hardware acceleration engine load) of the intelligent network card is received. In response to a negotiation signal triggered by a data flow feature, a task allocation proposal is generated in combination with a data flow identifier, an observation feature, and a host self-computing resource state, and is sent to the intelligent network card through the target negotiation link, so as to evaluate the proposal according to a real-time resource state and return response information containing acceptance, rejection, or degradation semantics. The host sends a confirmation packet after receiving the acceptance or degradation response, and completes the task attribution negotiation this time after a successful response. The application realizes real-time and dynamic negotiation between a host CPU and an intelligent network card about data processing responsibilities, thereby solving the problem of unbalanced resource utilization and the inability to adapt to dynamic load under a static task allocation strategy.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and in particular to a method and system for negotiating task attribution between a smart network interface card (NIC) and a host. Background Technology

[0002] With the widespread application of smart network interface cards (NICs) (such as DPUs / IPUs) in data centers, they no longer only perform physical layer link establishment functions but also possess programmable processing capabilities, participating in tasks such as packet parsing, filtering, and encryption / decryption. Currently, task allocation between hosts and smart NICs generally adopts static configuration or coarse-grained offloading strategies based on preset rules, lacking the ability to perceive the real-time computing resource status of both parties. When business traffic surges, static allocation can easily lead to NIC processing unit overload and packet loss, or host CPU idleness and resource waste. At the same time, the differentiated requirements of different data streams for latency, throughput, and determinism cannot be reflected in task allocation, and dynamic and fine-grained task scheduling cannot be performed based on the real-time resource status of hosts and smart NICs and the differentiated requirements of data streams, making it difficult to balance overall resource utilization efficiency and service quality (QoS). Summary of the Invention

[0003] The purpose of this application is to provide a method and system for negotiating task ownership between a smart network interface card (NIC) and a host, so as to alleviate the aforementioned technical problems existing in the prior art.

[0004] In a first aspect, the present invention provides a method for task attribution negotiation between a smart network interface card (NIC) and a host, executed by the host side, the method comprising: A target negotiation link is established with the smart network card through an out-of-band management channel, and the real-time hardware resource status information sent by the smart network card is received; wherein, the real-time hardware resource status information includes the number of idle programmable processing cores, the available slots of configurable pipeline stages, the on-chip storage margin, and the current load status of the hardware acceleration engine. In response to a negotiation trigger signal generated when the data stream characteristics meet preset trigger conditions, a task allocation proposal is generated based on the identification information of the data stream, observation characteristics, and the computing resource status of the host itself. The task allocation proposal is sent to the smart network card through the target negotiation link, and the response information returned by the smart network card is received; the response information is generated after evaluating the task allocation proposal based on the real-time hardware resource status information of the smart network card, and has acceptance, rejection or degradation semantics. Upon receiving a response message with acceptance or degradation semantics, an acknowledgment message is sent to the smart network card. When the confirmation message is successfully received and responded to by the smart network card, it is determined that the task allocation proposal and response have reached an agreement, and the task attribution negotiation is completed.

[0005] In an optional implementation, the negotiation trigger signal generated in response to data stream characteristics satisfying a preset trigger condition includes: Real-time acquisition of the connection number change rate of the ingress data stream, application layer protocol identifier, packet length distribution offset, and throughput fluctuation amplitude per unit time; When the rate of change of the number of connections exceeds a preset rise threshold, or the application layer protocol identifier matches a preset sensitive protocol set, or the packet length distribution offset reaches a preset dispersion threshold, or the throughput fluctuation amplitude per unit time is greater than a preset mutation coefficient, it is determined that the preset triggering condition is met, and the negotiation trigger signal is generated. The negotiation trigger signal includes: a five-tuple identifier information carrying the data stream; and the current bandwidth utilization rate, average connection duration, and packet loss frequency in the recent preset time period of the data stream.

[0006] In an optional implementation, in response to a negotiation trigger signal generated when data stream characteristics meet preset trigger conditions, a task allocation proposal is generated based on the data stream's identification information, observation characteristics, and the host's own computing resource status, including: Read the current CPU idle rate, remaining memory bandwidth, and interrupt handling queue length on the host side; The observed features of the data stream are jointly modeled with the current CPU idle rate, remaining memory bandwidth ratio, and interrupt handling queue length on the host side to generate a candidate set of task types; Select at least one processing task from the candidate set of task types, wherein the processing task is selected from one or more of the following: unpacking and parsing, first packet firewall filtering, connection state tracking and synchronization, and TCP stream reassembly. Set a corresponding latency tolerance threshold and task execution priority for each selected processing task; A task allocation proposal is generated based on the selected processing task, the latency tolerance threshold, and the task execution priority.

[0007] In an optional implementation, the task allocation proposal further includes: For each selected processing task, mark its original processing path identifier on the host side. The latency tolerance threshold is determined by mapping the data stream to the deterministic service level requirements of the service type to which it belongs.

[0008] In an optional implementation, receiving the response information returned by the smart network card includes: When the response information is a degradation semantic, the set of acceptable subtasks indicated by the response information and the corresponding adjusted latency tolerance threshold are parsed. The set of acceptable subtasks is generated by the smart network interface card (NIC) based on a comprehensive evaluation of the number of idle programmable processing cores, available slots in the configurable pipeline stages, on-chip storage capacity, and the current load status of the hardware acceleration engine.

[0009] In an optional implementation, sending an acknowledgment message to the smart network interface card includes: After receiving the response information corresponding to the acceptance or degradation semantics, verify whether the network card resource status snapshot timestamp contained in the response information is within a preset time window; If it is within the time window, an acknowledgment message carrying a consensus summary is constructed and sent; wherein, the consensus summary includes the finally determined data stream identifier, the actual list of processing tasks allocated to the network card side, the latency tolerance threshold and execution priority of each task.

[0010] In an optional implementation, the method further includes: After completing the task attribution negotiation, periodic status monitoring will be initiated. When the actual end-to-end latency of the smart network card processing the data stream continuously exceeds the latency tolerance threshold, or the host-side CPU idle rate increases to above the preset leniency threshold, or the hardware acceleration engine load state of the smart network card changes from not overloaded to overloaded, the negotiation trigger signal is regenerated to trigger a new round of task affiliation negotiation.

[0011] Secondly, the present invention provides a task attribution negotiation method between a smart network interface card (NIC) and a host, executed by the smart NIC, the method comprising: A target negotiation link is established with the host through an out-of-band management channel, and real-time hardware resource status information is sent to the host; wherein, the real-time hardware resource status information includes the number of idle programmable processing cores, the available slots of configurable pipeline stages, the on-chip memory margin, and the current load status of the hardware acceleration engine. The task allocation proposal is received from the host through the target negotiation link; the task allocation proposal is generated based on the identification information and observation characteristics of the data stream, and includes the type of task to be unloaded, the corresponding latency tolerance threshold, and the priority. Based on the real-time hardware resource status information, the task allocation proposal is evaluated, a response message with accept, reject, or downgrade semantics is generated, and the response message is sent to the host through the target negotiation link; After receiving the acknowledgment message from the host, return an acknowledgment response to the host; When the confirmation response is successfully received by the host, it is determined that the task allocation proposal and the response have reached an agreement, and the task attribution negotiation is completed.

[0012] Thirdly, the present invention provides a task attribution negotiation system between a smart network interface card (NIC) and a host, comprising a host and a smart NIC, wherein the host is used to execute the task attribution negotiation method between the smart NIC and the host as described in any of the foregoing embodiments, and the smart NIC is used to execute the task attribution negotiation method between the smart NIC and the host as described in the foregoing embodiments.

[0013] Fourthly, the present invention provides a computer-readable storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the task attribution negotiation method between the smart network card and the host as described in the aforementioned embodiments.

[0014] The task attribution negotiation method and system between the smart network interface card (NIC) and the host provided in this application establishes a target negotiation link through a dedicated out-of-band management channel, achieving physical or logical isolation between control signaling and data plane traffic. This avoids contention for bandwidth resources with service data, thereby ensuring the real-time performance and reliability of control command transmission. The host receives real-time hardware resource status information reported by the smart NIC, including the utilization rate of the intelligent computing unit core, pipeline slot occupancy, on-chip memory usage, and the load status of various acceleration engines. This enables precise perception of fine-grained resource usage within the NIC, overcoming the resource blind spot problem in traditional static configuration modes. Resource scheduling proposals are generated based on data flow identifiers and observation characteristics, supporting differentiated offloading decisions at the data flow granularity level, avoiding indiscriminate offloading of all traffic. Response information includes semantics such as accept, reject, or downgrade. All proposals are generated based on real-time resource assessment results from both parties, ensuring that task allocation strictly matches the current instantaneous carrying capacity of the host and the NIC. A three-phase confirmation mechanism is introduced to prevent data path configuration errors caused by inconsistent states. Through the above mechanism, a closed-loop, verifiable, and load-aware dynamic task reallocation capability is built between the host and the smart network card, which effectively improves the pooling utilization efficiency of heterogeneous computing resources and ensures the service quality and stability of critical services. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0016] Figure 1 A flowchart illustrating a task attribution negotiation method between a smart network interface card (NIC) and a host, provided as an embodiment of this application; Figure 2A flowchart illustrating another task attribution negotiation method between a smart network interface card (NIC) and a host, provided in an embodiment of this application; Figure 3 This application provides a structural diagram of a task attribution negotiation system between a smart network card and a host, as illustrated in an embodiment of the present application. Figure 4 This is a flowchart illustrating a specific task attribution negotiation method between a smart network interface card (NIC) and a host, as provided in an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0018] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0019] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0020] This application provides a method for task attribution negotiation between a smart network interface card (NIC) and a host, which is executed on the host side. See [link to relevant documentation]. Figure 1 As shown, the method mainly includes the following steps: S110 establishes a target negotiation link with the smart network card through an out-of-band management channel and receives real-time hardware resource status information sent by the smart network card. The real-time hardware resource status information includes the number of idle programmable processing cores, the available slots of configurable pipeline stages, the on-chip memory margin, and the current load status of the hardware acceleration engine.

[0021] The aforementioned out-of-band management channel is an independent control channel distinct from the PCIe data plane forwarding path. It is implemented using the MCTPover PCIe VDM or NC-SI protocol to ensure that negotiation messages do not compete for bandwidth with service data, guaranteeing the determinism and timeliness of control command transmission. Real-time hardware resource status information specifically refers to fine-grained indicators actively reported by the smart network interface card (NIC) that reflect the instantaneous availability of its internal programmable computing resources. These include the number of currently idle cores of the programmable processing unit, the unoccupied processing stage slots in the configurable pipeline, the remaining available capacity of on-chip memory, and the queue depth and real-time load rate of hardware acceleration engines (such as encryption / decryption and regular expression matching units). This information constitutes the objective and sole basis for subsequent dynamic task decisions, exceeding the scope of traditional physical layer automatic negotiation parameters.

[0022] In this embodiment, after the smart network card is inserted into the host PCIe slot and completes power-on initialization, the host-side driver and the management firmware on the smart network card establish a logical target negotiation link through an out-of-band management channel. This out-of-band management channel is specifically implemented using the MCTP over PCIe VDM (Manufacturer Custom Message) protocol or the NC-SI (Network Controller Sideband Interface) protocol. Its physical bearer is still the PCIe bus, but logically it is independent of the data forwarding path, does not occupy DMA bandwidth, and does not pass through the host kernel network protocol stack. The smart network card uses its local hardware monitoring unit to collect real-time data on the number of idle programmable processing cores, unused processing stage slots in the configurable pipeline, the remaining available capacity of on-chip memory, and the queue depth and current load rate of hardware acceleration units such as encryption / decryption engines and regular expression matching engines. This information is then structured and encapsulated into a capability description vector, which is sent unidirectionally to the host side via this target negotiation link. The host side receives and parses this vector to obtain the precise resource availability of the smart network card for data processing tasks.

[0023] S120, in response to the negotiation trigger signal generated when the data flow characteristics meet the preset trigger conditions, generates a task allocation proposal based on the data flow identification information, observation characteristics and the host's own computing resource status.

[0024] The aforementioned data flow characteristics satisfy the preset triggering conditions, using observable business behavior mutations at the data flow level as the basis for negotiation initiation. These include abnormally high connection establishment rates, concentrated occurrences of specific application layer protocols (such as TLS 1.3 and HTTP / 2), and significant changes in average packet length and distribution variance, achieving event-driven rather than periodic polling-based proactive negotiation. The essence of the task allocation proposal is to define the functional boundary division of a data flow between the host and the smart network interface card. Its generation must synchronously combine the five-tuple identifier of the data flow, the extracted observation features, and real-time resource status on the host side, such as CPU idle rate, memory bandwidth utilization, and soft interrupt processing latency, reflecting the refined decision-making logic of bidirectional load balancing.

[0025] In one implementation, the smart network interface card (NIC) mirrors or samples the incoming data stream in real time, extracting a five-tuple consisting of the source IP address, destination IP address, source port number, destination port number, and transport layer protocol type for each data stream as identification information. It also statistically analyzes observational characteristics such as the connection establishment rate per unit time, the frequency of occurrence of specific application layer protocols (e.g., TLS 1.3, HTTP / 2), average packet length and its variance, and the duration of burst traffic. When the combination of the above observational characteristics of any data stream matches a rule in a preset triggering policy table, the smart NIC generates a negotiation trigger signal. The preset triggering policy table is stored locally on the smart NIC, and examples of rules include: "HTTPS connection count increases by more than 200% within 5 seconds," "TLS 1.3 handshake packet percentage exceeds 80% for 3 consecutive seconds," and "Average packet length suddenly increases from 64 bytes to 1500 bytes with a variance increase of more than 5 times."

[0026] After receiving the trigger signal, the host side combines the five-tuple identifier of the data stream, all observed features, and the host's own current resource status such as CPU idle rate, memory bandwidth utilization, and soft interrupt processing latency to generate a specific task allocation proposal. The proposal clearly defines the boundaries of data processing responsibilities, for example: "The TLS handshake key negotiation and record decryption of the data stream are offloaded to the smart network card hardware encryption engine, while the host side retains HTTP message parsing and application logic processing."

[0027] S130, a task allocation proposal is sent to the smart network card through the target negotiation link, and the response information returned by the smart network card is received; the response information is generated after evaluating the task allocation proposal based on the real-time hardware resource status information of the smart network card, and has acceptance, rejection or degradation semantics.

[0028] The key semantic innovation of this invention's negotiation protocol lies in the acceptance, rejection, or degradation semantics of the response information. It is not a simple binary response, but a structured feedback carrying the results of hierarchical decision-making under resource constraints. Based on the real-time hardware resource status information of the smart network interface card, the evaluation explicitly limits the sole input for response generation to the fine-grained hardware load data received by S110. Specifically, it must verify the availability of the resources required in the proposal item by item, based on the current number of idle SCU cores, available pipeline slots, on-chip memory availability, and acceleration engine queue status, ensuring that the response possesses verifiable load awareness capabilities.

[0029] In practical implementation, the host encapsulates the task allocation proposal generated by S120 into an "INVITE" message according to the improved SIP protocol format, which carries the Call-ID, CSeq, Via header field, and proposal body. This message is sent to the smart NIC via the target negotiation link established by S110. After receiving the message, the smart NIC calls the latest synchronized real-time hardware resource status obtained in S110 to perform availability verification on the processing unit specified in the proposal: if the proposal requires the use of a certain SCU core, it checks whether the core is currently idle; if it requires the use of a certain programmable pipeline, it checks whether the corresponding processing stage slot is available; if it requires the use of a certain hardware acceleration engine, it checks whether its input queue depth is below the threshold. If all required resources are met, the smart network interface card (NIC) returns a "200 OK" response, which means "accept". If any resource is unavailable, it returns a "486 Busy Here" response, which means "reject". If only some resources are available, it returns a custom "420 Downgraded" response, which means "downgrade", and explicitly states the acceptable range of subtasks in the response body, such as: "Accept TLS record decryption, do not accept handshake key negotiation".

[0030] S140, after receiving the response information corresponding to the acceptance or degradation semantics, sends an acknowledgment message to the smart network card.

[0031] The acknowledgment message is a necessary step in the SIP three-phase handshake model to achieve the final convergence of the negotiation state. Its role is to eliminate the risk of inconsistency between the two parties' states caused by network latency, packet loss, or retransmission, ensure that the host and the smart network card form a strong consensus on task ownership, and avoid data path mismatch caused by unilateral execution.

[0032] In practical applications, the host side parses the response message received by S130 and identifies its status code and semantic markers. If it is "200 OK" or "420 Downgraded", it constructs an "ACK" confirmation message that conforms to the SIP protocol. This message contains Call-ID, CSeq, and Via header fields that are completely identical to the original "INVITE" message. In the case of downgrade, the message body explicitly confirms the specific sub-tasks accepted. This ACK message is still sent to the smart NIC through the same target negotiation link to complete the final closed loop of the SIP three-phase handshake.

[0033] S150: When the acknowledgment message is successfully received and responded to by the smart network card, it is determined that the task allocation proposal and response have reached an agreement, and the task attribution negotiation is completed.

[0034] After receiving the ACK packet sent by S140, the smart NIC verifies whether its Call-ID and CSeq match the previous "200 OK" or "420 Downgraded" response. If the verification is successful, it returns a lightweight response to the host, which can be a 204 No Content status code under the HTTP protocol or an ACK frame under the MCTP protocol. After receiving the response, the host writes the five-tuple of the data stream and the negotiated task attribution relationship (e.g., "TLS record decryption → smart NIC hardware encryption engine") into the local negotiation result cache and marks it as "confirmed". At this point, the task attribution negotiation process ends, and subsequent execution rules and data path switching will be carried out according to the negotiation result.

[0035] In summary, this application establishes an independent target negotiation link through an out-of-band management channel, completely isolating control signaling from data plane traffic and preventing bandwidth contention from interfering with control commands. The smart NIC reports fine-grained resource status in real time, including the number of idle SCU cores, pipeline slot occupancy, on-chip storage availability, and the load rate of the hardware acceleration engine. The host uses this information to make task decisions, enabling task allocation to truly perceive load changes. The negotiation process is triggered by data flow characteristics, including service layer observation information such as 5-tuple identifiers, connection counts, protocol types, and packet length distribution, allowing task allocation to be based on specific events and service characteristics. The negotiation adopts an improved three-phase handshake process, including proposal, response, and confirmation. The response information carries explicit semantics of acceptance, rejection, or degradation, and the explicit response of the NIC serves as the marker of negotiation completion, ensuring that the host and NIC reach a consistent consensus on task attribution. In scenarios with dynamically changing service traffic, this mechanism can avoid NIC overload and packet loss, while reducing host CPU idleness, effectively improving the utilization rate of heterogeneous computing resources, and ensuring the deterministic service quality of critical services.

[0036] For ease of understanding, the specific implementation details of this application are explained below.

[0037] In one implementation, the negotiation trigger signal generated in response to data stream characteristics satisfying preset trigger conditions may, in specific implementation, include the following steps 1.1 and 1.2: Step 1.1: Real-time collection of the connection number change rate, application layer protocol identifier, packet length distribution offset, and throughput fluctuation amplitude of the ingress data stream.

[0038] The connection change rate is used to characterize the growth intensity of the number of newly established connections per unit time. The application layer protocol identifier is used to identify the specific high-level protocol type carried by the data stream. The packet length distribution offset is used to quantify the degree of deviation of the current packet length statistical distribution from the baseline pattern, indicating whether the traffic behavior pattern has switched. The throughput fluctuation amplitude per unit time is used to characterize the instantaneous and drastic change in the ingress bandwidth usage, reflecting the overall data flood impact intensity.

[0039] In one example, the smart network interface card (NIC) continuously mirrors the ingress data stream, counting the total number of active connections every 200 milliseconds and calculating its percentage increase compared to the previous period as the connection change rate. Simultaneously, it parses the payload fields above the data packet transport layer, extracting and labeling protocol types such as HTTP / 2, TLS 1.3, and gRPC to form application layer protocol identifiers. It performs histogram statistics on the lengths of 1000 continuously collected data packets, calculating the Kullback-Leibler divergence between the current packet length distribution and the typical web service baseline distribution, using this as the packet length distribution offset. When the Kullback-Leibler divergence exceeds 0.8, it is determined to have reached a preset dispersion threshold. It then uses a 1-second sliding window to count the ingress throughput, taking the absolute value of the difference between the current window's throughput and the previous window's throughput as a percentage of the previous window's throughput, as the throughput fluctuation amplitude per unit time.

[0040] Step 1.2: When the rate of change of the number of connections exceeds the preset rise threshold, or the application layer protocol identifier matches the preset sensitive protocol set, or the packet length distribution offset reaches the preset dispersion threshold, or the throughput fluctuation amplitude per unit time is greater than the preset mutation coefficient, it is determined that the preset triggering condition is met, and a negotiation triggering signal is generated.

[0041] The preset escalation threshold, preset sensitive protocol set, preset dispersion threshold, and preset mutation coefficient are all configurable policy parameters, stored in the smart NIC's local policy table, and set by operations and maintenance personnel according to service quality requirements. This four-choose-one logical structure ensures that the triggering mechanism has fault tolerance and comprehensive coverage.

[0042] In practical applications, the smart NIC compares the four indicators obtained in step 1.1 with the corresponding parameters in the local policy table: if the connection change rate is greater than 50% / s (this threshold can be adjusted according to the actual business model, for example, it can be set to 20% / s for DDoS protection scenarios), the condition is met; if the application layer protocol identifier belongs to a preset sensitive protocol set, which includes at least one of TLS 1.3, HTTP / 2, and gRPC, the condition is met; if the packet length distribution offset is greater than 0.8 (measured by KL divergence), the condition is met; if the throughput fluctuation per unit time is greater than 40%, the condition is met; if any condition is met, it is determined that the preset trigger condition is met, and a negotiation trigger signal is immediately generated. The above values ​​are only illustrative examples and can be dynamically configured by operations and maintenance personnel according to business service quality requirements in practical applications.

[0043] The aforementioned negotiation trigger signal includes: carrying the five-tuple identification information of the data stream (that is, the five-tuple identification information consisting of the source IP address, destination IP address, source port number, destination port number and transport layer protocol type of the data stream); and carrying the current bandwidth utilization rate of the data stream, the average connection duration, and the frequency of packet loss in the most recent preset time period (e.g., 5 seconds).

[0044] The above method collects observation features from four orthogonal dimensions: connection number change rate, application layer protocol identifier, packet length distribution offset, and throughput fluctuation amplitude per unit time. It then uses "OR" logic for combined trigger judgment. This implementation achieves full coverage identification of diverse business surge scenarios. Specifically, it can respond to session layer surges such as HTTPS connection flooding, adapt to protocol semantic changes such as intensive gRPC calls between microservices, and capture packet length pattern migrations caused by video stream access and sudden throughput changes due to DDoS attacks. The multi-dimensional feature joint judgment avoids false triggers or missed triggers caused by noise interference from single indicators, significantly improving the accuracy, robustness, and timeliness of negotiation initiation. This ensures that task allocation adjustments always closely follow real business load changes, providing high-confidence decision input for dynamic resource scheduling.

[0045] Furthermore, the negotiation trigger signal generated in response to the data flow characteristics meeting preset triggering conditions generates a task allocation proposal based on the data flow's identification information, observation characteristics, and the host's own computing resource status. In specific implementation, this may include the following steps 2.1 to 2.5: Step 2.1: Read the current CPU idle rate, remaining memory bandwidth ratio, and interrupt handling queue length on the host side.

[0046] In one implementation, after the negotiation trigger signal is generated, the negotiation agent running on the host obtains the CPU idle rate, memory bandwidth remaining ratio, and interrupt handling queue length of the host system at the current moment as basic parameters reflecting the real-time computing resource status of the host.

[0047] Step 2.2: Jointly model the observed features of the data stream with the current CPU idle rate, remaining memory bandwidth ratio, and interrupt handling queue length on the host side to generate a candidate set of task types.

[0048] Observable characteristics of data streams include sudden increases in the number of connections, the appearance of specific application protocols, changes in packet length distribution, bandwidth usage, and connection duration. During joint modeling, these observed characteristics can be combined and matched with host resource states based on pre-defined decision trees or lookup table rules to generate candidate sets.

[0049] In practice, joint modeling can take the above-mentioned observation features and the current CPU idle rate, memory bandwidth remaining ratio and interrupt handling queue length on the host side as input, query the preset decision rule table, and generate a candidate set of task types. The elements of the candidate set are selected from one or more of unpacking and parsing, first packet firewall filtering, connection state tracking and synchronization, and TCP stream reassembly.

[0050] The decision rule table above defines the mapping relationship between feature combinations and candidate tasks, for example: 1) If the CPU idle rate is high and the data stream is a large packet length (i.e., a large packet stream), then the generated candidate tasks include unpacking and parsing. 2) If the 'TLS protocol identifier matches' and the 'cryptography engine is idle', the generated candidate tasks include 'TLS encryption / decryption offload'; 3) If there is a sudden increase in the number of connections and a long interruption queue, the generated candidate tasks include the first packet firewall filtering.

[0051] Step 2.3: Select at least one processing task from the task type candidate set. The processing task is selected from one or more of the following: unpacking and parsing, first packet firewall filtering, connection state tracking and synchronization, and TCP stream reassembly.

[0052] Based on the matching relationship between the data flow service attributes and the current resource status of the host, the negotiation proxy program determines one or more processing tasks to be actually unloaded from the task type candidate set. All selected tasks belong to the aforementioned four task types.

[0053] Step 2.4: Set the corresponding latency tolerance threshold and task execution priority for each selected processing task.

[0054] The negotiation agent configures the corresponding latency tolerance threshold and task execution priority for each processing task selected in step 2.3. The latency tolerance threshold is the maximum additional processing latency that the host system is willing to accept for the offloading operation, and the task execution priority is used to indicate the relative importance of the task when it is scheduled and executed on the network card side.

[0055] Step 2.5: Generate a task allocation proposal based on the selected processing task, latency tolerance threshold, and task execution priority.

[0056] The negotiation agent combines the processing tasks selected in step 2.3, the latency tolerance thresholds set for each task in step 2.4, and the task execution priorities to form a structured task allocation proposal, and sends it to the negotiation agent on the smart network card through a dedicated negotiation channel.

[0057] Steps 2.1 to 2.5 above together constitute the task allocation proposal generation process. This enables the host to generate a clear, parameter-complete task allocation proposal that can be directly evaluated by the smart NIC when data flow characteristics trigger negotiation, based on its own real-time resource status and data flow observation characteristics. This supports the subsequent task attribution negotiation process based on the SIP three-phase handshake. This process ensures that the task offloading decision matches the actual host load status, and by binding the latency tolerance threshold to the task execution priority, the negotiation result balances processing efficiency and service quality requirements.

[0058] Furthermore, the above task allocation proposal also includes: labeling each selected processing task with its original processing path identifier on the host side, and mapping according to the deterministic service level requirements of the service type to which the data flow belongs, and determining the latency tolerance threshold.

[0059] For each selected processing task, mark its original processing path identifier on the host side. This original processing path identifier is either 'kernel protocol stack IP layer' or 'XDP program'. When generating the task allocation proposal, for each processing task selected in step 2.3, the original processing path identifier is explicitly recorded as the software module or hardware path on the host side that originally executed the task in the ununloaded state. For example, for the 'TCP stream reassembly' task, its original processing path identifier could be 'kernel protocol stack TCP / IP layer'; for the 'first packet firewall filtering' task, its original processing path identifier could be 'XDP (eXpress Data Path) hook point' or 'netfilter PREROUTING chain'.

[0060] Mapping the data stream to the deterministic service level requirements (SSR) of its business type to determine the latency tolerance threshold involves the host negotiation agent module identifying the business type of the data stream based on the five-tuple information carried in the negotiation trigger signal, and then matching the corresponding SSR to a table to obtain the latency tolerance threshold for that processing task. The business type can include financial transactions, real-time audio / video, web access, and background batch transmission. The SSR is manifested as differentiated constraints on end-to-end latency, jitter, and packet loss rate, which are stored on the host side in the form of a pre-configured policy table. The mapping process does not involve real-time calculation or dynamic adjustment; it only performs a static table lookup operation. The determined latency tolerance threshold is directly used as the value set for that processing task in step 2.4.

[0061] Furthermore, the aforementioned receipt of the response information returned by the smart network card may, in specific implementation, include the following steps 3.1 and 3.2: Step 3.1: When the response information is a degradation semantic, parse the set of acceptable subtasks indicated by the response information and the corresponding adjusted delay tolerance threshold.

[0062] After evaluating the task allocation proposal put forward by the host, if the smart network interface card (NIC) determines that it cannot fully meet the original proposal requirements, it returns a response message with degradation semantics. The response message explicitly lists one or more subtasks that can be executed under the current conditions, and provides a latency tolerance threshold determined after re-evaluation for each subtask. The host performs structured parsing on the received response message, extracts the subtask types contained therein and their corresponding adjusted latency tolerance thresholds, and uses them as the basis for generating the final acknowledgment message.

[0063] Step 3.2, the set of acceptable subtasks is generated by the smart network interface card after comprehensive evaluation based on the number of idle programmable processing cores, available slots in the configurable pipeline stages, on-chip memory capacity, and the current load status of the hardware acceleration engine.

[0064] Before generating response information, the smart NIC collects the local hardware resource status in real time, including the number of idle programmable processing cores, available slots in configurable pipeline stages, on-chip storage capacity, and the current load status of the hardware acceleration engine. These four indicators constitute the core content of the smart NIC's computing capability description vector. Based on this capability description vector, the smart NIC evaluates the execution feasibility and latency reachability of each task proposed by the host, and only includes tasks that meet resource consumption constraints and can be completed within the adjusted latency tolerance threshold into the acceptable subtask set, ensuring that there is no hardware resource contention between the selected subtasks.

[0065] Steps 3.1 and 3.2 together constitute a complete response mechanism for the degradation response, enabling the host to accurately identify the actual task range that the smart network card can bear and the corresponding service quality boundary, supporting the validity and executability of the negotiation results under dynamic resource changes.

[0066] Furthermore, the aforementioned sending of an acknowledgment message to the smart network interface card may, in specific implementation, include the following steps 4.1 and 4.2: Step 4.1: After receiving the response information corresponding to the acceptance or degradation semantics, verify whether the network card resource status snapshot timestamp contained in the response information is within the preset time window.

[0067] When generating a response message, the smart network interface card (NIC) uses the time it locally collected the hardware resource status as a snapshot timestamp and sends it along with the response message. Upon receiving the response message, the host obtains the embedded timestamp and compares it with the local system time. If the time difference is less than a threshold set by a preset time window, the resource status on which the response message is based is considered valid; otherwise, the response message is discarded and a renegotiation process is triggered. As an example, the preset time window can be set to 50ms, requiring that the resource status snapshot in the response message be collected within the most recent 50ms to ensure its validity.

[0068] Step 4.2: If it is within the time window, construct and send an acknowledgment message carrying the consensus summary; wherein, the consensus summary includes the finally determined data flow identifier, the actual list of processing tasks allocated to the network card side, the latency tolerance threshold and execution priority of each task.

[0069] After confirming the validity of the response information, the host side forms the final data flow identifier and the actual processing task list allocated to the network interface card (NIC) based on the set of acceptable subtasks explicitly listed in the response information (or the tasks that were fully accepted in the original proposal). Each task in this task list is bound to the latency tolerance threshold and execution priority confirmed in the response information. The host side organizes the above content into a negotiation consensus digest according to a predefined structure, encapsulates it into an acknowledgment message, and sends it to the smart NIC through a dedicated negotiation channel.

[0070] Steps 4.1 and 4.2 above together constitute the mechanism for generating and sending confirmation messages. Timeliness verification ensures that the negotiation decision is based on the latest resource status, avoiding the inability to execute confirmed tasks due to dynamic changes in network interface card resources. Through the transmission of structured negotiation consensus digests, the smart network interface card can unambiguously parse and implement data path switching and rule configuration, ensuring the reliable implementation of task attribution negotiation results.

[0071] In one specific embodiment, after completing the current task ownership negotiation, periodic status monitoring is initiated; when any of the following conditions are detected, a negotiation trigger signal is regenerated to trigger a new round of task ownership negotiation: (1) The actual end-to-end delay of the smart network card in processing the data stream exceeds (e.g., exceeds for three consecutive sampling periods) the delay tolerance threshold determined during the negotiation process; (2) The CPU idle rate on the host side increases to above a preset lenient threshold (for example, the preset lenient threshold can be set to 60%); (3) The load status of the hardware acceleration engine of the smart network card changes from not overloaded to overloaded.

[0072] The actual end-to-end latency refers to the complete processing latency from the moment the data stream enters the physical interface of the smart network interface card (NIC) until it is processed and delivered to the host memory or forwarding exit. This latency is continuously sampled by the monitoring module inside the smart NIC. A continuous sampling threshold is defined as each sample exceeding the latency tolerance threshold within a preset number of consecutive samplings to prevent false triggering due to momentary fluctuations. The preset leniency threshold is a CPU resource redundancy judgment benchmark set on the host side, with a value higher than the conventional idle rate threshold, used to identify situations where the host has significant takeover capability. The hardware acceleration engine load status is determined by the smart NIC in real-time monitoring of parameters such as queue depth, processing throughput saturation, and response latency of its internal acceleration units. The states of no overload and overload are binary status indicators, not relying on continuous statistics, but only based on a snapshot of the current state.

[0073] The aforementioned monitoring and renegotiation mechanism ensures that the task attribution relationship is not fixed to the initial negotiation result, but dynamically evolves with the actual operating status of both the host and the smart network card, so that the data processing responsibility always matches the current optimal computing power distribution, thereby maintaining the coordinated optimization of the overall system resource utilization and business service quality.

[0074] Based on the host-side execution method described above, this invention provides a task attribution negotiation method between a smart network interface card (NIC) and a host, executed by the smart NIC. (See [link to relevant documentation]). Figure 2 As shown, the method includes the following steps: The S210 establishes a target negotiation link with the host via an out-of-band management channel and sends real-time hardware resource status information to the host. This real-time hardware resource status information includes the number of idle programmable processing cores, available slots in configurable pipeline stages, on-chip memory availability, and the current load status of the hardware acceleration engine. The out-of-band management channel is implemented using the MCTPover PCIe VDM or NC-SI protocol, independent of the data forwarding path. The real-time hardware resource status information is periodically collected by the smart network interface card's internal firmware and encapsulated into a capability description vector, which is then pushed unidirectionally to the host via the target negotiation link.

[0075] S220: Receive a task allocation proposal sent by the host via the target negotiation link. The task allocation proposal is generated based on the identification information and observation characteristics of the data stream, and includes the type of task to be offloaded, the corresponding latency tolerance threshold, and the priority. The type of task to be offloaded is selected from one or more of unpacking and parsing, first-packet firewall filtering, connection state tracking and synchronization, and TCP stream reassembly. The latency tolerance threshold and priority are set by the host according to the service level requirements of the service type.

[0076] S230: Based on real-time hardware resource status information, evaluate the task allocation proposal, generate response information with accept, reject, or degradation semantics, and send the response information to the host through the target negotiation link; when all tasks can meet their latency tolerance thresholds and resource usage is not exceeded, generate an accept semantic response; when any task exceeds resource carrying capacity or cannot meet latency constraints, generate a reject semantic or degradation semantic response; the degradation semantic response information explicitly lists the acceptable set of subtasks and the corresponding adjusted latency tolerance thresholds.

[0077] S240: After receiving the acknowledgment message sent by the host, the smart network interface card (NIC) returns an acknowledgment response to the host. The acknowledgment message carries a consensus digest, including the final data stream identifier, the list of processing tasks actually allocated to the smart NIC, the latency tolerance threshold and execution priority of each task. The smart NIC performs integrity verification and content parsing on the received acknowledgment message. After the verification is successful, it generates an acknowledgment response and sends it back.

[0078] S250: When the acknowledgment response is successfully received by the host, it is determined that the task allocation proposal and response have reached an agreement, completing the task attribution negotiation. The agreement triggers the smart NIC control plane to update the flow table rules, directing the corresponding data flow to the designated processing unit, and simultaneously initiating periodic status monitoring of the data flow to provide status basis for possible subsequent renegotiation.

[0079] Furthermore, the present invention provides a task attribution negotiation system between a smart network interface card (NIC) and a host, comprising a host and a smart NIC. Figure 3 This diagram illustrates the structure of a specific task attribution negotiation system between a smart network interface card (NIC) and a host. Figure 4 A flowchart illustrating a specific embodiment combining a host and a smart network interface card (NIC) is shown, including the following steps: S101: Establish a consultation channel After the smart network interface card (NIC) is inserted into the host PCIe slot and powered on for initialization, the host driver and the smart NIC management firmware establish a dedicated logical target negotiation link through an out-of-band management channel (such as MCTP over PCIe VDM or NC-SI) (Vendor-Defined Messages / Network Controller-Sideband Interface). This link is independent of the regular data forwarding path and is used to exchange control plane messages. This step corresponds to... Figure 3 Component 10 (host negotiation agent module) and component 20 (network card negotiation agent module) establish an initial communication session.

[0080] S102: Report and synchronize computing capabilities.

[0081] The network interface card (NIC) negotiation proxy module 20 collects local hardware resource status information, including but not limited to: the number of currently available SCU (System Control Unit) processor cores, the number of idle slots in the programmable pipeline stage, the remaining capacity of on-chip memory, and the current load rate of the hardware acceleration engine (including encryption / decryption engine and regular expression matching engine). This information is encapsulated into a capability description vector and sent to the host negotiation proxy module 10 through the communication channel established in step S101. Simultaneously, the host system integrates its CPU idle rate, memory bandwidth utilization, interrupt handling capabilities, and other status information to generate a host capability vector.

[0082] S103: Identify data stream characteristics and generate negotiation trigger signals.

[0083] The traffic identification engine 30 of the smart network card monitors the ingress data stream in real time. When the identification engine detects that the characteristics of a certain data stream meet the conditions in the predefined triggering policy table, it generates a negotiation trigger signal. The characteristics include, but are not limited to, a sudden increase in the number of connections, the appearance of a specific application protocol, or a change in packet length distribution. The negotiation trigger signal contains the five-tuple information of the data stream and its current observation characteristics, including bandwidth usage and connection duration.

[0084] S104: Negotiation of the attribution of the task.

[0085] After the trigger signal mentioned in step S103 is responded to, the host negotiation proxy module 10 and the network card negotiation proxy module 20 enter the negotiation process; the negotiation process is based on an improved session initiation protocol model and includes a three-phase handshake of proposal, response, and confirmation: Step S1041 (Proposal): The host system proposes a preliminary allocation scheme; the scheme includes, but is not limited to: proposing to offload the unpacking and firewall filtering tasks of data flow A to the network card, while the host system retains the TCP reassembly and application layer analysis tasks; the scheme also includes the maximum latency tolerance and task priority allowed by the host system for this offloading operation.

[0086] Step S1042 (Response): The network interface card (NIC) evaluates the proposal based on the real-time remaining capacity reported in step S102; when the current load of the NIC is lower than a preset threshold, it returns an acceptance response and optionally adds suggestions, including but not limited to simultaneously unloading the connection tracking status synchronization task; when the NIC is busy, it returns a rejection response or a degradation response, including but not limited to accepting only firewall filtering tasks and not accepting unpacking tasks.

[0087] Step S1043 (Confirmation): After receiving the response, if the host system accepts the network card's suggestion, it sends a final confirmation message, and the negotiation process is completed.

[0088] S105: Issue rules and switch data paths.

[0089] After successful negotiation, the negotiation proxy module converts the consensus result into specific hardware configuration instructions. On the network card side, the control plane 40 configures flow table rules according to the instructions and guides the specified data flow to the processing unit determined by the negotiation. The processing unit includes switching from the default host CPU path to the hardware offload engine 41 or embedded processor 42 inside the network card. On the host side, the interrupt affinity settings and receiver scaling hash configuration are updated, and the reception of traffic that has been offloaded is stopped.

[0090] S106: Periodic status monitoring and renegotiation.

[0091] The processing location allocation for a data stream in a negotiated state is not fixed. The monitoring module 50 continuously samples the load changes of the network card and the host. When it detects that the delay of the network card in processing the data stream exceeds the threshold agreed in step S1041, or the CPU idle rate on the host side rises above the preset threshold, the renegotiation process is automatically triggered, and the process jumps back to step S103 to dynamically adjust the task allocation.

[0092] In summary, this invention achieves real-time, load-aware dynamic offloading decisions at the data link layer by constructing an independent negotiation channel between the smart network interface card (NIC) and the host system, introducing a dynamic capability description table and a three-phase task attribution negotiation mechanism based on an improved session initiation protocol, thus realizing "who processes what data" dynamic offloading decisions. Its beneficial effects include: overcoming the rigidity of static task partitioning and significantly improving the overall utilization rate of heterogeneous computing resources; automatically migrating data stream processing responsibilities during traffic bursts, effectively preventing packet loss due to NIC overload or idle host CPU resources; embedding latency tolerance parameters during the negotiation process, ensuring the determinism of service quality while obtaining offloading benefits, guaranteeing a smooth processing experience for low-latency services; and supporting continuous load monitoring and renegotiation mechanisms, ensuring the system has adaptive adjustment capabilities during long-term operation and improving overall robustness.

[0093] Based on the above method, this embodiment provides a task attribution negotiation protocol between a smart network interface card (NIC) and a host. The protocol defines the interaction flow and semantic structure of control plane messages, including the following three stages: Phase 1: The host sends a task allocation proposal message to the smart network card. The task allocation proposal message carries data stream identification information, the type of task to be offloaded, the corresponding latency tolerance threshold and priority. Second stage: The smart network card returns a response message to the host; the response message is generated based on the real-time hardware resource status inside the smart network card and has accept, reject or downgrade semantics; wherein, the downgrade semantics indicate conditional acceptance of some types of tasks to be unloaded and can carry adjustment suggestions for other task types. Phase 3: The host sends an acknowledgment message to the smart network interface card (NIC); the smart NIC receives the acknowledgment message and returns an acknowledgment response message; when the acknowledgment response message is successfully received by the host, it is determined that the task allocation proposal and the response message have reached an agreement, and the task attribution negotiation is completed.

[0094] This application also provides a computer-readable storage medium storing computer-executable instructions. When these computer-executable instructions are called and executed by a processor, they cause the processor to implement the task attribution negotiation method between the smart network card and the host. For specific implementation details, please refer to the foregoing method embodiments, which will not be repeated here.

[0095] The computer program product of the task attribution negotiation method and system between the smart network card and the host provided in this application embodiment includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0096] Unless otherwise specifically stated, the relative steps, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of this application.

[0097] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0098] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for negotiating task attribution between a smart network interface card (NIC) and a host, characterized in that, Executed on the host side, the method includes: A target negotiation link is established with the smart network interface card (NIC) through an out-of-band management channel, and the real-time hardware resource status information sent by the smart NIC is received. The out-of-band management channel is implemented using the MCTP over PCIe VDM protocol or the NC-SI protocol, and its physical bearer is a PCIe bus, logically independent of the data forwarding path. The real-time hardware resource status information includes the number of idle programmable processing cores, available slots in configurable pipeline stages, on-chip memory reserves, and the current load status of the hardware acceleration engine. The smart NIC collects the above information in real time based on its local hardware monitoring unit and encapsulates this information into a structured capability description vector. In response to a negotiation trigger signal generated when the data stream characteristics meet preset trigger conditions, a task allocation proposal is generated based on the identification information of the data stream, observation characteristics, and the computing resource status of the host itself. The task allocation proposal is sent to the smart network interface card (NIC) through the target negotiation link, and the response information returned by the smart NIC is received. The response information is generated after evaluating the task allocation proposal based on the real-time hardware resource status information of the smart NIC, and has accept, reject, or downgrade semantics. The task allocation proposal is encapsulated into an INVITE message according to the improved SIP protocol format, carrying Call-ID, CSeq, Via header field, and proposal body. Upon receiving a response message with acceptance or degradation semantics, an acknowledgment message is sent to the smart network card. When the confirmation message is successfully received and responded to by the smart network card, it is determined that the task allocation proposal and response have reached an agreement, and the task attribution negotiation is completed. The negotiation trigger signal generated in response to data stream characteristics meeting preset trigger conditions includes: real-time acquisition of the connection number change rate, application layer protocol identifier, packet length distribution offset, and throughput fluctuation amplitude of the ingress data stream; when the connection number change rate exceeds a preset rise threshold, or the application layer protocol identifier matches a preset sensitive protocol set, or the packet length distribution offset reaches a preset dispersion threshold, or the throughput fluctuation amplitude is greater than a preset mutation coefficient, it is determined that the preset trigger conditions are met, and the negotiation trigger signal is generated; wherein, the negotiation trigger signal includes: carrying the five-tuple identifier information of the data stream; and simultaneously carrying the current bandwidth utilization rate of the data stream, average connection duration, and packet loss frequency in the most recent preset time period; Based on the identification information and observation characteristics of the data stream, and the computing resource status of the host itself, a task allocation proposal is generated, including: reading the current CPU idle rate, remaining memory bandwidth ratio, and interrupt handling queue length on the host side; jointly modeling the observation characteristics of the data stream with the current CPU idle rate, remaining memory bandwidth ratio, and interrupt handling queue length on the host side to generate a candidate set of task types; selecting at least one processing task from the candidate set of task types, wherein the processing task is selected from one or more of unpacking and parsing, first packet firewall filtering, connection state tracking and synchronization, and TCP stream reassembly; setting a corresponding latency tolerance threshold and task execution priority for each selected processing task; and generating a task allocation proposal based on the selected processing task, the latency tolerance threshold, and the task execution priority.

2. The task attribution negotiation method between the smart network card and the host according to claim 1, characterized in that, The task allocation proposal also includes: For each selected processing task, mark its original processing path identifier on the host side. The latency tolerance threshold is determined by mapping the data stream to the deterministic service level requirements of the service type to which it belongs.

3. The task attribution negotiation method between the smart network card and the host according to claim 1, characterized in that, The response information returned by the smart network card includes: When the response information is a degradation semantic, the set of acceptable subtasks indicated by the response information and the corresponding adjusted latency tolerance threshold are parsed. The set of acceptable subtasks is generated by the smart network interface card (NIC) based on a comprehensive evaluation of the number of idle programmable processing cores, available slots in the configurable pipeline stages, on-chip storage capacity, and the current load status of the hardware acceleration engine.

4. The task attribution negotiation method between the smart network card and the host according to claim 1, characterized in that, Sending an acknowledgment message to the smart network interface card includes: After receiving the response information corresponding to the acceptance or degradation semantics, verify whether the network card resource status snapshot timestamp contained in the response information is within a preset time window; If it is within the time window, an acknowledgment message carrying a consensus summary is constructed and sent; wherein, the consensus summary includes the finally determined data stream identifier, the actual list of processing tasks allocated to the network card side, the latency tolerance threshold and execution priority of each task.

5. The task attribution negotiation method between the smart network card and the host according to claim 4, characterized in that, The method further includes: After completing the task attribution negotiation, periodic status monitoring will be initiated. When the actual end-to-end latency of the smart network card processing the data stream continuously exceeds the latency tolerance threshold, or the host-side CPU idle rate increases to above the preset leniency threshold, or the hardware acceleration engine load state of the smart network card changes from not overloaded to overloaded, the negotiation trigger signal is regenerated to trigger a new round of task affiliation negotiation.

6. A method for negotiating task attribution between a smart network interface card (NIC) and a host, characterized in that, Executed by the smart network interface card (NIC), the method includes: The smart network interface card (NIC) establishes a target negotiation link with the host through an out-of-band management channel and sends real-time hardware resource status information to the host. This real-time hardware resource status information includes the number of idle programmable processing cores, available slots in configurable pipeline stages, on-chip memory availability, and the current load status of the hardware acceleration engine. The out-of-band management channel is implemented using the MCTPover PCIe VDM protocol or the NC-SI protocol, and its physical bearer is a PCIe bus, logically independent of the data forwarding path. The smart NIC collects the above information in real time based on a local hardware monitoring unit and encapsulates this information into a structured capability description vector. The task allocation proposal is received by the host through the target negotiation link; the task allocation proposal is generated based on the identification information and observation characteristics of the data stream, and includes the type of task to be unloaded, the corresponding latency tolerance threshold and priority; wherein, the task allocation proposal is encapsulated into an INVITE message in an improved SIP protocol format, carrying Call-ID, CSeq, Via header field and proposal body; Based on the real-time hardware resource status information, the task allocation proposal is evaluated, a response message with accept, reject, or downgrade semantics is generated, and the response message is sent to the host through the target negotiation link; After receiving the acknowledgment message from the host, return an acknowledgment response to the host; When the confirmation response is successfully received by the host, it is determined that the task allocation proposal and the response have reached an agreement, and the task attribution negotiation is completed.

7. A task attribution negotiation system between a smart network interface card (NIC) and a host, characterized in that, The system includes a host and a smart network interface card (NIC), wherein the host is used to execute the task attribution negotiation method between the smart NIC and the host as described in any one of claims 1 to 5, and the smart NIC is used to execute the task attribution negotiation method between the smart NIC and the host as described in claim 6.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the task attribution negotiation method between the smart network card and the host as described in any one of claims 1 to 6.

Images