Browse Prior Art Database

Async Command Interface to the Adapter (Virtual Host Command Register (vHCR) Algorithm)

IP.com Disclosure Number: IPCOM000249066D
Publication Date: 2017-Jan-31
Document File: 4 page(s) / 294K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed are a method and tool to have a queuing interface for commands through a long-running command interface for different types of workload requirements. The novel method comprises two solutions: one addresses two types of workloads and another introduces a third execution class for the asynchronous command case.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 41% of the total text.

1

Async Command Interface to the Adapter (Virtual Host Command Register (vHCR) Algorithm)

In a multi-processor environment, running commands for a variety of different processes using a single adapter results in a number of problems. It is particularly troublesome when different workloads have different timing requirements or cannot give up the processor until the task is completed. A unique type of command interface congestion control is required in order to satisfy a variety of workload needs.

The core idea is to have a queuing interface for commands through a long-running command interface for different types of workload requirements. The novel method comprises two solutions. The first solution addresses two types of workloads, normal and recovery . The second solution introduces a third execution class for the asynchronous command case.

Solution 1 When a multi-processor system is running a variety of different tasks or processes that all need to access the same single thread command interface in the hardware, a mechanism for arbitration is required in order to ensure that commands are complete before another command is posted. Furthermore, when the different tasks have different run time characteristics, the command interface must act in a differentiated manner. Thus, the first solution addresses two types of workloads. The first type of workload is a normal workload that can take asynchronous completion and is re-entrant upon the command completion. The second type of workload is a recovery workload, which must run as quickly as possible as a single task all at once.

The present solution identifies each task/process using a process identifier (PID). The PID includes what the process is as well as identification information used by those processes to know which control blocks require operation in order to know what to do next. Usually, the process ID itself represents a group of commands that need to be run in a specific order and is used in conjunction with control blocks in order to complete the task correctly through completion. A PID or multiple PIDs that are executing on a system call to the command interface to the adapter. The first step here is to check the type of workload in order to identify which execution path within the interface to go down.

When the PID is a normal mainline task, the method first determines whether the command interface is currently busy executing a command. When the interface is busy, the method must take the PID information as well as the specific command information and post it in a buffer to a queue for later execution. If the interface is not currently busy, then the tool writes the command to the hardware to begin execution and sets the flag in the control block to indicate that the interface is busy.

The completion of the command is checked in one of two ways: via directly reading the hardware bits for command completion or waiting for the hardware to post an event to a queue and come back to the PID...