JP7577580B2 - SSL communication processing device and SSL communication processing method - Google Patents

Description

The present invention relates to an SSL communication processing device and an SSL communication processing method.

For example, US Patent Publication 2007/0139963 discloses an apparatus for sequencing, synchronizing, and scheduling work in a network services processor having multiple cores, where each piece of work is identified by a tag that indicates how the work should be synchronized and sequenced, where work with different tags is processed in parallel by different processor cores to improve throughput, where packet processing can be divided into various stages, where each stage has a different tag depending on sequencing and synchronization constraints, where tag switch operations initiated by the cores switch tags depending on the stage, and where a dedicated tag switch bus minimizes the latency of the tag switch operations.

Patent document 2 also discloses a transmission control device in which a memory unit 1a stores information regarding the relationship between multiple requests and a priority for sending the request in association with the request, and when a processing unit 1b receives a first request for executing a process, the processing unit 1b refers to the memory unit 1a to identify a second request related to the first request and a first priority corresponding to the second request, and the processing unit 1b transmits the second request at a second priority higher than the first priority to an information processing device 2 that executes the process according to the first request.

Patent document 3 also discloses a method of processing security operations, in which a processor includes a number of execution units that process a number of requests for security operations, the execution units output results of the requests to an output data structure associated with the requests in a remote memory based on pointers stored in the requests, the execution units can output the results in an order different from the order of the requests in the request queue, the processor also includes a request unit coupled to the execution units, the request unit retrieves some of the requests from the request queue in the remote memory and retrieves associated input data structures for some of the requests from the remote memory, and the request unit distributes the retrieved requests to the execution units based on availability for processing by the execution units.

Special table 2008-512950 Patent Publication No. 2019-040344 Special table 2003-216591

The objective is to provide an SSL communication processing device that fully utilizes the performance of a device that performs encryption or decryption processing of SSL communications.

The SSL communications processing device according to the present invention includes a request issuing core that issues requests for encryption or decryption processing of SSL communications, a request queue collection including multiple request queues that queue the requests issued by the request issuing core, and a device that processes the requests queued in the request queues, and multiple grouped request queues are assigned to one of the request issuing cores.

Preferably, the request issuing core issues a request to a representative request queue from among the multiple grouped request queues, and a request queue selected in a round robin fashion from among the grouped request queues queues the request issued to the representative request queue.

Preferably, the device includes multiple child devices that can be processed in parallel independently of each other, and the multiple grouped request queues are assigned to different child devices.

Preferably, the device includes more engines than the request queue.

The SSL communication processing method according to the present invention also includes a step in which a request issuing core issues a request for encryption or decryption of SSL communication to a group of request queues assigned to the request issuing core, a step in which one of the request queues belonging to the group queues the request issued by the request issuing core, and a step in which a device performing encryption or decryption of SSL communication processes the request queued in the request queue.

This allows the device performing encryption or decryption processing for SSL communications to perform to its full potential.

FIG. 2 is a diagram illustrating an example of a hardware configuration of a network device 1. FIG. 2 is a diagram illustrating an example of a functional configuration of a network device 1. 10 is a flowchart illustrating an SSL process (S10) in the network device 1. FIG. 13 is a diagram illustrating an example of a functional configuration of a network device 1 according to a modified example. FIG. 11 is a diagram illustrating a functional configuration of a network device in a first comparative example. FIG. 11 is a diagram illustrating a functional configuration of a network device in a second comparative example.

An embodiment of the present invention will be described with reference to the drawings.
FIG. 1 is a diagram illustrating an example of a hardware configuration of a network device 1.
As illustrated in FIG. 1, the network device 1 includes a request issuing core 10, a request queue collection 12, and an SSL processing device 14.
The request issuing core 10 issues requests for encryption or decryption processing of SSL (Secure Sockets Layer) communication. For example, the request issuing core 10 includes a plurality of request issuing cores, which issue requests in parallel.
The request queue aggregate 12 includes a plurality of request queues 120, and queues requests issued from the request issuing core 10. Queuing refers to holding requests on a first-in, first-out basis.
The SSL processing device 14 is an engine group including a plurality of engines that perform encryption or decryption processing of SSL communications, and processes the requests queued in the request queue group 12 in order.
In the above configuration, a request for encryption processing, decryption processing, or the like is issued from the request issuing core 10 of the network device 1 to the request queue (request queue 120) of the SSL accelerator via the API.
The requests queued in the request queue 120 are processed using the engine of the SSL accelerator (the engine of the SSL processing device 14) and the requests are completed.
The issuance and completion of a request are asynchronous, and the network device 1 issues a request every time it encrypts or decrypts received data.

