KR102716942B1 - Tunnel data update method of data communication using tunnel Control thread - Google Patents

Abstract

The present invention relates to a method for processing tunnel data updates in data communications. The present invention is characterized by including a step of inputting a packet, a step of parsing an Ethernet header of the input packet, a step of confirming whether the packet is an IP packet, and if it is confirmed to be an IP packet, a step of parsing the IP header, a step of confirming the band of a source IP in a tunnel table and, if appropriate, parsing a tunnel UDP (User Datagram Protocol) header, a step of confirming whether the tunnel source port and the tunnel destination port are in the tunnel table, and if confirmed in the above step, a step of authenticating with a registered tunnel packet, a step of confirming whether the tunnel packet registered in the above step is a data packet, a step of removing the tunnel header and adding a new tunnel header if the data packet is confirmed in the above step, a step of confirming the port by updating statics, and a step of transmitting tunnel data to a network.

Description

Tunnel data update method of data communication using tunnel Control thread

The present invention relates to a method for processing tunnel data updates in data communication using a tunnel Ctrl thread, and more specifically, to a method for processing tunnel data updates using a tunnel Ctrl thread for easily processing a large number of sessions.

As cloud-based solutions such as SDN/NFV, vEPC, and IoT cloudification increase, servers in data centers are changing into high-performance virtualized servers, and servers no longer provide a single service, but provide diverse and complex services.

For example, multiple web servers can operate on a single server, and functions such as security servers and authentication servers can be performed simultaneously, and these can be changed in software depending on functions added and deleted from the server. In other words, the types of packets flowing into the server can vary depending on the tenant of the server.

The first part that receives packets from the network is the NIC (Network Interface Card). With the development of SDN/NFV and cloud computing technologies, NICs are also trending toward higher speeds and larger capacities, such as 40G and 100G. One alternative is to use a NIC that uses a dedicated network processor based on multi-cores to improve performance.

However, the buffer allocation and management of existing multi-core-based NICs are executed by fixing the buffer setting information requested by the user or service in advance at the time of initial program execution.

For the above reasons, adding and changing dynamic server functions in a fixed buffer allocation state reduces efficiency in terms of buffer usage and packet processing due to non-optimized buffer resource usage.

In addition, there was a disadvantage in that the tunnel, which is the transmission path between two nodes of a payload composed of encapsulated packets, was not properly updated, resulting in high consumption of data packets.

Recently, a tunnel update method using a tunnel CTRL thread has been highlighted as a tunnel update method in such data communications.

Republic of Korea Patent Registration No. 10-0785812 Republic of Korea Patent Publication No. 10-2017-0111455 Republic of Korea Patent Publication No. 10-2015-0081497

Accordingly, the present invention aims to provide a method for processing tunnel data updates in data communication using a tunnel CTRL thread, which is intended to perform a tunnel CTRL thread from setting up a tunnel connection to reading a command message and putting it into a command buffer when a command arrives through a tunnel session.

In addition, the purpose is to provide a method for processing tunnel data updates in data communication using a tunnel CTRL thread, which can significantly reduce work overhead in a tunnel table by using a tunnel CTRL sub-thread.

In order to solve such a problem, the present invention is characterized by including the steps of: inputting a packet; parsing an Ethernet header of the input packet; checking whether the packet is an IP packet; and parsing the IP header if it is confirmed to be an IP packet; checking the band of the source IP in a tunnel table and, if appropriate, parsing the tunnel UDP (User Datagram Protocol) header; checking whether the tunnel source port and the tunnel destination port are in the tunnel table; and, if confirmed in the above step, authenticating with a registered tunnel packet; checking whether the tunnel packet registered in the above step is a data packet; and, if the data packet is confirmed in the above step, removing the tunnel header and adding a new tunnel header; updating statics to check the port; and transmitting tunnel data to a network.

And, the step includes a step of receiving the IP packet through a smart NIC, a step of distributing the data of the IP packet for load balancing using the tunnel Ctrl thread, a step of merging the data and data of the command pool into a queue data pool, and S 3-4 of transmitting the data merged in the step to a plurality of tunnel Ctrl sub-threads.

And, in the above step, the IP packet forms a tunneling rule through a tunnel configuration agent, and if it is registered in the tunnel table according to a packet processing algorithm, it is changed into a UDP tunneling packet, and if it is not registered, it is processed as a host.

