A method for DPU-based link aggregation adaptive grouping and hardware instance stabilization

Abstract

The application discloses a DPU field and relates to a link aggregation adaptive grouping and hardware instance stabilizing method based on DPU, which continuously runs a link aggregation control protocol state machine and periodically sends a protocol data unit to dynamically determine the online state of a peer end; when the peer end is online, a port in a distribution state is selected as an active member, and when the peer end is offline, all ports with up physical links are selected as active members; a hook notification structure is constructed at an edge jump of the distribution state or an overage state and is issued to a hardware driver; the hardware driver searches a hardware aggregation instance according to a stable aggregation identification key, and adds or deletes a member without releasing or rebuilding the instance. The application makes a single aggregation group compatible with two kinds of deployments of a peer end configured or not configured with a link aggregation control protocol, the hardware instance remains unchanged when the peer end dynamically switches the protocol on and off, and the instance is not rebuilt in a port hot plug process, so that technical effects of zero jitter, no bandwidth loss and no need for maintenance intervention are achieved.

Description

Technical Field

[0001] This invention relates to the field of DPU, and specifically to a DPU-based method for link aggregation adaptive grouping and hardware instance stabilization. Background Technology

[0002] A Data Processing Unit (DPU) is a new type of processor designed for data centers. It offloads the workload of the host CPU in areas such as networking, storage, security, and virtualization to the hardware, improving overall system efficiency. Link aggregation is one of the core functions of a DPU's network forwarding capabilities. By aggregating multiple physical ports into a single logical port, it provides higher bandwidth and port redundancy than a single port.

[0003] Current link aggregation offloading schemes on DPUs largely rely on the coordination between the host kernel-level IEEE 802.3ad Link Aggregation Control Protocol (LACP) and hardware forwarding devices. The protocol module pushes port activity indicators to the hardware driver via the kernel interface, and the hardware driver programs aggregation entries accordingly. However, this scheme (such as...) Figure 2 and Figure 4 The following drawbacks exist when dealing with different peer device configurations:

[0004] 1) Poor compatibility of strict protocol synchronization mode: If the peer is not running LACP, the host-side member ports cannot enter the distribution state, resulting in the aggregation interface being unavailable and all traffic being blocked.

[0005] 2) Bandwidth loss in static hash mode: If the host switches to static hash mode to be compatible with the peer not running LACP, Protocol Data Units (PDUs) will stop being sent. If the peer is in active mode, the status will be abnormal, resulting in port hanging or hashing, and the aggregated bandwidth and redundancy will be damaged.

[0006] 3) The fallback scheme is not applicable to DPU: Existing fallback schemes are mostly deployed on the switch side and only support single-port activity or port hashing, which cannot maintain multi-port aggregation semantics in DPU scenarios.

[0007] 4) Mode switching causes business jitter: Operations and maintenance need to manually switch the aggregation mode, which triggers the destruction and reconstruction of the kernel and hardware aggregation instance, resulting in the clearing of forwarding table entries and business interruption, making it impossible to cope with the dynamic switching of protocol start and stop on the other end.

[0008] Therefore, those skilled in the art provide a DPU-based link aggregation adaptive grouping and hardware instance stabilization method to solve the problems mentioned in the background art. Summary of the Invention

[0009] The technical problem this invention aims to solve is: addressing the current issues of poor compatibility of DPU link aggregation offloading under different peer protocol configurations and the need to rebuild hardware instances during runtime switching. This invention provides a hardware-software integrated optimization scheme combining DPU-based adaptive grouping of link aggregation and a hardware instance stabilization method. This ensures that the aggregation group remains continuously available during arbitrary switching of peer configurations and hot-plugging of ports, without releasing or rebuilding the hardware aggregation instance, resulting in zero service jitter and no need for maintenance intervention.

[0010] To achieve the above objectives, the present invention provides the following technical solution:

[0011] A DPU-based method for link aggregation adaptive grouping and hardware instance stabilization includes the following steps:

[0012] Step S1: Load the link aggregation protocol module and register the callback function of the hardware forwarding device driver with it, initialize the aggregation group, allocate the aggregation identifier by the protocol module and derive a stable aggregation identifier key from it, establish a mapping with the hardware aggregation instance, and obtain the aggregation group initialization parameters.

[0013] Step S2: Continuously run the link aggregation control protocol state machine on all member ports and continuously send protocol data units according to the protocol's specified period. The sending action is independent of whether the peer is running the protocol. Traverse the protocol status fields of each member port to obtain the peer's online status indication.

[0014] Step S3: Construct a set of active hardware aggregation members based on the online status indication of the peer end—select ports in the distribution state when online, and select all ports with physical links up when offline; when an edge transition occurs in the distribution state or the overdue state, or when the physical link status of a member port changes, construct a hook notification structure and send it to the hardware forwarding device driver to obtain the hardware aggregation member configuration sequence;

[0015] Step S4: The hardware forwarding device driver retrieves the hardware aggregation instance by the aggregation identifier key. If no match is found and the instance has not been added, a new hardware aggregation instance is created and a mapping is established. If a match is found, members are added or deleted from the existing hardware aggregation instance. The hardware aggregation member table and the exit hash table are programmed to obtain the hardware forwarding table entry configuration results.

[0016] Step S5: The hardware forwarding device performs outbound load balancing forwarding among active members of multiple ports according to the packet header hash value; when the peer protocol configuration is switched or the member port physical link is switched up / down, S2 to S4 are triggered again, but the aggregation identifier key remains unchanged, the hardware aggregation instance is not released or rebuilt, and the aggregation group remains available.

[0017] In step S3, the overdue state refers to the temporary state in the protocol state machine after the peer PDU has timed out.

[0018] As a further aspect of the present invention: step S1 further includes: loading the link aggregation protocol module and the DPU hardware forwarding device driver module; saving the hardware callback function pointer to the global function pointer of the protocol module through the callback registration interface predefined by the protocol module; creating an aggregation group through the user-space network configuration tool and setting its aggregation mode to the dynamic aggregation mode based on the link aggregation control protocol; allocating an aggregation identifier by the protocol module and deriving a stable aggregation identifier key, establishing a mapping relationship between the aggregation identifier key and the hardware aggregation instance in the hardware aggregation instance table; configuring the member port list, the aggregation group media access control address, and the state machine period parameters.

[0019] As a further aspect of the present invention: step S2 further includes: starting the state machine cycle of the protocol module (default 100 milliseconds), running the link aggregation control protocol state machine in each cycle, and having the cycle sub-state machine continuously send protocol data units from all physical link up member ports according to the sending cycle (1 second in fast mode, 30 seconds in slow mode), the sending action does not depend on whether the peer responds or whether the peer runs the protocol; before the end of each cycle, traversing the protocol status field of all member ports, searching whether the distribution flag bit is set on any port, if so, setting the peer online status indicator to indicate that the peer is online, otherwise setting it to indicate that the peer is offline.

[0020] As a further aspect of the present invention: step S3 further includes: when the peer online status indication indicates that the peer is online, traversing all member ports in the aggregation group and selecting the set of ports in the distribution state as the active members of the hardware aggregation instance; when the indication indicates that the peer is offline, traversing all member ports in the aggregation group and selecting the set of ports with all physical links up as the active members of the same hardware aggregation instance; recording a baseline status field for each member port before the start of each state machine cycle, comparing it with the current protocol state at the end of the cycle, and constructing a hook notification structure and sending it to the hardware forwarding device driver via callback when an edge transition occurs in the distribution state or overdue state, or when the physical link status of a member port changes; the hook notification structure includes a member port identifier array, an aggregation identifier key, an activity indication, an aggregation group media access control address, and the number of members in this notification.