(background)
It is also possible to design the request issuing cores and the request queues in a one-to-one correspondence, as in Comparative Example 1 shown in Fig. 5. In this type of design, if the number of request queues is equal to or greater than the number of engines, there is no problem, but if the number of request queues is less than the number of engines, the engines will be left surplus and will not be used effectively.
In addition, the request queue uses one free engine at a time to process one request. The free engine to be used is assigned automatically and cannot be controlled by software.
That is, as shown in Fig. 5, the number of available request queues is less than the number of engines, resulting in free engines. Since the engines cannot be fully utilized, the SSL accelerator cannot demonstrate its original performance. In the example of Fig. 5, the number of request issuing cores is 6, the number of request queues is 30 (of which 6 are available), and engines EN7 to EN30 cannot be used.
There is no correlation between the request queue number and the engine number, and an available engine is automatically assigned.

Therefore, in the network device 1 of this embodiment, the SSL accelerator groups multiple request queues and issues a request to the representative request queue of that group, making it possible to execute request processing.

FIG. 2 is a diagram illustrating an example of the functional configuration of the network device 1. As shown in FIG.
As illustrated in FIG. 2, the network device 1 has a plurality of request issuing cores 10, grouped request queues 120, and an SSL processing device 14 including a plurality of engines 140, and each of the request issuing cores 10 is assigned a grouped request queue 120.
More specifically, a group of a plurality of request queues 120 is treated as a node, and the same number of nodes are created as the number of request issuing cores 10. One representative request queue 122 is set for each node.

Fig. 3 is a flowchart for explaining the SSL processing (S10) in the network device 1. Note that this flowchart will be explained focusing on one request issuing core 10 in Fig. 2. The other request issuing cores 10 also perform similar processing in parallel.
As illustrated in FIG. 3, in step 100 (S100), the request issuing core 10 issues a request to the representative request queue 122 of the assigned request queue group (node).
In step 110 (S110), the representative request queue 122 selects a request queue 120 assigned to the group (node) to which it belongs and issues a request. The selection method is round robin.

In step 120 (S120), the selected request queue 120 queues the issued request.
In step 130 (S 130 ), the engine 140 of the SSL processing device 14 processes the request queued in the request queue 120 .

As described above, according to the network device 1 of this embodiment, by increasing the number of request queues 140 used in the SSL accelerator and increasing the number of requests issued, the engines 140 can be effectively utilized and the performance of the SSL accelerator can be demonstrated. In other words, it is possible to create a state in which the number of request queues 120 is equal to or greater than the number of engines 140, and the relationship between the request issuing cores and the request queues becomes 1:many.
2, the request issuing core 10 can issue requests from a plurality of request queues 120, the number of which is at least the number of request queues 120 or engines 140. For example, when a request is queued in the representative request queue 122, one of the five request queues 120, including the representative request queue, namely, the 1st, 7th, 13th, 19th, and 25th request queues 120 is selected and the request is issued. In FIG. 2, an arrow is drawn from the request queue 120 to the engine for the request issued from the request issuing core 10, but an arrow can be drawn from the request queue 120 to the engine 140 for the requests issued from the other request issuing cores 10. This allows the engines to be used effectively without being wasted. Note that there is no correlation between the numbers of the request queues 120 and the numbers of the engines 140, and an available engine 140 is automatically assigned.

(Modification)
Next, as a modification of the above embodiment, a case will be described in which the SSL accelerator is physically one device but has three child devices internally.
In this case, if there is a bias in the request issuing cores used during communication, there will be a bias in the child devices used, as shown in Fig. 6. More specifically, a case in which two request issuing cores are evenly assigned to each of three child devices A, B, and C in Fig. 6 will be described as Comparative Example 2.
The engines of each child device are indicated as A1 to A10, B11 to B20, and C21 to C30. Considering a case where the request issuing cores 1 to 4 are biased, the request issuing cores 1 and 2 are assigned only to the child device A. At this time, among the engines A1 to A10, an available engine is automatically assigned and used. Furthermore, the request issuing cores 3 and 4 are assigned only to the child device B. Here, among the engines B11 to B20, an available engine is used. As a result, the engines are biased toward the child devices A and B, while the child device C is hardly used at all, and only about two-thirds of the original performance is exhibited as an SSL accelerator.