And, in the above step, Statics is characterized by the number of packets being tunneled.

In addition, in a tunnel data update processing system in data communication, it is characterized by including a plurality of tunnel configuration agents operating as virtual machines using Docker and a Statics monitor which outputs and transmits statistics on tunneled packets through a Statics thread, and including a user space where an application operates and a tunnel table and a Statics thread which outputs statistics on tunneled packets and transmits them to the Statics monitor, a pci thread which connects the user space, and an encap/decap thread which combines or removes a tunnel head, and including a smart NIC which offloads an IP-UDP tunneling function, and a kernel space which is formed between the user space and the smart NIC and executes a system drive.

In addition, when tunnel settings are entered in the tunnel configuration agent of the user space, the tunnel settings are completed in the tunnel table of the smart NIC.

Accordingly, the present invention has the effect of enabling the tunnel CTRL thread to perform the role of a server that manages a tunnel session, so that when a command arrives through a tunnel session, the tunnel CTRL thread can perform the part of reading a command message and putting it into a command buffer, thereby dividing the work and executing it.

Figure 1 is a flow chart of a tunnel data update processing method in data communication using a tunnel Ctrl thread according to the present invention.
Figure 2 is a flowchart of the process of transferring data to a tunnel Ctrl sub-thread using a tunnel Ctrl thread.
Figure 3 is a diagram showing the transmission and distribution of data to a tunnel Ctrl sub-thread using a tunnel Ctrl thread.
Figure 4 is a drawing of a tunnel table.
Figure 5 is a diagram showing the process of verifying registration in a tunnel table and transforming it into an IP-UDP tunneling packet.
Figure 6 is a block diagram of a tunnel data update process system in data communication.
Figure 7a is a diagram of the add tunnel request command message table.
Figure 7b is a diagram of the del tunnel request command message.
Figure 8 is a picture of the program structure of a smart NIC.
Figure 9 is a diagram of a management message program for rule registration.
Figure 10 is a diagram showing the rule message processing flow.
Figure 11 is a flow chart of the response process of the rule message processing of Figure 10.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the attached drawings. First, when adding reference numerals to components in each drawing, it should be noted that identical components are given the same numerals as much as possible even if they are indicated in different drawings.

In addition, when describing the present invention below, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the gist of the present invention, the detailed description will be omitted.

In addition, it is to be noted in advance that the terms used in this application are only used to describe specific embodiments and are not intended to limit the present invention, and that singular expressions also mean plural expressions unless the context clearly indicates otherwise.

Before describing the present invention, terms appearing in the specification of the present invention will be briefly explained.

UDP (User Datagram Protocol) is a protocol with relatively fast transmission speeds but lower transmission reliability than TCP. It is a connectionless oriented protocol that processes data in datagram units, which are packets with independent relationships. Datagrams are often used in services where continuity is more important than reliability, such as real-time streaming services.

A smart NIC (Smart Network Interface Card) is the part that first receives packets from the network. It performs network functions to enable the CPU (Central Processing Unit) to focus on application processing, thereby improving performance. It removes the TCP/IP Header from packet data sent and received between systems, so that the CPU can directly process the communication content between applications.

A tunnel is a passageway for transmitting control signals and data, and helps transmit data such as packets to means such as protocols or mobile terminals.

A virtual machine (VM) is a software implementation of a computing environment, and is software that emulates a computer. Operating systems and applications can be installed and run on a virtual machine.

A thread is a unit of multiple flows that are executed within a process.

FIG. 1 is a flow chart of a tunnel data update processing method in data communication using a tunnel Ctrl thread according to the present invention, FIG. 2 is a flow chart of a process of transmitting data to a tunnel Ctrl sub-thread using a tunnel Ctrl thread, FIG. 3 is a drawing showing data transmission and distribution to a tunnel Ctrl-sub-thread using a tunnel Ctrl thread, FIG. 4 is a drawing of a tunnel table, FIG. 5 is a drawing showing a process of confirming registration of a tunnel table and transforming it into an IP-UDP tunneling packet, FIG. 6 is a block diagram of a tunnel data update process system in data communication, FIG. 7a is a drawing of an add tunnel request command message, FIG. 7b is a drawing of a del tunnel request command message, FIG. 8 is a photograph of a program structure of a smart NIC, FIG. 9 is a drawing of a management message program for rule registration, FIG. 10 is a drawing showing a rule message processing flow, and FIG. 11 is a flow chart of a response process of the rule message processing of FIG. 10.