[0021] As a further aspect of the present invention: step S4 further includes: the hardware forwarding device driver receiving the hook notification structure through its registered callback function; extracting the aggregation identifier key field from the notification, retrieving a matching hardware aggregation instance from the hardware aggregation instance table, allocating a new hardware aggregation instance and establishing a mapping when no match is found and the activity indication is "join"; for each member port identifier in the notification, obtaining its corresponding physical port index, adding or deleting the physical port on the existing hardware aggregation instance according to the activity indication, updating the hardware aggregation member bitmap field and the in-use member bitmap field, and writing the aggregation group media access control address into the corresponding register; counting the number of currently active members, dynamically recalculating the bucket allocation of the exit hash table according to the number of currently active members, updating the broadcast / multicast leaf linked list entries, and obtaining the hardware forwarding table entry configuration result.

[0022] As a further aspect of the present invention: step S5 further includes: after receiving the outgoing message, the hardware forwarding device calculates the hash value according to the Layer 2, Layer 3, and Layer 4 fields of the message header, looks up the outgoing physical port number according to the outgoing hash table, and performs multi-port load balancing among all active member ports; when the peer switches from never configured to configured, or from configured to revoked, the local protocol module recalculates the peer's online status indication in the next state machine cycle and issues the hardware aggregation member configuration change through the S3 to S4 process. The hardware forwarding device driver still hits the existing hardware aggregation instance by pressing the same aggregation identifier key, and the hardware aggregation instance is neither released nor rebuilt; when any member port physical link undergoes a down / up switch, if it is a down switch, the link status change processing flow constructs a hook notification structure and issues it to the hardware driver; if it is an up switch, a hook notification is constructed in the next state machine cycle and issued to the hardware driver, and the hardware aggregation instance is also neither released nor rebuilt.

[0023] As a further aspect of the present invention, it also includes at least one of the following alternatives:

[0024] (a) Extend the “forced active” state in the link aggregation control protocol state machine to force all physical link up ports to be included in the active set when the peer has not responded to the protocol data unit for a long time.

[0025] (b) Reserve a fallback port pool in the hardware. When the peer's online status is indicated as offline, automatically map all physical link up ports to the fallback port pool.

[0026] (c) The physical link status is polled using a timer and combined with an edge-triggered mechanism. The carrier status of netdev is adjusted by the driver, which indirectly affects the triggering of kernel bond and the invocation of kernel hooks.

[0027] Compared with the prior art, the beneficial effects of the present invention are:

[0028] (1) A single aggregation group configuration is compatible with both deployment modes of "the peer is configured with the link aggregation control protocol" and "the peer is not configured with the link aggregation control protocol", which eliminates the burden of operation and maintenance to know the peer configuration in advance or distinguish the aggregation mode of the host side.

[0029] (2) In scenarios where the peer does not run the link aggregation control protocol, the external bandwidth of the aggregation group is not lost and is still equal to the sum of the physical rates of all physical link up member ports in the aggregation group; compared with the existing commercial single-port fallback scheme (bandwidth is reduced to the physical rate of a single port), the bandwidth increase is proportional to the number of aggregation group members.

[0030] (3) When the peer runs the link aggregation control protocol dynamically, the host side can automatically switch the packet semantics without any reconfiguration. The hardware aggregation instance is not released or rebuilt, and the service is interrupted.

[0031] (4) During the hot-plugging process of the port, the hardware aggregation instance is not released or rebuilt to avoid jitter caused by the clearing of hardware resources, forwarding table entries and statistical counts;

[0032] (5) The edge-triggered offload notification mechanism minimizes the number of hardware table entries written and instantaneous jitter, and maintains the stability of the forwarding plane in scenarios with dense state changes.

[0033] (6) Unlike the existing fallback schemes on the switch side (which only keep a single port active or port hashing), this invention maintains multi-port aggregation semantics when the peer is not running the link aggregation control protocol. All ports of the physical links up participate in load sharing, and the aggregation bandwidth is not lost. Attached Figure Description

[0034] Figure 1 This is a schematic diagram of the online / offline adaptive packetization scheme for the peer end in this invention;

[0035] Figure 2 This is a schematic diagram illustrating the behavior of the strict protocol synchronization aggregation mode in existing technologies;