There are two aspects to this lack of performance:
- Unable to demonstrate performance when engines are under heavy load For example, if there is a concentration of requests with a large volume and heavy calculations that require processing by all 30 engines, and the requests are concentrated on child devices A and B, the number of engines that can be used will be limited to 20, A1 to A10 and B11 to B20. Since all 30 engines cannot be used, the SSL accelerator cannot demonstrate its inherent performance.
- The unique functions of each child device cannot be fully utilized Each child device has its own unique functions in addition to the engine. For example, when processing a specific encryption type, calculations may be performed using a unique circuit that each child device has, separate from the engine. As a result, while three circuits can be used across all devices, only two circuits are used across two devices, and performance cannot be achieved. This problem does not only occur during high loads such as those described above.

Therefore, in the network device 1 of this modified example, the multiple grouped request queues 120 are assigned to different child devices. In other words, the multiple request queues 120 in a group are assigned across multiple child devices. More specifically, as shown in FIG. 4, the request queues 120 and engines 140 of each child device are used as evenly as possible to maximize performance.

Specifically, an example of an SSL accelerator having multiple child devices is PE3ISLBTL (PCIe 3.0, x8 Crypto/Compression LBG Server Adapter) made by Silicon Corp. In such an SSL accelerator, the request queues 120 of the child devices are assigned to the request issuing core 10 so as to be used as evenly as possible.
In this modified example, the number of request issuing cores 10 is six, the number of child devices is three, the request queues 120 of child device A are 1 to 10, the engine group 15A of child device A are A1 to A10, the request queues 120 of child device B are 11 to 20, the engine group 15B of child device B are B11 to B20, the request queues of child device C are 21 to 30, and the engine group 15C of child device C are C21 to C30. Note that the queue numbers of the representative request queue 122 are indicated by circles. There is no correlation between the numbers of the request queues 120 and the numbers of the engines 140, and a request queued in the request queue 120 is automatically assigned an available engine 140 from among the engines 140 indicated by the same hatching pattern as the request queue 120.

The above settings have the following effects:
Even if the request issuing cores 10 used are unevenly distributed, processing can be distributed among the child devices, allowing processing to be performed without degrading the performance of the SSL processing device 14. For example, even if the request issuing cores used are unevenly distributed among the first to fourth request issuing cores, in this modified example, all three child devices A to C can be used from the request queues 120 corresponding to the respective request issuing cores 10, allowing the unique functions of all child devices to be used. In addition, all engines 140 of all child devices can be used. Therefore, performance degradation can be reduced compared to when not using all child devices.
Even if an error occurs in one child device and it becomes temporarily unable to process, the other child devices can process requests, so processing can continue. For example, if child device A becomes unable to process, request queues 120 No. 1 to 10 become unusable, but request queues 120 No. 11 to 30 can be used, so all request issuing cores 10 can continue to issue and process requests.

In this manner, according to the network device 1 of this modified example, even if the request issuing cores 10 used are unevenly distributed, processing can be distributed among child devices, so processing can be performed without degrading the performance of the SSL accelerator as a whole.
Furthermore, even if an error occurs in one child device and it becomes temporarily unable to process, other child devices can still process the request, so processing can continue.

Reference Signs List 1 network device 10 request issuing core 12 request queue aggregate 120 request queue 122 representative request queue 14 SSL processing device 140 engine 15 engine group

Claims (5)

a request issuing core that issues a request for encryption or decryption of SSL communication;
a request queue assembly including a plurality of request queues for queuing requests issued by the request issuing core;
a device for processing requests queued in the request queue;
A plurality of grouped request queues are assigned to one of the request issuing cores. the request issuing core issues a request to a representative request queue among the grouped request queues;
2. The SSL communications processing device according to claim 1, wherein a request queue selected in a round robin manner from among the grouped request queues queues a request issued to the representative request queue. The device includes a plurality of child devices that can operate in parallel independently of each other;
The SSL communications processing device according to claim 1 , wherein the plurality of grouped request queues are assigned to different child devices. The SSL communications processing apparatus of claim 2 , wherein the device includes more engines than the request queues. A request issuing core issues a request for encryption or decryption of SSL communication to a group of request queues assigned to the request issuing core;
queuing a request issued by the request issuing core in one of the request queues belonging to the group;
A device that performs encryption or decryption processing of SSL communication processes requests queued in the request queue.

Images