Hereinafter, a tunnel data update processing method in data communication according to the present invention will be described with reference to FIG. 1.

First, packet (not shown) data is input (S 1). The packet is a transmission unit (small piece of data) of data transmitted through a network. In data communication, in order to efficiently transmit and exchange data, data (e.g., files, etc.) is divided into an appropriate length of about 1,000 to 2,000 bits, or conversely, short data (e.g., characters or character information) is grouped into an appropriate length and control information such as a recipient address is assigned to each of them.

Next, the Ethernet header is parsed (S 2).

The packet input from the above S 1 is parsed into an Ethernet header (converted into an executable internal format) to transmit the packet safely and effectively. That is, networking of the computer due to the Ethernet header is initiated.

In the above S 2, it is checked whether the parsed packet is an IP packet, and if it is confirmed to be an IP packet, the IP header is parsed (S 3). If it is confirmed in S 2 that it is not an IP packet, it is sent to the host (400).

However, in cases like this, the tunnel data (T) is overloaded with work, which increases the workload, and there is a high possibility that the processing speed may be delayed.

Accordingly, the present invention provides a tunnel Ctrl thread (C) and a tunnel Ctrl sub-thread (S) to reduce such work load. FIG. 2 is a flow chart of a process of transferring data to a tunnel Ctrl sub-thread using a tunnel Ctrl thread. This will be described with reference to FIG. 2 and FIG. 3.

First, the IP packet confirmed in S 2 described above is received through the smart NIC (200) (S 3-1).

Then, the data of the above IP packet is distributed through load balancing using the tunnel Ctrl thread (C) (S 3-2).

The above load balancing refers to distributing data evenly, and data is input by enqueuing it.

Referring to Fig. 3, the data in S 3-2 and the data in the command pool (drawing symbol omitted) are combined into queue data (drawing symbol omitted) (S 3-3).

In this way, the merged data is dequeued and outputted, and the task of dividing it so that it can be transmitted to multiple tunnel Ctrl sub-threads (S) is executed.

All data combined in the above S 3-3 is transmitted to multiple tunnel Ctrl sub-threads (S) (S 3-4). Therefore, the tunnel Ctrl sub-threads (S) can perform the task of sending it to the host (400) by dividing the work. For reference, the number of tunnel Ctrl sub-threads (S) is preferably 5 to 10.

Therefore, by distributing the data to multiple tunnel Ctrl sub-threads (S) as described above, the workload is largely divided, which provides an excellent function that allows the tunnel table (T) to easily process many sessions.

The bandwidth of the source IP of the above IP packet is checked in the tunnel table (see Figure 4, description of the drawing symbols is omitted), and if appropriate, the tunnel UDP (User Datagram Protocol) header is parsed (S 4).

The above IP packet is checked by comparing it with the tunnel table (T) formed in the tunnel thread (210) of the smart NIC (200), and the tunnel UDP header is parsed.

Referring to FIG. 5, the IP packet received from the outside is formed into a tunneling rule (defined as a list of IP packets generated based on an IP address and port and included in a processing target) through a tunnel configuration agent (120), and is matched according to a packet processing algorithm. If it is registered in the tunnel table (T), it is changed into a UDP tunneling packet, and if it is not registered, it is processed by a host (400).

Therefore, when a rule is registered in the tunnel table (T) belonging to the smart NIC (200), IP-UDP Encapsulation/Decapsulation (removal) is performed in the smart NIC (200).

Whether the port of the above IP packet is a tunnel source port (Tunnel src.port: transmitter port) or a tunnel destination port (Tunnel dst.port: destination port) is checked in the tunnel table (T) (S 5).

In the above S 5, if the IP packet corresponds to both the tunnel source port and the destination source port, it is authenticated as a registered tunnel packet (S 6).

If, in the above S 5, the port of the IP packet does not correspond to the tunnel source port (Tunnel src.port: transmitter port) and the tunnel destination port (Tunnel dst.port: destination port), it is regarded as an unregistered tunnel packet and transmitted to the host (400).

It is checked whether the tunnel packet registered in the above S 6 is a data packet (S 7). If it is not a data packet, this is also transmitted to the host (400).