[0036] Figure 3 This is a schematic diagram of the hardware aggregation instance stability scheme in this invention;

[0037] Figure 4 This is a schematic diagram of a hardware instance reconstruction scheme for mode switching in the prior art;

[0038] Figure 5 This is a flowchart of the overall solution of the present invention. Detailed Implementation

[0039] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0040] Please see Figures 1-5 In this embodiment of the invention, a method for adaptive grouping and hardware instance stabilization based on DPU link aggregation includes the following steps:

[0041] Step S1: Load the link aggregation protocol module and register the callback function of the hardware forwarding device driver with it, initialize the aggregation group, allocate an aggregation identifier by the protocol module and derive a stable aggregation identifier key from it, establish a mapping with the hardware aggregation instance, and obtain the aggregation group initialization parameters.

[0042] Further, step S1 includes: loading the link aggregation protocol module and the DPU hardware forwarding device driver module; saving the hardware callback function pointer to the global function pointer of the protocol module through the callback registration interface predefined by the protocol module; creating an aggregation group through the user-space network configuration tool and setting its aggregation mode to the dynamic aggregation mode based on the link aggregation control protocol; allocating an aggregation identifier by the protocol module and deriving a stable aggregation identifier key, and establishing a mapping relationship between the aggregation identifier key and the hardware aggregation instance in the hardware aggregation instance table; configuring the member port list, aggregation group media access control address, state machine periodic parameters, etc., to obtain the aggregation group initialization parameters.

[0043] Step S2: Continuously run the link aggregation control protocol state machine on all member ports and continuously send protocol data units according to the period specified in the protocol. The sending action is independent of whether the other end is running the protocol. Traverse the protocol status fields of each member port to obtain the online status indication of the other end.

[0044] Furthermore, step S2 includes: starting the state machine cycle of the protocol module (default 100 milliseconds), running the link aggregation control protocol state machine in each cycle, and having the cycle sub-state machine continuously send protocol data units from all physical link up member ports according to the sending cycle (1 second in fast mode, 30 seconds in slow mode). The sending action does not depend on whether the peer responds or whether the peer runs the protocol. Before the end of each cycle, iterate through the protocol status fields of all member ports, and check whether the distribution flag bit is set on any port. If so, set the peer online status to indicate that the peer is online; otherwise, set the flag to indicate that the peer is offline.

[0045] Step S3: Construct a set of active hardware aggregation members based on the online status indication of the peer end—select ports in the distribution state when online, and select all ports with physical links up when offline; when an edge transition occurs in the distribution state or the overdue state, or when the physical link status of a member port changes, construct a hook notification structure and send it to the hardware forwarding device driver to obtain the hardware aggregation member configuration sequence.

[0046] In step S3, the overdue state refers to the temporary state in the protocol state machine after the peer PDU has timed out.

[0047] Furthermore, step S3 includes: when the peer online status indicates that the peer is online, traversing all member ports in the aggregation group and selecting the set of ports in the distribution state as the active members of the hardware aggregation instance; when the indication indicates that the peer is offline, traversing all member ports in the aggregation group and selecting the set of ports with all physical links up as the active members of the same hardware aggregation instance; recording a baseline status field for each member port before the start of each state machine cycle, comparing it with the current protocol status at the end of the cycle, and constructing a hook notification structure (including a member port identifier array, aggregation identifier key, activity indication, aggregation group media access control address, and the number of members in this notification) and sending it to the hardware forwarding device driver via callback when an edge transition occurs in the distribution state or overdue state, or when the physical link status of a member port changes.

[0048] Step S4: The hardware forwarding device driver retrieves the hardware aggregation instance by the aggregation identifier key. If no match is found and the instance has not been added, a new hardware aggregation instance is created and a mapping is established. If a match is found, members are added or deleted from the existing hardware aggregation instance. The hardware aggregation member table and the exit hash table are programmed to obtain the hardware forwarding table entry configuration results.

