Technique for collecting state information of an apparatus
US-2023214224-A1 · Jul 6, 2023 · US
US12423116B1 · US · B1
| Field | Value |
|---|---|
| Publication number | US-12423116-B1 |
| Application number | US-202418612953-A |
| Country | US |
| Kind code | B1 |
| Filing date | Mar 21, 2024 |
| Priority date | Mar 21, 2024 |
| Publication date | Sep 23, 2025 |
| Grant date | Sep 23, 2025 |
A practical reading order for non-experts. Skip the full description unless you need deep technical detail.
What the patent document calls the invention.
A short plain-language summary of the technical disclosure.
Who owns or filed the patent and who is credited as inventor.
Filing, priority, publication, and grant dates set the timeline.
The legal scope of protection — read this for what is actually claimed.
Technology tags used to group this patent with similar filings.
Prior art links and similar publications in this corpus.
Official abstract text for this publication.
Embodiments herein describe synchronizing policing entries for multiple pipelines using synchronization counters. That is, memories for each of the pipelines can store policing entries which determine whether a packet for a particular entity (e.g., a flow, a VM, or host) has exceeded a data or packet rate. If the packet is allowed (the rate is not exceeded), the policing entry at the local pipeline is updated. However, the policing entries for the other pipelines are not aware of this update. In one embodiment, in addition to maintaining policing entries, the pipelines also update synchronization (sync) counters which are updated when the policing entries are updated. When a synch counter reaches a threshold, a sync event is triggered where the value of the synch counter is used to update the values of the policing entries in the other pipelines in the DPU.
Opening claim text (preview).
What is claimed is: 1. A data processing unit (DPU), comprising: a first pipeline comprising a plurality of hardware stages, the first pipeline configured to maintain a first policing entry for indicating whether a rate limit for a first entity has been met; and a second pipeline comprising a plurality of hardware stages, the second pipeline configured to maintain a second policing entry for indicating whether the rate limit for the first entity has been met, wherein the second pipeline is further configured to: receive packet data corresponding to the first entity, query the second policing entry to determine that the rate limit for the first entity has not been exceeded, update the second policing entry and a synchronization counter stored in the second pipeline, and upon determining the synchronization counter has satisfied a threshold, perform a synchronizer event to update the first policing entry in the first pipeline using the synchronization counter in the second pipeline. 2. The DPU of claim 1 , wherein the first pipeline is further configured to: receive packet data corresponding to the first entity, query the first policing entry to determine that the rate limit for the first entity has not been exceeded, update the first policing entry and a second synchronization counter stored in the first pipeline, and upon determining the second synchronization counter has satisfied a threshold, perform a synchronizer event to update the second policing entry in the second pipeline using the second synchronization counter in the first pipeline. 3. The DPU of claim 1 , wherein querying the second policing entry comprises: performing a table lookup in table memory in the second pipeline that contains the second policing entry, wherein the table lookup returns a policing color. 4. The DPU of claim 3 , wherein the plurality of hardware stages each includes a match processing unit (MPU) configured to use the returned policing color to determine whether to admit or deny the packet data. 5. The DPU of claim 1 , wherein the first pipeline is configured to maintain (i) a third policing entry for indicating whether a rate limit for a second entity has been met and (ii) a second synchronization counter to track changes made to the third policing entry since a last synchronizer event, wherein the second pipeline is configured to maintain (i) a fourth policing entry for indicating whether the rate limit for the second entity has been met and (ii) a third synchronization counter to track changes made to the fourth policing entry since a last synchronizer event. 6. The DPU of claim 1 , wherein the first pipeline is configured to maintain a third policing entry for indicating whether a rate limit for a second entity has been met, wherein the second entity is part of the first entity, wherein the second pipeline configured to maintain a fourth policing entry for indicating whether the rate limit for the second entity has been met. 7. The DPU of claim 6 , wherein the first entity is a host and the second entity is a virtual machine (VM) executed by the host, or the first entity is a VM and the second entity is a network flow generated by the VM. 8. The DPU of claim 6 , wherein the second pipeline is further configured to: query the fourth policing entry to determine that the rate limit for the second entity has not been exceeded; and upon determining the rate limit for the first entity and the rate limit for the second entity have not been exceeded, update the fourth policing entry, wherein updating the second policing entry is performed after determining the rate limit for the first entity and the rate limit for the second entity have not been exceeded. 9. The DPU of claim 8 , wherein querying the second and fourth policing entries are read only operations, wherein updating the second and fourth policing entries are read-modify-write operations. 10. The DPU of claim 6 , wherein the second pipeline is further configured to: upon determining that either the rate limit for the first entity or the rate limit for the second entity has been exceeded or met, dropping the packet data. 11. A method comprising: receiving packet data corresponding to a first entity at a first pipeline in a DPU, wherein the first pipeline maintains a first policing entry for indicating whether a rate limit for the first entity has been met; querying the first policing entry to determine that the rate limit for the first entity has not been exceeded; updating the first policing entry and a synchronization counter stored in the first pipeline; and upon determining the synchronization counter has satisfied a threshold, performing a synchronizer event to update a second policing entry in a second pipeline in the DPU using the synchronization counter in the first pipeline, wherein the second policing entry indicates whether the rate limit for the first entity has been met. 12. The method of claim 11 , further comprising: receiving packet data corresponding to the first entity at the second pipeline; querying the second policing entry to determine that the rate limit for the first entity has not been exceeded; updating the second policing entry and a second synchronization counter stored in the second pipeline; and upon determining the second synchronization counter has satisfied a threshold, performing a synchronizer event to update the first policing entry in the first pipeline using the second synchronization counter in the second pipeline. 13. The method of claim 11 , wherein querying the first policing entry comprises: performing a table lookup in table memory in the first pipeline that contains the first policing entry, wherein the table lookup returns a policing color. 14. The method of claim 13 , wherein a plurality of stages in the first pipeline each includes a MPU configured to use the returned policing color to determine whether to admit or deny the packet data. 15. The method of claim 14 , further comprising: maintaining a third policing entry in the first pipeline for indicating whether a rate limit for a second entity has been met, wherein the second entity is part of the first entity maintaining a fourth policing entry in the second pipeline for indicating whether the rate limit for the second entity has been met. 16. The method of claim 15 , wherein the first entity is a host and the second entity is a virtual machine (VM) executed by the host, or the first entity is a VM and the second entity is a network flow generated by the VM. 17. The method of claim 16 , further comprising: querying the third policing entry to determine that the rate limit for the second entity has not been exceeded; and upon determining the rate limit for the first entity and the rate limit for the second entity have not been exceeded, updating the third policing entry, wherein updating the first policing entry is performed after determining the rate limit for the first entity and the rate limit for the second entity have not been exceeded. 18. The method of claim 17 , wherein the querying the first and third policing entries are read only operations, wherein updating the first and third policing entries are read-modify-write operations. 19. The method of claim 16 , upon determining that either the rate limit for the first entity or the rate limit for the second entity has been exceeded or met, dropping the packet data. 20. The method of claim 14 , wherein the DPU is part of a Smart network interface controller/card (SmartNIC).
Network integration; Enabling network access in virtual machine instances · CPC title
Hypervisors; Virtual machine monitors · CPC title
Configuring for program initiating, e.g. using registry, configuration files · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.