If it is confirmed that the tunnel packet registered in the above S 7 is a data packet, the tunnel data (T) header (not shown) is removed and a new tunnel data (T) header is combined (S 8). If it is also confirmed that it is not a data packet, it is sent back to the host (400).

Check the port by updating statics (S 9).

In the above S 9, the Statics is the number of IP packets that are tunneled, and this S 9 is a step of updating all of the IP packets. At the same time as updating, the corresponding tunnel source port and tunnel destination port are checked.

Finally, the newly updated IP packet from S 9 is transmitted to the network (S 10).

Below, a tunnel data update process system in data communication using a tunnel Ctrl thread according to the present invention will be described.

Referring to FIG. 6, the system of the present invention is largely composed of a user space (100) in which an application (not shown) operates, a smart NIC (200) that offloads an IP-UDP tunneling function, and a kernel space (300) formed between the user space (100) and the smart NIC (200) to execute a system drive.

In the user space (100), multiple tunnel configuration agents (120: Tunnel Configuration Agent) that operate as virtual machines (110) using Docker are formed.

The above tunnel configuration agent (120) specifies a tunnel source port and a tunnel destination port when tunneling. When tunnel settings are entered in the tunnel configuration agent (120), the tunnel settings are completed by entering and referencing the internal algorithm of the tunnel table (T) of the smart NIC (200). For reference, the number of the above tunnel configuration agents (120) is preferably 3 to 20.

As illustrated, a tunnel thread (210) containing a tunnel table (T) inside is connected to a tunnel Ctrl- sub thread (S) to enable transmission and distribution of data.

The above tunnel CTRL-sub thread (S) is connected to the tunnel thread (210) to process the session, parse the contents of the command data, execute the command, and transmit a response message for the result to the host (400).

The tunnel CTRL thread (C) manages the above sessions and distributes data so that the tunnel CTRL sub-thread (S) can process them with load balancing.

That is, the tunnel Ctrl thread (C), which performs the role of a server managing the session, executes distribution to the tunnel Ctrl-sub thread (S) so as not to cause an overload on the tunnel table (T).

Additionally, the Statics monitor (130) generates statistics on tunneled packets through the Statics thread (220) of the smart NIC (200) and transmits them to the administrator.

The smart NIC (200) is formed with a tunnel thread (210) that holds a tunnel table (T) and a static thread (220) that generates statistics on tunneled packets and transmits them to the static monitor (130).

The PCI thread (230) serves to connect the smart NIC (200) and the user space (100).

The encapsulation/decapsulation thread (240) is responsible for combining or removing the tunnel data (T) head (not shown).

Hereinafter, the operational relationship of the tunnel data update process system in data communication using the tunnel Ctrl thread according to the present invention will be described.

When an IP packet enters a smart NIC (200), a tunneling rule is input into a packet processing algorithm in the smart NIC (200) to match whether the IP packet is registered in the tunnel table (T).

The tunnel configuration agent (120) operates through a virtual machine using Docker (110) and specifies the path of the IP packet.

If the IP packet is registered in the above tunnel table (T), it is changed into an IP-UDP tunneling packet, and if it is not registered in the above tunnel table (T), it is sent to the host (400) for processing.

Below, according to an embodiment of the present invention, a tunnel CTRL thread (C) and a tunnel CTRL sub-thread (S) are formed to largely share the burden of the excessive sessions that the tunnel table (T) can handle, and this will be described.

The above tunnel CTRL thread (C) acts like a server that manages the tunnel session.

Referring to FIGS. 7a and 7b, when a packet connected to a tunnel session arrives from a host (400), the tunnel CTRL thread (C) reads an event (Add, Del) for a socket, sets up a tunnel connection, or, when a command arrives through the tunnel session, reads a command message and places it in a command buffer (not shown).

The role of parsing the received command message, executing the command contents, and sending the result to the host (400) is divided and performed by multiple tunnel CTRL sub-threads (S).

In order to easily process many sessions through the above multiple tunnel CTRL sub-threads (S), load-balancing is performed on multiple tunnel CTRL sub-threads (S).

Whenever a command is received, the socket and event information, and data information received from the host (400) are placed in the memory space allocated from the command set Pool, and one of the Queues connected to the tunnel CTRL-sub thread (S) is selected and the command data (see Figure 3, the drawing symbol is omitted) is placed in the corresponding Queue.

The above Queue distinguishes received commands and is determined by the Session ID value (a value assigned by the host to distinguish commands).