[0049] Further, step S4 includes: the hardware forwarding device driver receiving the hook notification structure through its registered callback function; extracting the aggregation identifier key field from the notification, retrieving a matching hardware aggregation instance from the hardware aggregation instance table, allocating a new hardware aggregation instance and establishing a mapping if no match is found and the activity indication is "join"; for each member port identifier in the notification, obtaining its corresponding physical port index, adding or deleting the physical port on the existing hardware aggregation instance according to the activity indication, updating the hardware aggregation member bitmap field and the in-use member bitmap field, and writing the aggregation group media access control address into the corresponding register; counting the number of currently active members, dynamically recalculating the bucket allocation of the egress hash table according to the number of currently active members, updating the broadcast / multicast leaf linked list entries, and obtaining the hardware forwarding table entry configuration result.

[0050] Step S5: The hardware forwarding device performs outbound load balancing forwarding among active members of multiple ports according to the packet header hash value; when the peer protocol configuration is switched or the member port physical link is switched up / down, S2 to S4 are triggered again, but the aggregation identifier key remains unchanged, the hardware aggregation instance is not released or rebuilt, and the aggregation group remains available.

[0051] Furthermore, step S5 includes: after receiving the outgoing packet, the hardware forwarding device calculates the hash value according to the Layer 2, Layer 3, and Layer 4 fields of the packet header, looks up the outgoing physical port number according to the outgoing hash table, and performs multi-port load balancing among all active member ports; when the peer switches from never configured to configured, or from configured to revoked, the local protocol module recalculates the peer's online status indication in the next state machine cycle and issues the hardware aggregation member configuration change through the S3 to S4 process. The hardware forwarding device driver still hits the existing hardware aggregation instance by pressing the same aggregation identifier key, and the hardware aggregation instance is neither released nor rebuilt; when any member port physical link goes down, the link status change processing flow constructs a hook notification structure and issues it to the hardware driver; when an up switch occurs, a hook notification is constructed in the next state machine cycle and issued to the hardware driver, and the hardware aggregation instance is also neither released nor rebuilt.

[0052] There is a close synergistic relationship between steps S1 to S5 of the present invention, which together achieve the overall effect of "continuous availability of the aggregation group and stable hardware instances under heterogeneous peer configuration":

[0053] (1) In step S2, “the local end continues to send protocol data units” is a prerequisite for “determining the online status of the peer based on the distribution state” in step S3. If the local end stops sending protocol data units, the peer cannot establish a distribution state, and the local end cannot perceive whether the peer is running the protocol, so adaptive grouping is out of the question.

[0054] (2) The decision rule in step S3, "selecting the distribution state port when the peer is online and selecting all physical link up ports when the peer is offline", works in conjunction with "constructing hook notification only at the edge transition of the distribution state or the overdue state" - since the change of the peer's online / offline status will inevitably manifest as the edge transition of the distribution state or the overdue state, this edge triggering mechanism can just issue the hardware configuration at the moment when the decision result may change, which not only ensures the timeliness of the response, but also avoids frequent writing to the hardware table due to periodic refresh or status jitter.

[0055] (3) The "stable aggregation identifier key" allocated in step S1 and the "hardware instance not being released or rebuilt" in steps S4 / S5 constitute the core synergy. It is precisely because the aggregation identifier key remains unchanged throughout the entire aggregation group's lifecycle that the change in the active member set caused by the switching of peer protocol configuration or port status in step S3 can be completed by adding or deleting members on the existing hardware aggregation instance, without destroying and rebuilding the instance. This fundamentally eliminates the service jitter caused by mode switching in the prior art.

[0056] (4) The overall effect of the above synergy is that a single aggregation group configuration can simultaneously support two deployments: “the peer configures the link aggregation control protocol” and “the peer does not configure the protocol”. When the peer dynamically starts or stops the protocol or hot-plugs the port, the host side does not need any reconfiguration, the hardware aggregation instance remains unchanged, the aggregation bandwidth is not lost, and the service is interrupted.

[0057] Example 1:

[0058] A data center server is equipped with the DPU described in this invention, and its two uplink physical ports (denoted as port ① and port ②) are connected to the access switch via a link.

