Method to reduce write responses to improve bandwidth and efficiency
US-2019138465-A1 · May 9, 2019 · US
US11038800B2 · US · B2
| Field | Value |
|---|---|
| Publication number | US-11038800-B2 |
| Application number | US-201916553511-A |
| Country | US |
| Kind code | B2 |
| Filing date | Aug 28, 2019 |
| Priority date | Aug 28, 2019 |
| Publication date | Jun 15, 2021 |
| Grant date | Jun 15, 2021 |
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.
An endpoint in a network may make posted or non-posted write requests to another endpoint in the network. For a non-posted write request, the target endpoint provides a response to the requesting endpoint indicating that the write request has been serviced. For a posted write request, the target endpoint does not provide such an acknowledgment. Hence, posted write requests have lower overhead, but they suffer from potential synchronization and resiliency issues. While non-posted write requests do not have those issues, they cause increased load on the network because such requests require the target endpoint to acknowledge each write request. Introduced herein is a network operation technique that uses non-posted transactions while maintaining a load overhead of the network as a manageable level. The introduced technique reduces the load overhead of the non-posted write requests by collapsing and reducing a number of the responses.
Opening claim text (preview).
What is claimed is: 1. A method of operating a fabric comprising: forwarding requests from a source endpoint to a target endpoint; and forwarding responses of the requests from the target endpoint to the source endpoint, wherein, the forwarding the responses includes reducing a number of the responses by collapsing some of the responses that belong to a same stream into a single collapsed response, and wherein the collapsing includes: determining that at least one of the responses is collapsible; comparing the at least one collapsible response to other collapsible response; and if a stream identifier of the at least one collapsible response matches a stream identifier of the other collapsible response, incrementing a collapse count in the other collapsible response and discarding the at least one collapsible response. 2. The method of claim 1 , wherein the collapsing further includes storing the at least one collapsible response if the stream identifier of the at least one collapsible response does not match the stream identifier of the other collapsible response. 3. The method of claim 1 , wherein the collapsing further includes continuing to forward the other collapsible response to the source endpoint when a predetermined time period expires or when the collapse count reaches a maximum count or an expected response number for a stream, to which the other collapsible response belongs. 4. The method of claim 1 , wherein the collapsing is performed using a content-addressable memory of a switch connected to the fabric. 5. The method of claim 1 , wherein the forwarding the requests includes changing original stream identifiers of the requests with unique stream identifiers when the original stream identifiers do not indicate streams, to which the requests belong. 6. The method of claim 5 , wherein the changing includes changing an original stream identifier of one of the requests with a unique stream identifier from a non-collapsible tag pool when the one request is not collapsible. 7. The method of claim 5 , wherein the changing includes when one of the requests is collapsible and does not belong to tracked streams in a memory, changing an original stream identifier of the one request with a unique stream identifier from a collapsible tag pool and storing a stream, with which the unique stream identifier is associated, in the memory. 8. The method of claim 5 , wherein the changing includes changing an original stream identifier of one of the requests with a unique stream identifier from a non-collapsible tag pool when the one request is collapsible and a stream, to which the one request belongs, cannot be tracked. 9. The method of claim 5 , wherein the changing includes changing an original stream identifier of one of the requests with a unique stream identifier associated with a tracked stream and incrementing a collapse count of the tracked stream when the one request is collapsible and belongs to the tracked stream. 10. The method of claim 1 further comprising synchronizing the source endpoint and the target endpoint by tracking flush requests and responding to each of the flush requests when all transactions before the each flush request are completed. 11. The method of claim 10 , wherein the tracking includes: incrementing an open counter of a tracking structure when a request of at least one stream arrives at the tracking structure and decrementing the open counter when a response of the at least one stream arrives at the tracking structure; receiving one of the flush requests at the tracking structure; and upon the receiving: if a closed counter of the tracking structure is empty or zero, transitioning the open and closed counters to opposite states; and if the closed counter has not reached zero, marking the open and closed counters to transition to the opposite states when the closed counter reaches zero and continuing to track incoming transaction and flush request on the open counter. 12. The method of claim 11 , wherein the tracking further includes when the closed counter reaches zero, responding to all flush requests that arrived while the closed counter was the open counter and transitioning the open and closed counters to the opposite states. 13. The method of claim 12 , wherein the transitioning the open and closed counters to the opposite states includes updating extended stream identifiers of transactions to be tracked by a new open counter. 14. The method of claim 1 , further comprising detecting an error in a particular stream by determining whether all transactions of the particular stream are completed within a predetermined time period. 15. The method of claim 14 , wherein the determining includes tracking responses of the particular stream using a closed counter of a source-track structure, and when the closed counter does not reach zero before a timer associated the closed counter expires, notifying the source endpoint that the error has occurred in the particular stream. 16. The method of claim 15 , wherein the notifying includes clearing transactions of the particular stream from the source endpoint and the fabric. 17. The method of claim 15 , wherein a usage of the timer is time-multiplexed and shared by multiple closed counters. 18. The method of claim 15 , wherein a usage of the closed counter is time-multiplexed and shared by multiple open counters. 19. The method of claim 1 , wherein the requests are non-posted write requests. 20. A device for operating a fabric comprising: a pipeline configured to forward requests from a source endpoint to a target endpoint and forward responses of the requests from the target endpoint to the source endpoint; and a collapsing structure implemented as a hardware circuit, connected to the pipeline and configured to reduce a load of the responses on the fabric by collapsing some of the responses that belong to a same stream into a single collapsed response, wherein the collapsing includes: determining that at least one of the responses is collapsible; comparing the at least one collapsible response to other collapsible response that is stored in the collapsing structure; and if a stream identifier of the at least one collapsible response matches a stream identifier of the other collapsible response, incrementing a collapse count in the other collapsible response and discarding the at least one collapsible response. 21. The device of claim 20 , wherein the collapsing further includes storing the at least one collapsible response in the collapsing structure if the stream identifier of the at least one collapsible response does not match the stream identifier of the other collapsible response and the collapsing structure has an available slot. 22. The device of claim 20 , wherein the collapsing structure is further configured to release the other collapsible response into the pipeline when a predetermined time period expires or when the collapse count reaches a maximum count or an expected response number for a stream that the other collapsible response belongs to. 23. The device of claim 20 , wherein the collapsing structure is a content-addressable memory. 24. The device of claim 20 further comprising a tag remapping structure configured to change original stream identifiers of the requests with unique stream identifiers when the original stream identifiers do not indicate streams, to which the requests belong. 25. The device of claim 24 , wh
Avoiding congestion; Recovering from congestion · CPC title
with data restructuring · CPC title
using content-addressable memories [CAM] · CPC title
Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes · CPC title
using switching circuits, e.g. switching matrix, connection or expansion network (G06F13/4009 takes precedence) · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.