The tunnel CTRL-sub thread (S) parses the contents of the Command data, executes the command, and generates a response message for the result and sends it to the host (400).

It is confirmed whether the IP packet that has gone through the above procedure is a data packet, the existing tunnel header (not shown) is removed, and a new tunnel header is combined.

By updating the above IP packet, the updated IP packet is transmitted to the network. Then, the Statics thread (220) generates statistics on the tunneled IP packet and transmits them to the Statics monitor (130) of the user space (100).

Hereinafter, with reference to Fig. 8 and a picture of the program structure of the smart NIC, the operational relationship of the related tunnel data update process system (U) will be described. Duplicate descriptions of the previously explained contents will be omitted to some extent.

As shown, it is divided into two sides, a smart NIC (200) and a host (400), and is a form of exchanging files, etc. in a P2P (peer-to-peer) manner.

On the smart NIC (200) side, the packet processing thread, the encap/decap thread (240) and the PCI thread (230) are connected to each other.

And, on both sides of the encap/decap thread (240) and the PCI thread (230), an mPIPE (m) that provides a communication channel for transmitting network traffic between peers and a TRIO (245) that is compatible with the PCI thread (230) are respectively connected and formed.

And, a tunnel thread (210) and a static thread (220) containing a tunnel table (T) are formed at the bottom. Here, the tunnel thread (210) is connected to a tunnel CTRL-sub thread (S) that receives commands from a tunnel CTRL thread (C), but as described above, a detailed description will be omitted.

On the host (400) side, a kernel space (300), a Linux-type PCIe driver (310), Docker (110), and a plurality of connected tunnel configuration agents (120) are configured in a DTR (data-terminal-ready: data transmission preparation complete) state.

Additionally, a Statics monitor (130) is formed that receives statistics on tunneled IP packets from the Statics thread (220) of the smart NIC (200).

Tunnel information is transmitted from the tunnel configuration agent (120), and the tunnel information includes a network, a tunnel source port, a tunnel destination port, a new tunnel source IP, a new tunnel destination IP, and an interface.

Next, the tunnel Ctrl-sub thread (S) that receives the tunnel information as described above updates the tunnel information and sends tunnel setup information (success, failure, list) in response to the tunnel configuration agent (120).

As shown in Fig. 9, the tunnel setting information is determined by determining whether it is registered through the tunnel table (T) rule of the tunnel thread (210), success, failure if it is not registered, and the number of successes or failures is recorded as a number in the list.

The add part is 0, so nothing has been added, and the Socket Payload (message structure exchanged between the tunnel thread (210) and the tunnel configuration agent (120), the drawing symbol is omitted) remains the same, but the tunnel source IP and tunnel destination IP on the right side, which are IP addresses, have both been deleted.

And, the list below is 2 (since it is the 2nd case of add and del), which is the common part of add and del. is deleted, and only the leftmost type (1 Byte) is recorded.

Figure 10 is an algorithm that shows the flow of processing by receiving a rule messenger and showing the tunnel configuration agent (120) sending a response message.

First, the rule messenger is received and the Type field of the tunnel table (T) is checked (Step 1). The Type field is checked as a number (Step 1), and add is defined as '0', del is defined as '1', and list is defined as '2'.

That is, if it is in the rule, add, if it is not in the rule, del, and determine the numerical value to be written in the list of cases.

If add is recorded in the rule, the port number is searched by parsing the add format.

If a port exists, the network and IP are updated to create a success messenger and transmit it. If the port does not exist, the total list number is searched continuously, the network, port, and IP are input, and then a success messenger is created and the response message is transmitted to the user space (100) (Step 2-a).

If it does not exist in the rule and is recorded as del, the del format is parsed and the port number is searched.

If the corresponding port exists, the corresponding list is deleted, a success messenger is created and transmitted, and if the corresponding port does not exist, a failure messenger is created and a response message as described above is transmitted to the user space (100) (Step 2-b).

Then, the list parses the list format to create a failure messenger as a response messenger and transmits the response message to the user space (100) (Step 2-c).

Figure 11 is a flow chart of the response process of the rule message processing of Figure 10.

When a rule message is received through a process similar to that in the above drawing 10, a response message must be transmitted in order to transmit it to the user space (100). This process will be described below.

First, receive the response message (Step 3) and check its result field (Step 4). The result field is a numerical value indicating the result, that is, 1 for success, 0 for failure, and 2 for list.