[0059] If the access switch is configured with the link aggregation control protocol active mode, the local protocol module will continuously send protocol data units according to S2. After the state machine periodic negotiation, both member ports will enter the distribution state, and the peer online status indication will be true. The active members of the hardware aggregation instance are {port ①, port ②}. The external bandwidth of the aggregation group is equal to the sum of the physical rates of the two physical ports (e.g., 2 × 10 Gbps = 20 Gbps).

[0060] If the access switch is not configured with this protocol, the local protocol module will continue to send protocol data units according to S2, but the member ports cannot enter the distribution state, the peer online status indication is false, the active members of the hardware aggregation instance are still {port ①, port ②}, and the external bandwidth of the aggregation group is still equal to the sum of the physical rates of the two physical ports.

[0061] In both scenarios, the hardware aggregation instance is uniquely identified by the same aggregation identifier key, and the hardware aggregation instance is neither released nor rebuilt. The peer can dynamically switch whether to enable the protocol at runtime without any reconfiguration on the local end.

[0062] Example 2 (Port Hot-Swapping Scenario):

[0063] Based on the deployment in Example 1, assume a down event occurs on the physical link of port ①. The link state change handling process immediately processes the down event, constructs a hook notification structure and sends it to the hardware driver. The hardware aggregation instance marks port ① as unavailable, but the instance itself is not released. In the next state machine cycle (100 milliseconds later), the protocol module recalculates the peer online status indication (still false, because the peer is not running the protocol), selects all ports with physical links up (at this time only port ②) as the active member set, and constructs a hook notification to send configuration changes in the next state machine cycle. The hardware driver hits the existing instance with the same aggregation identifier key, deletes only port ①, and keeps port ②. The forwarding plane continues to operate, and the aggregated bandwidth is reduced to the single-port rate. When port ① comes up again, a hook notification is constructed in the next state machine cycle to add port ② back to the active set, bandwidth is restored, and the hardware instance is not rebuilt throughout the entire process.

[0064] Example 3 (Scenario of Dynamic Start-Stop Protocol on the Peer End)

[0065] Based on the deployment in Example 1, assuming the access switch is initially not configured with LACP, the local aggregation group operates in "offline mode," both ports are active, and the bandwidth is 20Gbps. The maintenance personnel enable LACP active mode on the switch side. The switch begins sending LACP PDUs. After the local protocol module receives the PDU in the next state machine cycle (within 100 milliseconds), the state machine enters the negotiation process. Within 1 second (the fast mode sending cycle), both member ports enter the distribution state successively, and the peer's online status indication changes from false to true. This change triggers an edge hook notification: the new active member set remains {port ①, port ②} (because both ports are in the distribution state), and the hardware driver hits the existing instance using the same aggregation identifier key, requiring no changes (the member set is the same). However, the aggregation group semantics subsequently switch from "offline mode" to "protocol mode." If the peer subsequently disables LACP again, the distribution state disappears, the peer's online status indication changes to false, and the hook notification triggers an active member set that remains {port ①, port ②} (because both ports are linked up), and the hardware instance remains unchanged. The entire process was uninterrupted and involved no instance rebuilding.

[0066] Alternative implementation methods:

[0067] To achieve the same inventive objective as this invention, one or more combinations of the following alternatives may also be used:

[0068] (a) Extend a “forced active” state to the link aggregation control protocol state machine. When the peer is detected to have not responded to the protocol data unit for a long time, force all physical link up ports to be included in the active set, replacing the decision logic based on the distribution state.

[0069] (b) Reserve a set of fallback port pools in the hardware. When the online status of the peer is indicated as offline, automatically map all physical link up ports to the fallback port pool to maintain the multi-port aggregation and forwarding capability and avoid degradation to single port or hash port.

[0070] (c) The physical link status is polled using a timer and combined with an edge-triggered mechanism. The carrier status of netdev is adjusted by the driver, which indirectly affects the triggering of kernel bond and the invocation of kernel hooks.

