Packet Network Flush Request Hardware Processing

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing packet networks are inefficient in processing flush requests due to treating them as regular write requests, leading to slow propagation and potential data loss in case of power interruptions, as they rely on software stacks within the persistence domain to perform flush operations.

Innovation Solution

Implementing a packet-based flush command within the packet network that is recognized by hardware components, allowing direct triggering of flush operations within the persistence domain, thereby bypassing software invocation and enhancing performance and reliability.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If flush requests are treated as regular write requests in packet networks, then the packet network can process them using existing infrastructure, but the processing speed becomes very slow due to software invocation overhead

Engineering Contradiction:

Improvecompatibility with existing packet network infrastructureVSAvoidflush request processing speed

Core Design Contradiction:

Adaptability or versatilityVSSpeed

Solution Approach 1:

The patent changes the parameter of request identification by introducing a specific request type field that distinguishes flush requests from regular write requests. This allows the packet network to recognize and handle flush requests differently, enabling faster processing while maintaining compatibility with existing infrastructure through the same packet format.

Inventive Principle:

Principle #35Parameter changes

Solution Approach 2:

The patent introduces an intermediary mechanism in the form of a dedicated flush request handler that sits between the packet network and the persistence domain. This intermediary translates flush requests into appropriate actions without requiring full software stack invocation, thereby speeding up processing while maintaining system integration.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Reliability

If flush requests are processed through software stacks within the persistence domain, then data persistence can be ensured, but the time delay between issuing flush request and its execution increases significantly

Engineering Contradiction:

Improvedata persistence reliabilityVSAvoidflush request execution delay

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

The patent extracts the critical flush operation triggering function from the software stack and implements it directly in the packet network hardware. This separation allows the time-critical flush request processing to be handled by fast hardware paths while the software stack remains responsible for higher-level data persistence management, thereby reducing delay without compromising reliability.

Inventive Principle:

Principle #2Taking out (Extraction)

Solution Approach 2:

The patent implements preliminary action by pre-configuring the packet network to recognize and prioritize flush requests before they reach the persistence domain. This preliminary identification and routing preparation enables the system to execute flush operations faster without sacrificing the reliability guarantees provided by the persistence domain's software stacks.

Inventive Principle:

Principle #10Preliminary action

3Device complexity

If a packet network is designed to handle multiple types of requests uniformly, then device complexity is reduced, but the ability to distinguish and optimize processing of flush requests is lost

Engineering Contradiction:

Improvepacket network processing logic complexityVSAvoidflush request processing throughput

Core Design Contradiction:

Device complexityVSProductivity

Solution Approach 1:

The patent applies local quality by introducing request type differentiation only at specific points in the packet network where it is most beneficial, rather than redesigning the entire network. The request type field and specialized handling logic are localized to the packet processing path, allowing the rest of the network to continue operating with uniform request handling, thus minimizing added complexity while improving flush request throughput.

Inventive Principle:

Principle #3Local quality

Data Source

PatentEP3999972B1An apparatus and method for processing flush requests within a packet network

Publication Date: 2023.11.22 ARM LTD

Figure 1
Figure 2A
Figure 2B

AI summary

An apparatus and method are provided for processing flush requests within a packet network (15). The apparatus comprises a requester device (30) within the packet network (15) arranged to receive a flush request generated by a remote agent (10) requesting that one or more data items be flushed to a point of persistence (25). The requester device (30) translates the flush request into a packet- based flush command conforming to a packet protocol of the packet network (15). A completer device (40) within the packet network (15) that is coupled to a persistence domain (20) incorporating the point of persistence (25) is arranged to detect receipt of the packet- based flush command, and then trigger a flush operation within the persistence domain (25) to flush the one or more data items to the point of persistence (25). This provides a fast, hardware-based, mechanism for performing a flush operation within a persistence domain (20) without needing to trigger software in the persistence domain (20) to handle the flush to the point of persistence (25).