As shown, the result field is checked and if it is '0', a failure message is output, if it is '1', a success message is output, and if it is '2', a list is output (Step 5).

Those skilled in the art will understand that the present invention, as described above, can implement other specific forms without changing the technical idea or essential features of the present invention. Therefore, it should be understood that the above-described embodiments are illustrative and not limiting.

The scope of the present invention is indicated by the appended claims rather than the detailed description above, and all changes or modifications derived from the meaning and scope of the claims and their equivalent concepts should be interpreted as being included in the scope of the present invention.

100: User Space 110: Docker
120: Tunnel Configuration Agent 130: Statics Monitor
200: Smart NIC 210: Tunnel Thread
220 : Statics thread 230 : pci thread
240: Encap/Decap Thread 245: TRIO
300 : kernel space 400 : host
T: Tunnel Table P: mPIPE
S: Tunnel CTRL-sub thread C: Tunnel CTRL thread
U: Tunnel data update process system

Claims (6)

In a method for processing tunnel data updates in data communication using a tunnel Ctrl thread,
S 1 inputting a packet;
S 2 parses the Ethernet header in the input packet;
S 3 checks whether the above packet is an IP packet, and if it is confirmed to be an IP packet, parses the IP header;
S 4, which checks the bandwidth of the source IP in the tunnel table (T) and parses the tunnel UDP header;
S 5 checks the tunnel table (T) to see if the tunnel source port and tunnel destination port are the same;
If verified in the above S 5, S 6 authenticates with a registered tunnel packet;
S 7, which checks whether the tunnel packet registered in the above S 6 is a data packet;
When the data packet is confirmed in the above S 7, the tunnel table (T) header is removed and a new tunnel table (T) header is added in S 8;
S 9 to check the port by updating Statics(220);
Includes S 10 for transmitting IP packets to the network,
In the above S 3
S 3-1 receiving the above IP packet through smart NIC (200);
S 3-2, which distributes the data of the IP packet for load balancing using the above tunnel Ctrl thread (C);
S 3-3 where the above data and the data in the command pool are merged into a queue data pool;
Includes S 3-4, which transfers the data merged in the above S 3-3 step to multiple tunnel Ctrl sub-threads (S).
A method for processing tunnel data updates in data communication using a tunnel Ctrl thread, characterized in that in the above S 4, the IP packet forms a tunneling rule through a tunnel configuration agent (120), and if it is registered in the tunnel table (T) according to a packet processing algorithm, it is changed into a UDP tunneling packet, and if it is not registered, it is processed by a host (400).
delete delete ◈Claim 4 was waived upon payment of the registration fee.◈ In the first paragraph,
A method for processing tunnel data updates in data communication using a tunnel Ctrl thread, characterized in that in the above S 9, Statics is the number of tunneled packets.
◈Claim 5 was waived upon payment of the registration fee.◈ In a tunnel data update processing system in data communication using a tunnel Ctrl thread,
It is composed of a plurality of tunnel configuration agents (120: Tunnel Configuration Agent) operating as virtual machines (110) using Docker and a Statics monitor (130) that outputs and transmits statistics on tunneled packets through a Statics thread (220), and a user space (100) where an application operates;
A tunnel thread (210) having a tunnel table (T) inside;
A tunnel CTRL-sub thread (S) that is connected to the above tunnel thread (210), processes the session, parses the contents of the command data, executes the command, and transmits a response message for the result to the host (400);
A tunnel CTRL thread (C) that manages the above sessions and distributes data so that the tunnel CTRL sub-thread (S) can process it with load balancing;
A Statics thread (220) that generates and transmits statistics on packets tunneled to the above Statics monitor (130);
A smart NIC (200) comprising a pci thread (230) connecting the user space (100) and an encap/decap thread (240) combining or removing a tunnel data (T) head, and offloading the IP-UDP tunneling function;
A tunnel data update processing system in data communication using a tunnel Ctrl thread, characterized in that it includes a kernel space (300) formed between the user space (100) and the smart NIC (200) and for executing a system drive.
◈Claim 6 was waived upon payment of the registration fee.◈ In paragraph 5,
A tunnel data update processing system in data communication, characterized in that when tunnel settings are entered in the tunnel configuration agent (110) of the above user space (100), tunnel settings are completed in the tunnel table (T) of the above smart NIC (200).

Images