[0071] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A DPU-based method for adaptive grouping and hardware instance stabilization of link aggregation, characterized in that: Includes the following steps: Step S1: Load the link aggregation protocol module and register the callback function of the hardware forwarding device driver with it, allocate an aggregation identifier and derive a stable aggregation identifier key, and establish a mapping with the hardware aggregation instance; Step S2: Continuously run the link aggregation control protocol state machine on all member ports, continuously send protocol data units according to the specified period, traverse the protocol status fields of each member port, and obtain the online status indication of the peer end; Step S3: When the peer is online, select the port in the distribution state; when offline, select all ports with physical links up. When an edge transition occurs in the distribution state or the overdue state, or when the physical link status of a member port changes, construct a hook notification structure and send it to the hardware forwarding device driver. Step S4: Retrieve hardware aggregation instances by aggregation identifier key. If no instance is found and the instance has not been added, create a new instance and establish a mapping. If a instance is found, add or delete members on the existing instance. Program the hardware aggregation member table and the exit hash table. Step S5: The hardware forwarding device performs load sharing forwarding among active members of the multi-port according to the packet header hash value; when the peer protocol configuration is switched or the port physical link status changes, S2 to S4 are triggered again, but the aggregation identifier key remains unchanged, and the hardware aggregation instance is not released or rebuilt.

2. The method for DPU-based link aggregation adaptive grouping and hardware instance stabilization according to claim 1, characterized in that: In step S1, the hardware callback function pointer is saved to the global function pointer of the protocol module through the callback registration interface predefined by the protocol module, and an aggregation group is created through the user-space network configuration tool, and its aggregation mode is set to the dynamic aggregation mode based on LACP.

3. The method for DPU-based link aggregation adaptive grouping and hardware instance stabilization according to claim 1, characterized in that: In step S2, the state machine cycle is 100 milliseconds, the transmission cycle is 1 second in fast mode or 30 seconds in slow mode, and the transmission action does not depend on whether the other end responds or whether LACP is running.

4. The method for DPU-based link aggregation adaptive grouping and hardware instance stabilization according to claim 1, characterized in that: In step S3, the hook notification structure includes a member port identifier array, an aggregation identifier key, an activity indicator, an aggregation group MAC address, and the number of members in this notification.

5. The method for DPU-based link aggregation adaptive grouping and hardware instance stabilization according to claim 1, characterized in that: In step S4, the hardware driver adds or deletes physical ports on existing hardware aggregation instances according to the activity indication, updates the aggregation member bitmap and the in-use member bitmap, dynamically recalculates the bucket allocation of the exit hash table, and updates the broadcast / multicast leaf list entries.

6. The method for DPU-based link aggregation adaptive grouping and hardware instance stabilization according to claim 1, characterized in that: In step S5, when the peer switches from unconfigured LACP to configured, or from configured to revoked, the local protocol module recalculates the peer's online status indication and issues a hardware aggregation member configuration change in the next state machine cycle. The hardware aggregation instance is neither released nor rebuilt.

7. The method for DPU-based link aggregation adaptive grouping and hardware instance stabilization according to claim 1, characterized in that: When any member port physical link goes down, the link state change processing flow constructs a hook notification structure and sends it to the hardware driver; when an up switch occurs, the hook notification is constructed in the next state machine cycle and sent to the hardware driver, and the hardware aggregation instance is neither released nor rebuilt.

8. The method for DPU-based link aggregation adaptive grouping and hardware instance stabilization according to claim 1, characterized in that, It also includes at least one of the following alternatives: (a) Extend the "forced active" state in the link aggregation control protocol state machine to force all physical link up ports to be included in the active set when the peer has not responded to the protocol data unit for a long time. (b) Reserve a fallback port pool in the hardware. When the peer's online status indicates that it is offline, automatically map all physical link up ports to the fallback port pool. (c) The physical link status is polled using a timer and combined with an edge-triggered mechanism. The carrier status of netdev is adjusted by the driver, which indirectly affects the triggering of kernel bond and the invocation of kernel hooks.

Images