Network packet filtering

Abstract

The subject matter of the invention is network packet filtering. Examples described herein relate to a network interface device comprising: an interface to a port; and a circuitry module to: perform a parallel evaluation of the plurality of rules for grouping; discarding the packet based, at least in part, on an indication made by the parallel evaluation that communication with the target is not allowed; and allowing communication of the packet based at least in part on a second indication of allowing communication with the target by the parallel evaluation. In some examples, a parallel evaluation of multiple rules is to evaluate one or more of an allowed sender Internet Protocol (IP) address range, an allowed destination IP address range, an allowed packet protocol, or an allowed egress port range.

Description

Related Applications

[0001] This application claims priority to U.S. Provisional Application No. 63 / 596,503, filed on November 6, 2023. The entire contents of this application are incorporated by reference in their entirety. Background Art

[0002] Data centers provide processing and storage resources that can be accessed by applications. For example, a car, smartphone, laptop, tablet, or Internet of Things (IoT) device can utilize a data center to perform data analysis, data storage, or data retrieval. Processing and storage resources are connected together using high-speed networking devices such as network interfaces, switches, or routers.

[0003] Network policies are used to provide security in the network to protect the network from external threats and malicious traffic. As applications move to public, private, and hybrid cloud deployments, network policies are implemented to provide secure access, firewalls, and network isolation per tenant at edge and core data centers. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Figure 1 An example system is depicted.

[0005] Figure 2 Examples of operations for configuring a network interface device to perform parallel application of rules to packets are described.

[0006] Figure 3 An example of evaluation of packets in a data plane of a network interface device is shown.

[0007] Figure 4 The implementation of network policies in a packet processing pipeline or circuit module of a network interface device is shown.

[0008] Figure 5 Depicted is an example bitmap with allow / deny decisions based on the results of a parallel lookup.

[0009] Figure 6 An example of mapping a policy of rules to packets is shown.

[0010] Figure 7 Depicts an example of mapping policies to rules and rule groups.

[0011] Figure 8 Examples of actions in a set of one or more actions that may be performed based on a range check and a match of an IPset bitmap are shown.

[0012] Fig. 9 An example process is depicted.

[0013] Fig.10An example network interface device is depicted.

[0014] Figures 11A-11C An example switch is depicted.

[0015] Fig.12 An example system is depicted. DETAILED DESCRIPTION

[0016] The network interface device can utilize access control lists (ACLs) to control communications to and from processes executed by one or more servers. For example, the network interface device can apply an Internet Protocol (IP) ACL to allow or restrict packets from a specific sender to an exit to a specific receiver. An IP ACL can be an ordered set of allow or deny conditional rules applied in a sequential manner to incoming and / or outgoing traffic until the rule matches. Evaluating ACL rules one at a time can be time consuming and increase the latency of packet communication as the number of applied rules increases. Various examples provide parallel evaluation of network policies and firewall ACL rules through match-action operations in the network interface device. The network interface device can include a packet processing circuit module that performs a range checker and a longest prefix match (LPM), the range checker can be used to check the matching of multiple destination port ranges of incoming or outgoing packets, and the longest prefix match (LPM) is used to check the matching of source or destination Internet Protocol (IP) addresses or subnets, exact matching with bit ranges, and ternary content addressable memory (TCAM) for wildcard matching. A server or host system may offload execution of the ACL to a programmable match-action pipeline. Some examples may reduce latency in processing ACL rules compared to sequential processing of ACL rules by software executed by a host processor.

[0017] In some examples, cloud and edge service providers can offload the execution of Kubernetes (K8s) network access control lists (NACLs) to a network interface device. Some examples can offload the decomposition of network policies into multiple rules for at least Kubernetes (K8s) pods to a programmable packet processing circuit module or other circuit module. The decomposition of network policies can be performed on the processor of the network interface device instead of on the core executing the application, or on the processor of the network interface device in addition to the core executing the application. Performing the decomposition of rules at the network interface device can potentially increase security and free up server resources (such as processors and memory) for use by the customer's tenant applications.

[0018] Figure 1An example system is depicted. One or more of the servers 150-0 to 150-A (where A is an integer) may be coupled to the network interface device 100 using a device interface 155 (e.g., Peripheral Component Interconnect Express (PCIe), Compute Express Link (CXL), or other) or a network connection. One or more of the servers 150-0 to 150-A may include a processor 152, a memory 160, and at least one of the components described herein. Fig.12 The processor 152 may include one or more of the following: a central processing unit (CPU), a processor core, a graphics processing unit (GPU), a neural processing unit (NPU), a general purpose GPU (GPGPU), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a tensor processing unit (TPU), a matrix math unit (MMU), or other circuit modules.

[0019] The processor 152 may include a system agent or non-core, which may include one or more of the following: a memory controller, a shared cache memory (e.g., a last level cache memory (LLC)), a cache coherency manager, an arithmetic logic unit, a floating point unit, a core or processor interconnect, a cache / home agent (CHA), an interface circuit module (e.g., a structure, memory, device), and / or a bus or link controller. The system agent may provide one or more of the following: a direct memory access (DMA) engine connection, a non-cache coherent master connection, data cache coherency between cores and arbitration cache requests, or an advanced microcontroller bus architecture (AMBA) capability.

[0020] Processor 152 may execute process 154. Process 154 may include one or more of the following: application, process, thread, virtual machine (VM), micro VM, container, Kubernetes pod, microservice or other virtualized execution environment. In some examples, process 154 may execute Kubernetes pod, Docker container, networking application or other process. Process 154 may perform packet processing based on one or more of the following: data plane development kit (DPDK), storage performance development kit (SPDK), OpenDataPlane, network function virtualization (NFV), software defined networking (SDN), evolved packet core (EPC) or 5G network slice. Some example implementations of NFV are described in the European Telecommunications Standards Institute (ETSI) specification or the open source NFV management and orchestration (MANO) from the open source Mano (OSM) organization of ETSI. A virtual network function (VNF) may include a sequence or service chain of virtualized tasks executed on general configurable hardware such as a firewall, domain name system (DNS), cache or network address translation (NAT) and may run in a virtual execution environment. VNFs can be linked together as service chains. In some examples, EPC is a 3GPP-specified core architecture for at least Long Term Evolution (LTE) access. 5G network slicing can provide multiplexing of virtualized and independent logical networks on the same physical network infrastructure.

[0021] The processor 152 may execute an operating system 156 and / or a driver 158. The process 154 may call an application programming interface (API) to communicate with the operating system 156 and / or the driver 158 to discover the ability of the network interface device 100 to perform parallel evaluation of a packet's destination port and / or source and protocol combination or a destination Internet Protocol (IP) address against a port range and / or source or destination IP address in a plurality of rules. The operating system 156 and / or the driver 158 may enable or disable the packet processor 104 and the accelerator 110 of the network interface device 100 to perform parallel evaluation of a packet's destination port and / or source or destination Internet Protocol (IP) address against a port range and / or source or destination IP address in a plurality of rules.

[0022] Process 154 may access network interface device 100 as one or more virtualized devices using virtualization technology via interface 155. Various examples of virtualization technology include single root I / O virtualization (SR-IOV) and Scalable I / O Virtualization (SIOV). The Single Root I / O Virtualization (SR-IOV) and Sharing Specification Version 1.1, released on January 20, 2010, specifies hardware-assisted performance input / output (I / O) virtualization and sharing of devices. Scalable I / O Virtualization (SIOV) allows a device to be configured to group its resources into multiple isolated assignable device interfaces (ADIs). Direct memory access (DMA) transfers to and from the ADIs are tagged with unique process address space identifier (PASID) numbers. Unlike SR-IOV's device partitioning approach, which is used to create multiple virtual functions (VFs) on a physical function (PF), SIOV enables software to flexibly compose virtual devices at a finer granularity using hardware assistance for device sharing. An example technical specification for SIOV is Scalable I / O Virtualization Technology Specification Revision 1.0 (June 2018), and earlier and later versions and variants thereof.

[0023] The packet processing circuit module 104 can process data packets transmitted between processes 154 executed by one or more servers in servers 150-0 to 150-A. As described herein, the packet processing circuit module 104 can perform ACL rule processing per pod. In some examples, multiple pods can be assigned the same policy or different policies. The data center administrator can enter the pod level K8 policy through the policy entry 180. The policy entry 180 can appear with the help of a command line interface (CLI) or a configuration file. The policy can restrict communication to and from different pods, including pods executed as processes 154. The policy can specify the allowed packet egress policy (e.g., protocol, destination port range, destination IP address, or other) and specify the allowed packet entry policy (e.g., protocol, source port range, source IP address, or other). In some examples, the control plane 170 executed on the server 150-1 can divide the policy into one or more rule groups. The rule group can be characterized by a protocol (e.g., Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Quick UDP Internet Connection (QUIC) or other). Within the rule group, the control plane 170 can decompose the rule into a destination port range check and a source or destination IP address or subnet range check (e.g., a Classless Inter-Domain Routing (CIDR) range check). The control plane 170 can transmit the rule group as the rule group 122 to the network interface device 100 to program the packet processor 104 to execute the rule group 122.

[0024] For example, the packet processor 104 of the network interface device 100 can execute the rules in the rule group 122 in parallel. For example, the packet processor 104 can execute the port range check in the rule group in parallel. Similarly, the packet processor 104 can execute the source or destination IP address or subnet range check in parallel for the rules in the rule group.

[0025] In some examples, to apply the rule 122 that restricts communication between processes, the network interface device 100 may perform an ACL as a match-action operation based on a port range, a protocol, and / or an IPSet for a destination IP address for outbound packets, and / or an IPSet for a source IP address for inbound packets to a process in the process 154. The IPSet may include one or more IP addresses, subnets, or classless inter-domain routing (CIDR). The packet processing circuit module 104 of the network interface device 100 may perform a match-action operation based on one or more of the following: exact match, longest prefix match (LPM), wildcard match (WCM), or others.

[0026] In some examples, the packet processing circuit module 104 can be configured to perform parallel evaluation of rules for incoming (receiving) packets and outgoing (transmitting) packets. For example, for outgoing packets, the packet processing circuit module 104 can be configured to perform an egress port range check and a next hop determination in parallel. For example, to perform an egress port range check, the packet processing circuit module 104 can perform an exact match operation. For example, to perform an IP address range check for an outgoing packet, the packet processing circuit module 104 can perform a longest prefix match (LPM) operation to check for a match against a range of one or more destination Internet Protocol (IP) addresses or subnets (subnets). For example, to perform an IP address range check for an incoming packet, the packet processing circuit module 104 can perform an LPM operation to check for a match against a range of one or more source IP addresses or subnets.

[0027] In some examples, the packet processing circuit module 104 may generate a bitmap for one or more of the packet ingress or egress directions to indicate whether the rule passed or failed. The bitmap may indicate what rule was matched. For example, if there is a port range match for a particular rule, the packet processing circuit module 104 may set a bit in the first bitmap indicating that the particular rule was satisfied for the packet. If there is a subnet match, the packet processing circuit module 104 may set a bit in the second bitmap indicating that the particular rule was satisfied by the packet. The packet processing circuit module 104 may compare the bitmap generated according to the parallel operation and the subnet check to determine the action to be performed on the packet. For example, the bitmap may be a logical "and" to determine together whether the associated rules match, and based on the matching of the associated rules, the packet processing circuit module 104 may access the action to be performed on the packet. Based on the failure of the associated rule to be matched, the packet processing circuit module 104 may discard the packet or trigger an error indication to the control plane 170 or the data center administrator.

[0028] For example, to access an action to be applied to a packet, packet processing circuit module 104 may access a ternary content addressable memory (TCAM) based on a wildcard match (WCM). In the case where the packet is the first packet of a flow processed by packet processing circuit module 104, packet processing circuit module 104 may store the action and packet flow information so that a single match-action rule may be executed on other packets of the flow, rather than performing parallel rule evaluations for other packets.

[0029] A packet may refer to a collection of various formats of bits that may be sent across a network, such as an Ethernet frame, an Internet Protocol (IP) packet, a Transmission Control Protocol (TCP) segment, a User Datagram Protocol (UDP) datagram, a Real-time Transport Protocol (RTP) segment, and the like. A packet may be associated with a stream. A stream may be a sequence of packets transmitted between two endpoints, typically representing a single session using a known protocol. Therefore, a stream may be identified by a set of header field values ​​or defined tuples, and for routing purposes, a stream may be identified by two tuples (e.g., source address and destination address) that identify the endpoints. For content-based services (e.g., load balancers, firewalls, intrusion detection systems, etc.), streams may be distinguished at a finer granularity by using N-tuples (e.g., source address, destination address, IP protocol, transport layer source port, and destination port). Packets in an expected stream have the same set of tuples in the packet header. A packet flow may be identified by a combination of a tuple (e.g., Ethernet type field, source and / or destination IP addresses, source and / or destination User Datagram Protocol (UDP) ports, source / destination TCP ports, or any other header field) and unique source and destination queue pair (QP) numbers or identifiers.

[0030] Reference to flows may alternatively or additionally refer to tunnels, such as Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP); Segment Routing over IPv6 Data Plane (SRv6) source routing; VXLAN tunneling services; GENEVE tunneling services; network slicing based on virtual local area networks (VLANs); the techniques described in Mudigonda, Jayaram et al., "Spain: Cots data-center ethernet for multipathing over arbitrary topologies" (NSDI. Vol. 10.2010) (hereinafter "SPAIN"); and the like.

[0031] Based on the configuration 124, the packet processing circuit module 104 can be configured to perform a match-action operation on the packet to execute the rule 122 and identify the next hop for the packet. The match-action operation can be based on one or more of the following: OneAPI, Programming Protocol Independent Packet Processor (P4), Software for Open Networking in the Cloud (SONiC), Network Programming Language (NPL), DOCA TM , Data Plane Development Kit (DPDK), Open Data Plane (ODP), Infrastructure Programmer Development Kit (IPDK), eBPF, OpenConfig, NETCONF, RESTconfAPI, x86-compatible executable binaries, or other executable binaries.

[0032] The packet processor 104 and / or the accelerator 110 may process data to be transmitted to or received from one or more of the servers 150-0 to 150-A by performing one or more of the following: encryption, decryption, data compression, data decompression, data or device authentication, next hop determination, error value checking (e.g., cyclic redundancy check (CRC) or checksum), trust verification, or other.

[0033] In some examples, the network interface device 100 may include one or more of the following: a network interface controller (NIC), a remote direct memory access (RDMA) enabled NIC, a SmartNIC, a router, a switch, a virtual switch, a forwarding element, an infrastructure processing unit (IPU), a data processing unit (DPU), or an edge processing unit (EPU). The edge processing unit (EPU) may include a network interface device that utilizes a processor and an accelerator (e.g., a digital signal processor (DSP), a signal processor, or a wireless dedicated accelerator for virtualized radio access network (vRAN), cryptographic operations, compression / decompression, etc.). The virtual switch may provide virtual machine to virtual machine communication for virtual machines in the same server or between different servers.

[0034] The packet processor 104 and / or the accelerator 110 may be implemented as one or more of the following: a CPU, a processor core, a GPU, an NPU, a GPGPU, an FPGA, an ASIC, a TPU, an MMU, a match-action circuit module, or other circuit modules.

[0035] Although examples are described with respect to the packet processing circuit module 104 performing evaluation of rules in parallel on packets, the accelerator 110 may perform evaluation of rules in parallel on one or more packets.

[0036] Figure 2 An example of operations for configuring a network interface device to perform parallel application of rules on a group is depicted. At 202, a control plane may monitor policy update messages from a data center administrator or orchestrator (e.g., a Kubernetes orchestrator, a container orchestrator, or other). Example control planes include a Kubernetes-compliant control plane, a Docker-compliant control plane, a container networking interface (CNI), or other. The data center administrator or orchestrator may submit at least: (i) a policy update that defines rules in a policy and (ii) an endpoint update request that notifies a list of pods to which the policy needs to be applied. A policy may include a defined rule group. A rule group may include a subset of rules in a policy that have the same protocol to be matched.

[0037] At 202, the control plane may generate a rule group for destination port range checking to parallelize the operation of the port range checking. For example, the control plane may generate multiple parallel rules for unspecified or wildcard (*) rules by creating rules for port ranges with different protocols (e.g., UDP, TCP, QUIC, no protocol). For example, a first rule of the parallel rules may include checking the port range of UDP protocol packets. For example, a second rule of the parallel rules may include checking the port range of TCP protocol packets. In addition, the control plane may generate rules for next hop determination that may be performed in parallel with the port range check.

[0038] For example, the control plane may assign a unique range of port range indexes (range_idx) and IPset indexes (ipset_idx) to a rule group in a policy. The packet processing circuit module may use range_idx and ipset_idx as keywords in a corresponding match action table to match the port range (e.g., range check table) and IPset (e.g., longest prefix match table) of a rule belonging to a given rule group. For example, if a port range is not specified in a rule, the control plane may convert the port range into a full port range match (e.g., 0-65535). If an IPSet is not specified in a rule, the control plane may convert an IP address into a wildcard LPM match (e.g., 0.0.0.0 / 0 with mask 0).

[0039] For policies that do not specify protocols and / or port ranges, the control plane can perform operations (a)-(d) to create rules. At (a), a rule group with rules but no protocols is created and a unique ipset_idx is associated with this rule group. At (b), an additional table (e.g., exact match table 1) that matches only on pod IP addresses but not protocols is defined and assigned the same ipset_idx. At (c), the flags MATCH_IPSET and MATCH_RULE are defined so that a match against the exact match table causes the MATCH_IPSET flag to be set to 1 (e.g., exact match table 1) based on a policy with rules with only IPset (e.g., no protocol) or causes the MATCH_RULE flag to be set to 1 (e.g., exact match table 2) based on a policy with rules with protocols (and other fields) respectively. The wildcard match (WCM) table can be configured to match only ipset_check_result or to match both range_check_result and ipset_check_result for the final allow / deny decision for the packet. At (d), priorities are assigned to the exact match tables, such that if the two exact match tables match, the actions of exact match table 2 take precedence over match table 1.

[0040] At 204, after forming the rules of the rule group, the control plane may program the packet processing pipeline of the network interface device with the rules.

[0041] Figure 3 An example of evaluation of a packet in a data plane of a network interface device is shown. In some examples, the process may be performed by a circuit module in the network interface device or a circuit module accessible to a processor. At 302, a rule group may be determined to apply to a packet received at a network interface. At 304, a port range rule check may be applied to the packet. For a match or hit in a lookup of an allowed range of one or more egress ports for the packet, the circuit module may set an indicator bit in a first bitmap, where the position of the bit in the first bitmap corresponds to a particular rule.

[0042] At 306, a destination IP address range rule check may be applied to the packet. For a match or hit in the lookup of an allowed range of one or more IP addresses for the packet, the circuit module may set an indicator bit in the second bitmap, wherein the position of the bit in the second bitmap corresponds to a particular rule. For example, an allowed range of one or more destination IP addresses may be used for outgoing packets to be transmitted from the network interface device, while an allowed range of one or more destination IP addresses may be used for packets to be outgoing from the network interface device.

[0043] At 308, if both the port range and the source IP address range match, a lookup for an action to be performed on the packet can be performed. If either the port range or the source IP address does not pass the corresponding range check or IP address check, the packet can be discarded. Other methods may include assigning first metadata to store a value that the port range check passed or failed and assigning second metadata to store a value that the IPSet check passed or failed and assigning an exact match lookup to identify whether the first metadata matches the second metadata. Based on the first metadata matching the second metadata, it can be determined that the packet passed. Based on the first metadata not matching the second metadata, it can be determined that the packet failed.

[0044] Figure 4 The network policy implementation in the packet processing pipeline or circuit module of the network interface device is shown. The packet processing pipeline or circuit module can access the matching action table stored in the ternary content addressable memory (TCAM) table to determine the final result based on the comparison of the bitmap. The control plane can configure the packet processing circuit module of the network interface device to perform the matching against the exact match table 1-3 in parallel or at least overlapping in time. For example, the control plane can be executed on a server communicatively coupled to the network interface device or can be executed on the network interface device.

[0045] The control plane can configure Table 1 for the packet processing pipeline or circuit module to determine whether there is a match between the source IP address of the packet to be sent out and the range of one or more source IP addresses. Based on the match between the source IP address of the packet to be sent out and the range of one or more source IP addresses, the ACL state of the packet can be set to allow all (e.g., allow outgoing), deny all (e.g., do not allow outgoing), or perform a search IPSET. Based on the miss of the source IP address of the packet to be sent out and the range of one or more source IP addresses, the ACL state of the packet can be set to allow all.

[0046] The control plane can configure Table 2 for the packet processing pipeline or circuit module to determine whether there is a match between the source IP address of the outgoing packet and the range of one or more source IP addresses and whether any packet protocol of the outgoing packet matches one or more protocols. Based on the match between the source IP address of the outgoing packet and the range of one or more source IP addresses and the match between the protocol of the outgoing packet and the one or more protocols, the ACL state of the packet can be set to the search rule. Based on the miss of the source IP address of the outgoing packet against the range of one or more source IP addresses, the ACL state of the packet can be set to no action, making the administrator aware of the miss and identifying the flow of the packet that triggered the miss, and recording the error identifying the flow of the packet that triggered the miss.

[0047] In some examples, the control plane may set the priority of Table 2 higher than the priority of Table 1 so that a match with Table 2 preempts the result from Table 1 for an outgoing packet. A TCAM-based longest prefix match (LPM) match may dictate rule priority. In some examples, a discard action may be taken based on an inconsistency in the results from a lookup from multiple tables, such as where a lookup against a first table indicates that a packet discard is to occur and a lookup against a second table indicates that the packet is to proceed. In some examples, where a packet matches multiple rules and the multiple rules are of varying priority levels, an action associated with the highest priority rule may be performed despite the inconsistency between the actions of the matched rules.

[0048] For a match in Table 1 and setting the lookup IPSET, the control plane can set the next action to lookup the IP set, the range of one or more allowed destination IP addresses of the packet. In some examples, the lookup IP set can be based on the LPM. For a miss in the lookup in Table 1 or a match in the lookup in Table 1 and setting allow all or deny all, the control plane can cause the next operation to be a bitmap comparison in the second operation.

[0049] For a match against Table 2 and setting the lookup rule, the control plane may set the next action to lookup the allowed range of one or more egress ports for the packet. For a match or hit in the lookup of the allowed range of one or more egress ports for the packet, the circuit module may set an indicator bit in the first bitmap, where the position of the bit in the first bitmap corresponds to the specific rule applied by Table 2. For a miss in the lookup against Table 2, the control plane may cause the next action to be no action, making the administrator aware of the miss and identifying the flow of the packet that triggered the miss, and logging an error identifying the flow of the packet that triggered the miss.

[0050] The control plane can configure Table 3 for the packet processing pipeline or circuit module to determine the egress port for the packet to be outgoing in comparison with the range of one or more destination media access control (MAC) addresses and / or destination IP addresses of the packet to be outgoing. Based on the match of one or more destination MAC addresses and / or destination IP addresses of the packet to be outgoing, the egress port for the packet can be determined and the egress port for the packet can be used to make the packet go out and / or other actions can be performed. For a miss in the lookup of Table 3, the control plane can cause the next action to be no action, making the administrator aware of the miss and identifying the flow of the packet that triggered the miss, and recording the error of identifying the flow of the packet that triggered the miss.

[0051] The control plane can configure a lookup of an IP set for a packet processing pipeline or circuit module to determine whether to allow the destination IP address of the packet to go out based on a match or hit against a range of one or more destination IP addresses. As described herein, for a match or hit in a lookup of an allowed range of one or more destination IP addresses, the circuit module can set an indicator bit in a second bitmap, where the position of the bit in the bitmap corresponds to a specific rule. For a miss against a range of one or more destination IP addresses, the control plane can cause the next action to be no action, making the administrator aware of the miss and identifying the flow of the packet that triggered the miss, and recording an error identifying the flow of the packet that triggered the miss.

[0052] The control plane can configure a second operation for the packet processing pipeline or circuit module to perform a comparison of the first bitmap and the second bitmap to determine whether the values ​​in the bitmap are the same or different. For example, matching the values ​​in the first bitmap and the second bitmap can indicate that both the egress port range check and the IP address have passed and the packet can be allowed to go out. For example, mismatching the values ​​in the first bitmap and the second bitmap can indicate that either the egress port range check or the destination IP address check has not passed and the packet can be discarded, making the administrator aware of the miss and identifying the flow that triggered the discarded packet, and recording the error that identified the flow that triggered the discarded packet. In some examples, the second operation can occur after the lookup of the IP set and can involve recycling the packet through the packet processing pipeline.

[0053] After processing the first packet of a flow, the results of the ACL processing may be stored in a match-action table with dynamic entry addition capability (e.g., add-on-miss capability). Subsequent packets in the flow may hit the match-action table, resulting in the stored action (allow or deny) being taken on subsequent packets to apply the fixed rules. Where there are a finite number of match-action stages, recirculating packets through the pipeline to perform additional match-action operations on the packets may be performed.

[0054] Although the examples are described in relation to outbound packets, the examples may be applied to inbound packets by performing a range check on the source IP address in the LPM table.

[0055] Figure 5 Depicted is an example bitmap of an allow / deny decision with results based on parallel lookups. The control plane can assign a unique index (i) to a rule in a rule group. As described herein, the evaluation of multiple port ranges for a rule in a rule group can occur in parallel for a packet and the result of rule i can be stored at position i in an n-bit bitmap (range_check_bitmap), where n is the number of rules in the rule group. A value of 1 for a bit indicates a matched rule and a value of 0 indicates that the rule does not match. Similarly, an IP address or subnet that is part of an IPSet of a rule group is evaluated immediately and the result of rule "i" is stored at position "i" in another n-bit bitmap (ipset_match_bitmap). When the same bit position matches in two bitmaps, the packet processing circuit module can allow the packet to enter or go out. When the same bit position matches in two bitmaps, the packet processing circuit module can deny the packet to enter or go out.

[0056] Figure 6An example of mapping the policy of a rule to a packet is shown. For example, policy 600 may include multiple rules. The control plane may map the policy of a rule to a packet. For example, the control plane may parallelize the evaluation of the rules in rule groups 602 and 604. For example, in rule group 602, rule 0 may evaluate a port range of 80 for TCP protocol and a destination IP address range of 10.10.10.0 to 10.10.10.24. For example, in rule group 602, rule 1 may evaluate a port range of 443 for TCP protocol and a destination IP address range of 10.10.10.0 to 10.10.10.24. For example, in rule group 602, rule 2 may evaluate a port range of 1500-2500 for TCP protocol and a destination IP address range of 20.20.20.0 to 20.20.20.24.

[0057] For example, in rule group 604, rule 0 may evaluate a port range of 1000-2000 for UDP protocol and a destination IP address range of 192.168.1.100. For example, in rule group 604, rule 1 may evaluate a port range of 1000-2000 for UDP protocol and a destination IP address range of 192.168.1.200. For example, in rule group 604, rule 2 may evaluate a port range of 1000-2000 for UDP protocol and a destination IP address range of 192.168.1.220. For example, in rule group 604, rule 3 may evaluate a port range of 53 for UDP protocol and a destination IP address range of 8.8.8.8.

[0058] For example packet 1 having a source IP address of 192.168.1.2, a destination IP address of 20.20.20.10, a TCP protocol, and an egress port of 2000, rule set 1 (602) may be applied. The rule in bit position 2 may match and the range_check_bitmap output may be 00000100. Additionally, the destination IP address of 20.20.20.10 may match the IPSet for the rule in bit position 2 and the ipset_check_bitmap output may be 00000100. Since there is a match between the range_check_bitmap and the ipset_check_bitmap, an action may be performed for packet 1 and a policy may be fixed for the tuple associated with packet 1 to other packets for the same flow as packet 1.

[0059] For example packet 2 having a source IP address of 192.168.1.2, a destination IP address of 20.20.20.10, a TCP protocol, and an egress port of 443, rule set 2 (604) may be applied. The rule in bit position 1 may match and the range_check_bitmap output may be 00000010. Additionally, the destination IP address of 20.20.20.10 may match the IPSet for the rule in bit position 2 and the ipset_check_bitmap output may be 00000100. Since there is a mismatch between the range_check_bitmap and the ipset_check_bitmap, packet 2 may be dropped and other actions may be performed (e.g., logging an error, contacting a data center administrator, or other).

[0060] For a policy with at least one rule that specifies a protocol and at least one rule that does not specify a protocol, the control plane can add a rule with no protocol to the group with defined protocols and an additional group with no protocol. A packet can be matched to a rule group (e.g., pod IP address and protocol) if the packet arrives with one of the protocols that are part of the rule group. A packet can be matched to the no-protocol group if the packet arrives with a protocol that does not match one of the protocols that are part of the rule group. Figure 7 Depicts an example of mapping policies to rules and rule groups.

[0061] For example, policy 700 may include rules that do not specify a protocol (e.g., protocol=*) but specify an allowed range of destination IP addresses (e.g., 30.30.30.0 to 30.30.30.24). Rule group 1 (702) may include port range rules and destination IP addresses for TCP protocol packets. Rule group 2 (704) may include port range rules and destination IP addresses for UDP protocol packets. The control plane may add rules to rule group 1 (702) and rule group 2 (704) that include the entire range of port ranges (e.g., 0-65535) and the allowed range of destination IP addresses (e.g., 30.30.30.0 to 30.30.30.24).

[0062] For example, for TCP protocol packets or packets with a protocol that is neither TCP nor UDP, the packet processing pipeline can execute the rules in rule group 1 (702) in parallel. For example, for UDP protocol packets or packets with a protocol that is neither TCP nor UDP, the packet processing pipeline can execute the rules in rule group 2 (704) in parallel.

[0063] For example packet 1 having a source IP address of 192.168.1.2, a destination IP address of 30.30.30.10, a TCP protocol, and an egress port of 2000, rule set 1 (702) may be applied. The rule associated with bit position 2 may match and the range_check_bitmap output may be 00000100. Additionally, the destination IP address of 30.30.30.10 may match the IPSet for the rule associated with bit position 2 and the ipset_check_bitmap output may be 00000100. Since there is a match between the range_check_bitmap and the ipset_check_bitmap, an action may be performed for packet 1 and a policy may be fixed for the tuple associated with packet 1 to other packets for the same flow as packet 1.

[0064] For example packet 2 having a source IP address of 192.168.1.2, a destination IP address of 30.30.30.10, a UDP protocol, and no specified egress port, rule set 2 (704) may be applied. Since the packet does not include a specified egress port, the egress port of the packet cannot be compared against a range. Additionally, the destination IP address of 30.30.30.10 may match the IPSet for the rule in bit position 2 and the ipset_check_bitmap output may be 00000100. There is only a match in the IPSet and the packet may be allowed to go out, and the policy may be fixed to other packets for the same flow as packet 2 for the tuple associated with packet 2.

[0065] In addition to making an allow / deny decision, additional actions can be performed. An example is incrementing a per-policy counter. Figure 8 An example of an action in a set of one or more actions that can be performed based on a range check and a match of an IPset bitmap is shown. Based on the match of the bitmap, the result can be an identifier (set_id) that provides a set of one or more actions to be performed. The set of one or more actions can include: incrementing a counter that counts the number of packets allowed, incrementing a counter that counts the number of packets discarded, incrementing a counter of existing flows in a network interface device, allowing and logging, denying and logging, or other.

[0066] Fig. 9An example process is depicted. The process may be performed by a network interface device in response to a packet to be transmitted. At 902, a determination may be made as to whether an egress policy is enabled for a source pod. For example, the egress policy may indicate that one or more rules are to be applied that restrict communication from the source pod to one or more destination pods. Based on enabling the egress policy for the source pod, the process may continue to 904. Based on not enabling the egress policy for the source pod, the process may continue to 950 to allow communication to the destination pod and allow egress of the packet.

[0067] At 904, a determination may be made as to whether the outgoing flow is fixed so that the rule is programmed to apply to the packet. The fixed rule may identify a packet flow that is allowed to go out. For example, the outgoing flow may be fixed based on a previous packet of a packet flow with a destination port within an allowed range and a destination IP address within an allowed range. As described herein, the previous packet of the packet flow may have been verified based on parallel evaluation and bitmap comparison. Based on the outgoing flow being fixed, the process may go to 906. Based on the outgoing flow not being fixed, the process may go to 910.

[0068] At 906, a determination may be made as to whether the fixed rule allows egress of the packet. For example, the fixed rule may allow egress of the packet based on the packet having a destination port within an allowed range and a destination IP address within an allowed range. Based on the fixed rule not allowing egress of the packet, the process may proceed to 908 to discard the packet. Based on the fixed rule allowing egress of the packet, the process may proceed to 950.

[0069] At 910, a determination may be made as to whether rules have been configured for the source pod. For example, the rules may be configured as one or more ACLs for the source pod in a packet processing circuit module of the network interface device. Based on the rules not being configured for the source pod, the process may proceed to 908 to drop the packet and / or make the administrator aware that the network interface device is not configured with the rules. Based on the rules being configured for the source pod, the process may proceed to 912.

[0070] At 912, a decision may be made as to whether the protocol of the packet matches one or more rules for the source pod. Based on the protocol of the packet matching one or more rules for the source pod, the process may proceed to 914. Based on the protocol of the packet not matching one or more rules for the source pod, the process may proceed to 930.

[0071] At 914, a check may be performed against the rules for the allowed destination port range. A pass or fail result may be recorded for the packet against the allowed destination port range in the first bitmap. At 916, a check may be performed against the rules for the allowed destination IP address range. A pass or fail result may be recorded for the packet against the allowed destination IP address range in the second bitmap. At 918, based on the destination port range and destination IP address range pass for the packet, the process may go to 920 to fix the flow of the packet for the egress of subsequent packets used to allow or deny the flow. For example, the destination port range and destination IP address range pass for the packet may be matched based on the first bitmap and the second bitmap.

[0072] At 930, a determination may be made as to whether a rule for an allowed destination IP address range is configured. Based on configuring an allowed destination IP address range, the process may proceed to 916. Based on not configuring an allowed destination IP address range, the process may proceed to 908.

[0073] Fig.10 An example network interface device is depicted. In some examples, as described herein, the processor and / or FPGA 1030 may be configured to perform parallel evaluation of network policies and firewall ACL rules in the network interface device. The network interface device may be configured as an endpoint receiver that is multi-homed and receives time-ordered packets, potentially reorders the packets, and merges the packet contents before copying them to the host. Some examples of the network interface 1000 are part of a data processing unit (DPU) or an infrastructure processing unit (IPU), or are utilized by an IPU or DPU. An xPU may refer to at least an IPU, a DPU, a graphics processing unit (GPU), a general-purpose GPU (GPGPU), or other processing unit (e.g., an accelerator device). An IPU or DPU may include a network interface having one or more programmable pipelines or fixed-function processors to perform offloads of operations that would otherwise be performed by a CPU. An IPU or DPU may include one or more memory devices. In some examples, an IPU or DPU may perform virtual switch operations, manage storage transactions (e.g., compression, cryptography, virtualization), and manage operations performed on other IPUs, DPUs, servers, or devices.

[0074] The network interface 1000 may include a transceiver 1002, a processor 1030, a transmit queue 1006, a receive queue 1008, a memory 1010 and an interface 1012, and a DMA engine 1014. The transceiver 1002 may be capable of receiving and transmitting packets in accordance with an applicable protocol such as Ethernet as described in IEEE 802.3, although other protocols may also be used. The transceiver 1002 may receive packets from a network and transmit packets to a network via a network medium (not depicted). The transceiver 1002 may include a PHY circuit module 1004 and a media access control (MAC) circuit module 1005. The PHY circuit module 1004 may include an encoding and decoding circuit module (not shown) to encode and decode data packets in accordance with applicable physical layer specifications or standards. The MAC circuit module 1005 may be configured to perform MAC address filtering on received packets, process the MAC header of the received packet by verifying data integrity, remove the preamble and padding, and provide packet content for processing by a higher layer. The MAC circuit module 1005 may be configured to assemble data to be transmitted into packets including a destination address and a source address together with network control information and an error detection hash value.

[0075] Processor 1030 may be one or more of the following or a combination of the following: a processor, a core, a graphics processing unit (GPU), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or other programmable hardware device that allows programming of network interface 1000. For example, an "intelligent network interface" or SmartNIC may use processor 1030 to provide packet processing capabilities in a network interface.

[0076] Processor 1030 may include a programmable processing pipeline or offload circuit module programmable by P4, Software for Open Networking in the Cloud (SONiC), Network Programming Language (NPL), DOCA TM , Data Plane Development Kit (DPDK), OpenDataPlane (ODP), Infrastructure Programmer Development Kit (IPDK), eBPF, x86 compatible executable binary files, or other executable binary files. The programmable processing pipeline may include one or more match-action units (MAUs) configured based on a programmable pipeline language instruction set. Processors, FPGAs, other special-purpose processors, controllers, devices and / or circuits may be used for packet processing or packet modification. Ternary Content Addressable Memory (TCAM) may be used for parallel match-action or lookup operations on packet header content.

[0077] The packet distributor 1024 may use receive side scaling (RSS) to provide distribution of received packets for processing by multiple CPUs or cores. When the packet distributor 1024 uses RSS, the packet distributor 1024 may calculate a hash or make another determination based on the content of the received packet to determine which CPU or core is to process the packet.

[0078] Interrupt coalescing 1022 may perform interrupt moderation, whereby interrupt coalescing 1022 waits for multiple packets to arrive, or for a timeout to expire, before generating an interrupt to a host system used to process (one or more) received packets. Receive segment coalescing (RSC) may be performed by network interface 1000, whereby portions of incoming packets are combined into a coalesced packet. Network interface 1000 provides this coalesced packet to the application.

[0079] A direct memory access (DMA) engine 1014 may copy packet headers, packet payloads, and / or descriptors directly from host memory to a network interface, or vice versa, rather than copying the packets to an intermediate buffer at the host and then using another copy operation from the intermediate buffer to a destination buffer.

[0080] In some examples, processor 1030 may be configured to perform packet reordering to reorder packets according to timestamp values ​​and / or packet sequence numbers before copying the packets to the host system via interface 1012 .

[0081] Memory 1010 may be a volatile and / or non-volatile memory device and may store any queue or instructions used to program network interface 1000. A transmission service manager may schedule the transmission of packets from a transmission queue 1006. Transmission queue 1006 may include data or references to data for transmission by a network interface. Receive queue 1008 may include data or references to data received by a network interface from a network. Descriptor queue 1020 may include descriptors that reference data or packets in transmit queue 1006 or receive queue 1008. Interface 1012 may provide an interface with a host device (not depicted). For example, interface 1012 may be compatible with or at least partially based on PCI, PCIe, PCI-x, Serial ATA, and / or USB (however, other interconnection standards may be used) or proprietary variants thereof.

[0082] Fig.11AAn example network interface device is depicted. The host 1100 may include a processor, a memory device, a device interface, and other circuit modules such as described herein. The processor of the host 1100 may execute software, such as an application (e.g., a microservice, a virtual machine (VM), a micro VM, a container, a process, a thread, or other virtualized execution environment), an operating system (OS), and a device driver. The OS or device driver may configure the network interface device or the packet processing device 1110 to communicate with a software defined networking (SDN) controller 1142 via a network to configure the operation of the one or more control planes using one or more control planes.

[0083] The packet processing device 1110 may include multiple computing complexes, such as an accelerated computing complex (ACC) 1120 and a management computing complex (MCC) 1130, as well as a packet processing circuit module 1140 and a network interface technology for communicating with other devices via a network. The ACC 1120 may be implemented as one or more of the following: a microprocessor, a processor, an accelerator, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or a circuit module described at least in relation to this document. Similarly, the MCC 1130 may be implemented as one or more of the following: a microprocessor, a processor, an accelerator, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or a circuit module described herein. In some examples, the ACC 1120 and the MCC 1130 may be implemented as independent cores in a CPU, different cores in different CPUs, different processors in the same integrated circuit, or different processors in different integrated circuits.

[0084] The packet processing device 1110 can be implemented as one or more of the following: a microprocessor, a processor, an accelerator, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or a circuit module described herein. The packet processing pipeline circuit module 1140 can process packets as directed or configured by one or more control planes executed by multiple computing complexes. In some examples, the ACC 1120 and the MCC 1130 can execute the respective control planes 1122 and 1132.

[0085] As described herein, the packet processing device 1110, ACC 1120, and / or MCC 1130 may be configured to perform parallel evaluation of network policy and firewall ACL rules in a network interface device.

[0086] The SDN controller 1142 may upgrade or reconfigure software executed on the ACC 1120 (e.g., the control plane 1122 and / or the control plane 1132) through the content of packets received through the packet processing device 1110. In some examples, the ACC 1120 may execute a control plane operating system (OS) (e.g., Linux) and / or a control plane application 1122 (e.g., a user space or kernel module) used by the SDN controller 1142 to configure the operation of the packet processing pipeline 1140. The control plane application 1122 may include a generic flow table (GFT), ESXi, NSX, Kubernetes control plane software, application software for managing cryptographic configuration, a programming protocol independent packet processor (P4) runtime daemon, a target specific daemon, a container storage interface (CSI) agent, or a remote direct memory access (RDMA) configuration agent.

[0087] In some examples, the SDN controller 1142 may communicate with the ACC 1120 using a remote procedure call (RPC) such as Google Remote Procedure Call (gRPC) or other service, and the ACC 1120 may convert the request to a target specific protocol buffer (protobuf) request to the MCC 1130. gRPC is a remote procedure call solution based on data packets sent between a client and a server. While gRPC is an example, other communication schemes may be used, such as but not limited to Java Remote Method Call, Modula-3, RPyC, Distributed Ruby, Erlang, Elixir, Action Message Format, Remote Function Call, Open Network Computing RPC, JSON-RPC, and the like.

[0088] In some examples, the SDN controller 1142 may provide packet processing rules for execution by the ACC 1120. For example, the ACC 1120 may program table rules (e.g., header field matches and corresponding actions) applied by the packet processing pipeline circuit module 1140 based on changes in policy and changes in VMs, containers, microservices, applications, or other processes. The ACC 1120 may be configured to provide network policies as flow cache rules into a table to configure the operation of the packet processing pipeline 1140. For example, the control plane application 1122 executed by the ACC may configure a rule table applied by the packet processing pipeline circuit module 1140 with rules to define a business destination based on packet type and content. The ACC 1120 may program table rules (e.g., match-actions) into a memory accessible to the packet processing pipeline circuit module 1140 based on changes in policy and changes in VMs.

[0089] For example, the ACC 1120 may implement a virtual switch such as a vSwitch or an open vSwitch (OVS), Stratum, or vector packet processing (VPP) that provides communication between virtual machines executed by the host 1100 or with other devices connected to the network. For example, the ACC 1120 may configure the packet processing pipeline circuit module 1140 regarding which VM is to receive traffic and what kind of traffic the VM can transmit. For example, the packet processing pipeline circuit module 1140 may implement a virtual switch such as a vSwitch or an open vSwitch that provides communication between virtual machines executed by the host 1100 and the packet processing device 1110.

[0090] The MCC 1130 may execute a host management control plane, a global resource manager, and perform hardware register configuration. The control plane 1132 executed by the MCC 1130 may perform provisioning and configuration of the packet processing circuit module 1140. For example, a VM executed on the host 1100 may utilize the packet processing device 1110 to receive or transmit packet traffic. The MCC 1130 may execute boot, power, management, and manageability software (SW) or firmware (FW) code to boot and initialize the packet processing device 1110, manage device power consumption, provide connectivity to a baseboard management controller (BMC), and other operations.

[0091] One or both control planes of the ACC 1120 and the MCC 1130 may define the network topology and traffic routing table contents applied by the packet processing circuit module 1140 to select the path of the packet in the network to the next hop or to the destination network-connected device. For example, a VM executing on the host 1100 may utilize the packet processing device 1110 to receive or transmit packet traffic.

[0092] The ACC 1120 may execute a control plane driver to communicate with the MCC 1130. At least to provide a configuration and provisioning interface between the control planes 1122 and 1132, the communication interface 1125 may provide control plane to control plane communication. The control plane 1132 may perform gatekeeper operations for configuration of shared resources. For example, via the communication interface 1125, the ACC control plane 1122 may communicate with the control plane 1132 to perform one or more of the following: determine hardware capabilities, access data plane configurations, reserve hardware resources and configurations, communicate between the ACC and MCC via interrupts or polling, subscribe to receive hardware events, perform indirect hardware register reads and writes for debuggability, flash and physical layer interface (PHY) configuration, or perform system provisioning for different deployments of network interface devices (such as storage nodes, tenant hosting nodes, microservice backends, compute nodes, or others).

[0093] The communication interface 1125 may be utilized by negotiation protocols and configuration protocols running between the ACC control plane 1122 and the MCC control plane 1132. The communication interface 1125 may include a general mailbox for different operations performed by the packet processing circuit module 1140. Examples of operations of the packet processing circuit module 1140 include: issuing a non-volatile memory express (NVMe) read or write, issuing a non-volatile memory express over fabric (NVMe-oF) TM ) read or write, a look-aside cryptographic engine (LCE) (e.g., compression or decompression), an address translation engine (ATE) (e.g., an input-output memory management unit (IOMMU) used to provide virtual to physical address translation), encryption or decryption, configuration as a storage node, configuration as a tenant-hosted node, configuration as a compute node, providing multiple different types of services between different Peripheral Component Interconnect Express (PCIe) endpoints, or others.

[0094] The communication interface 1125 may include one or more mailboxes accessible as registers or memory addresses. For communications from the control plane 1122 to the control plane 1132, communications may be written to one or more mailboxes by the control plane driver 1124. For communications from the control plane 1132 to the control plane 1122, communications may be written to one or more mailboxes. Communications written to the mailboxes may include descriptors including message opcodes, message errors, message parameters, and other information. Communications written to the mailboxes may include defined format messages for transferring data.

[0095] The communication interface 1125 may provide communication based on writing or reading to specific memory addresses (e.g., dynamic random access memory (DRAM)), registers, and other mailboxes that are written to and read from to pass commands and data. To provide secure communication between the control planes 1122 and 1132, the registers and memory addresses (and memory address translations) used for communication may only be available to be written to or read from by the control planes 1122 and 1132 or cloud service provider (CSP) software executing on the ACC 1120 and device vendor software, embedded software, or firmware executing on the MCC 1130. The communication interface 1125 may support communication between multiple different computing complexes, such as from a host 1100 to an MCC 1130, from a host 1100 to an ACC 1120, from an MCC 1130 to an ACC 1120, or otherwise.

[0096] The packet processing circuit module 1140 may be implemented using one or more of the following: an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a processor executing software, or other circuit modules. The control plane 1122 and / or 1132 may configure the packet processing pipeline circuit module 1140 or other processor to perform operations related to NVMe, NVMe-oF read or write, look-aside cryptographic engine (LCE), address translation engine (ATE), local area network (LAN), compression / decompression, encryption / decryption, or other acceleration operations.

[0097] Various message formats may be used to configure the ACC 1120 or MCC 1130. In some examples, as described herein, a P4 program may be compiled and provided to the MCC 1130 to configure the packet processing circuit module 1140 to perform parallel evaluation of network policy and firewall ACL rules in a network interface device.

[0098] Fig. 11B An example switch is depicted. As described herein, various examples may be used in or with a switch to perform concurrent evaluation of network policies and firewall ACL rules in a network interface device. Switch 1154 may route frames or packets of any format or in accordance with any specification from any port 1152-0 to 1152-X to any port in ports 1156-0 to 1156-Y (or vice versa). One or more of ports 1152-0 to 1152-X may be connected to a network of one or more interconnected devices. Similarly, any of ports 1156-0 to 1156-Y may be connected to a network of one or more interconnected devices.

[0099] In some examples, the switch fabric 1160 may provide routing of packets from one or more ingress ports for processing prior to egress from the switch 1154. The switch fabric 1160 may be implemented as one or more multi-hop topologies (where example topologies include torus, butterfly, buffered multi-stage, etc.), or a shared memory switch fabric (SMSF), among other implementations. An SMSF may be any switch fabric in a switch that is connected to an ingress port and an egress port, where an ingress subsystem writes (stores) packet segments into a memory of the fabric, and an egress subsystem reads (retrieves) packet segments from the memory of the fabric.

[0100] The memory 1158 may be configured to store packets received at a port before egressing from one or more ports. The packet processing pipeline 1162 may include ingress and egress packet processing circuitry modules to process incoming packets and outgoing packets, respectively.

[0101] In some examples, the packet processing pipeline 1162 may include a parser, an ingress pipeline, a buffer, a scheduler, and an egress pipeline. In some examples, the packet processing pipeline 1162 may perform the operations of the traffic manager 1163.

[0102] The packet processing pipeline 1162 can use a table that maps packet characteristics to associated output ports to determine which port to transmit a packet or frame to. In some examples, the packet processing pipeline 1162 can be configured to perform a match-action on the received packet to identify the packet processing rules and the next jump using information stored in a ternary content addressable memory (TCAM) table or an exact match table. For example, a match-action table or circuit module can be used, whereby a hash of a portion of the packet is used as an index to find an entry (e.g., a forwarding decision based on the packet header content). The packet processing pipeline 1162 can implement an access control list (ACL) or packet discard due to queue overflow. As described herein, the packet processing pipeline 1162 can be configured to perform a parallel evaluation of network policies and firewall ACL rules in a network interface device. The configuration (including its data plane) of the operation of the packet processing pipeline 1162 can be programmed using P4, C, Python, Broadcom Network Programming Language (NPL), or an x86 compatible executable binary file or other executable binary file. Processor 1166 and FPGA 1168 may be used for packet processing or modification.

[0103] The traffic manager 1163 may perform hierarchical scheduling of packet transmissions from one or more packet queues as well as transmission rate shaping and metering. The traffic manager 1163 may perform congestion management such as flow control, congestion notification message (CNM) generation and reception, priority flow control (PFC), and others. The software and circuit modules of the network interface described herein may be utilized by the switch 1154, including the MAC and SerDes.

[0104] Fig. 11C An example switch is depicted. As described herein, various examples may be used in or with a switch to perform concurrent evaluation of network policies and firewall ACL rules in a network interface device. The switch 1180 may include a network interface 1182 that may provide an Ethernet consistent interface. The network interface 1182 may support 25GbE, 50GbE, 100GbE, 200GbE, 400GbE Ethernet port interfaces. The cryptographic circuit module 1184 may perform at least media access control security (MACsec) or Internet Protocol security (IPSec) decryption for received packets or encryption for packets to be transmitted.

[0105] The various circuit modules may perform one or more of the following: service metering, packet counting, operations, administration and management (OAM), protection engine, usage instrumentation and telemetry, and clock synchronization (eg, based on IEEE 1588).

[0106] The database 1186 may store profiles of the device to configure the operation of the switch 1180. The memory 1188 may include a high bandwidth memory (HBM) for packet buffering. The packet processor 1190 may perform one or more of the following: determination of the next hop related to packet forwarding, packet counting, access list operation, bridging, routing, multi-protocol label switching (MPLS), virtual private LAN service (VPLS), L2VPN, L3VPN, OAM, data center tunnel encapsulation (e.g., VXLAN and NV-GRE), or other. The packet processor 1190 may include one or more FPGAs. The buffer 1194 may store one or more packets. The traffic manager (TM) 1192 may provide bandwidth guarantees per subscriber according to a service level agreement (SLA) and perform layered quality of service (QoS). The fabric interface 1196 may include a serializer / deserializer (SerDes) and provide an interface to the switch fabric.

[0107] The operations of the components of the switches of the examples of the devices described herein may be combined, and the components of the switches described herein may be included in other examples of the switches of the examples described herein. For example, the components of the examples of the switches described herein may be implemented in a switch system on chip (SoC) that includes at least one interface to other circuit modules in the switch system. The switch SoC may be coupled to other devices in the switch system, such as an ingress or egress port, a memory device, or a host interface circuit module.

[0108] Fig.12The system is depicted. In some examples, as described herein, the circuit modules of the system 1200 can configure the network interface device 1250 to perform parallel evaluation of network policies and firewall ACL rules in the network interface device. The system 1200 includes a processor 1210, which provides processing, operation management, and execution of instructions for the system 1200. The processor 1210 may include any type of microprocessor, central processing unit (CPU), graphics processing unit (GPU), XPU, processing core, or other processing hardware used to provide processing for the system 1200, or a combination of processors. The XPU may include one or more of the following: CPU, graphics processing unit (GPU), general purpose GPU (GPGPU) and / or other processing units (such as accelerators or programmable or fixed function FPGAs). The processor 1210 controls the overall operation of the system 1200 and may be or include one or more programmable general or special purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), etc., or a combination of such devices.

[0109] In one example, the system 1200 includes an interface 1212 coupled to the processor 1210, which may represent a higher speed interface or a high throughput interface for system components that require a higher bandwidth connection, such as the memory subsystem 1220 or the graphics interface component 1240 or the accelerator 1242. The interface 1212 represents an interface circuit that may be a separate component or integrated onto the processor die. If present, the graphics interface 1240 interfaces with a graphics component for providing a visual display to a user of the system 1200. In one example, the graphics interface 1240 generates a display based on data stored in the memory 1230 or based on operations performed by the processor 1210, or both.

[0110] The accelerator 1242 may be a programmable or fixed-function offload engine that can be accessed or used by the processor 1210. For example, an accelerator among the accelerators 1242 may provide data compression (DC) capabilities; cryptographic services such as public key encryption (PKE), cryptography, hashing / authentication capabilities, decryption; or other capabilities or services. In some cases, the accelerator 1242 may be integrated into a CPU socket (e.g., a connector to a circuit board or motherboard that includes a CPU and provides an electrical interface with the CPU). For example, the accelerator 1242 may include a single-core or multi-core processor, a graphics processing unit, a logic execution unit, a single-level or multi-level cache, a functional unit that can be used to independently execute a program or thread, an application-specific integrated circuit (ASIC), a neural network processor (NNP), programmable control logic, and a programmable processing element such as a field programmable gate array (FPGA). The accelerator 1242 may provide multiple neural networks, CPUs, processor cores, general-purpose graphics processing units, or may make the graphics processing unit available for use by artificial intelligence (AI) or machine learning (ML) models. For example, the AI ​​model may use or include any or a combination of the following: a reinforcement learning scheme, a Q-learning scheme, deep-Q learning, or an asynchronous dominant actor-critic (A3C), a combination neural network, a recursive combination neural network, or other AI or ML models. Multiple neural networks, processor cores, or graphics processing units may be made available to the AI ​​or ML model to perform learning and / or reasoning operations.

[0111] The storage subsystem 1220 represents the main memory of the system 1200 and provides storage for code to be executed by the processor 1210 or data values ​​to be used when executing routines. The memory subsystem 1220 may include one or more memory devices 1230, such as read-only memory (ROM), flash memory, one or more random access memories (RAM) (such as DRAM), or other memory devices, or a combination of such devices. The memory 1230 stores and hosts (among other things) an operating system (OS) 1232 to provide a software platform for the execution of instructions in the system 1200. In addition, applications 1234 can be executed on the software platform of the OS 1232 from the memory 1230. Applications 1234 represent programs that have their own operating logic to complete the execution of one or more functions. Processes 1236 represent agents or routines that provide auxiliary functions to the OS 1232 or one or more applications 1234 or a combination. The OS 1232, applications 1234, and processes 1236 provide software logic to provide functions for the system 1200. In one example, the memory subsystem 1220 includes a memory controller 1222, which is a memory controller used to generate and issue commands to the memory 1230. It will be understood that the memory controller 1222 can be a physical part of the processor 1210 or a physical part of the interface 1212. For example, the memory controller 1222 can be an integrated memory controller integrated onto a circuit with the processor 1210.

[0112] Application 1234 and / or process 1236 may alternatively or additionally refer to a virtual machine (VM), a container, a microservice, a processor, or other software. Various examples described herein may execute an application consisting of microservices, wherein the microservices run in their own processes and communicate using protocols such as application program interfaces (APIs), hypertext transfer protocols (HTTP) resource APIs, message services, remote procedure calls (RPCs), or Google RPCs (gRPCs). Microservices may communicate with each other using a service grid, and microservices may be executed in one or more data centers or edge networks. These services may be independently deployed using centralized management of microservices. Management systems may be written in different programming languages, and management systems may use different data storage technologies. Microservices may be characterized by one or more of the following: polyglot programming (e.g., code written in multiple languages ​​to capture additional functionality and efficiency not available in a single language), or lightweight container or virtual machine deployment, and distributed continuous microservice delivery.

[0113] In some examples, OS 1232 may be FreeBSD, Server or personal computer, VMware vSphere, openSUSE, RHEL, CentOS, Debian, Ubuntu, or any other operating system. The OS and drivers can be found on Texas etc., sold or designed to execute on processors.

[0114] In some examples, as described herein, OS 1232, a system administrator, and / or an orchestrator can enable or disable network interface 1250 to perform parallel evaluation of network policy and firewall ACL rules in the network interface device.

[0115] Although not specifically described, it will be understood that the system 1200 may include one or more buses or bus systems between devices, such as a memory bus, a graphics bus, an interface bus, or other. A bus or other signal line may communicatively couple or electrically couple components together, or both communicatively and electrically couple components. A bus may include a physical communication line, a point-to-point connection, a bridge, an adapter, a controller, or other circuit modules, or a combination. A bus may include, for example, a system bus, a peripheral component interconnect (PCI) bus, a hypertransport or industry standard architecture (ISA) bus, a small computer system interface (SCSI) bus, a universal serial bus (USB), or one or more of the Institute of Electrical and Electronics Engineers (IEEE) standard 1394 bus (Firewire).

[0116] In one example, system 1200 includes an interface 1214 that can be coupled to interface 1212. In one example, interface 1214 represents an interface circuit that can include independent components and integrated circuit modules. In one example, multiple user interface components or peripheral components or both are coupled to interface 1214. Network interface 1250 provides system 1200 with the ability to communicate with remote devices (such as servers or other computing devices) through one or more networks. Network interface 1250 may include an Ethernet adapter, a wireless interconnect component, a cellular network interconnect component, a USB (universal serial bus), or other interfaces based on wired or wireless standards or proprietary. Network interface 1250 can transmit data to devices or remote devices in the same data center or rack, which can include sending data stored in memory. Network interface 1250 can receive data from a remote device, which can include storing received data into memory. In some examples, the packet processing device or network interface device 1250 may refer to one or more of the following: a network interface controller (NIC), a NIC enabled with remote direct memory access (RDMA), a SmartNIC, a router, a switch, a forwarding element, an infrastructure processing unit (IPU), or a data processing unit (DPU). An example IPU or DPU is described herein.

[0117] In one example, the system 1200 includes one or more input / output (I / O) interfaces 1260. The I / O interfaces 1260 may include one or more interface components through which a user interacts with the system 1200. The peripheral interfaces 1270 may include any hardware interface not specifically mentioned above. Peripherals generally refer to devices that are connected to the system 1200 in a dependent manner.

[0118] In one example, the system 1200 includes a storage subsystem 1280 for storing data in a non-volatile manner. In one example, in certain system implementations, at least some components of the storage subsystem 1280 may overlap with components of the memory subsystem 1220. The storage subsystem 1280 includes (one or more) storage devices 1284, which may be or include any conventional media for storing large amounts of data in a non-volatile manner, such as one or more magnetic, solid-state, or optical-based disks or a combination. The storage device 1284 saves code or instructions and data 1286 in a persistent state (e.g., the value is retained despite the interruption of power to the system 1200). Although the memory 1230 is generally used to provide execution or operating memory for instructions to the processor 1210, the storage device 1284 may be broadly viewed as "memory." Given that the storage device 1284 is non-volatile, the memory 1230 may include volatile memory (e.g., if the power to the system 1200 is interrupted, the value or state of the data is uncertain). In one example, storage subsystem 1280 includes controller 1282 for interfacing with storage device 1284. In one example, controller 1282 is a physical part of interface 1214 or processor 1210, or may include circuits or logic in both processor 1210 and interface 1214.

[0119] Volatile memory may include memory whose state (and therefore data stored therein) is indeterminate if power to the device is interrupted. Non-volatile memory (NVM) devices may include memory whose state is deterministic even if power to the device is interrupted.

[0120] In some examples, the system 1200 may be implemented using an interconnected computing platform of processors, memories, storage devices, network interfaces, and other components. High-speed interconnects such as Ethernet (IEEE 802.3), Remote Direct Memory Access (RDMA), InfiniBand, Internet Wide Area RDMA Protocol (iWARP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Quick UDP Internet Connection (QUIC), RDMA over Converged Ethernet (RoCE), Peripheral Component Interconnect Express (PCIe), Intel Quick Path Interconnect (QPI), Intel Ultra Path Interconnect (UPI), Intel System-on-Chip Fabric (IOSF), Omni-Path, Compute Express Link (CXL), HyperTransport, High-Speed ​​Fabric, NVLink, Advanced Microcontroller Bus Architecture (AMBA) Interconnect, OpenCAPI, Gen-Z, Infinity Fabric (IF), Cache Coherent Interconnect for Accelerators (CCIX), 3GPP Long Term Evolution (LTE) (4G), 3GPP 5G, and variants thereof may be used. The data may be accessed or copied or stored to a virtualized storage node using a protocol such as NVMe over Fabric (NVMe-oF) or NVMe (e.g., a Non-Volatile Memory Express (NVMe) device may operate in a manner consistent with the Non-Volatile Memory Express (NVMe) Specification, Revision 1.3c, dated May 24, 2018 (the “NVMe Specification”), or a derivative or variant thereof).

[0121] In an example, the system 1200 may be implemented using an interconnected computing platform of processors, memory, storage devices, network interfaces, and other components. A high-speed interconnect such as PCIe, Ethernet, or optical interconnect (or a combination thereof) may be used.

[0122] The examples herein may be implemented in various types of computing and networking devices such as switches, routers, racks, and blade servers, such as those employed in data center and / or server farm environments. Servers used in data centers and server farms include arrayed server configurations, such as rack-based servers or blade servers. These servers are interconnected in communications by means of various network provisions, such as partitioning a collection of servers into local area networks (LANs) with appropriate switching and routing facilities between LANs to form a private intranet. For example, cloud hosting facilities may typically employ large data centers with a large number of servers. Blades include separate computing platforms, i.e., "servers on cards," configured to perform server-type functions. Thus, blades include components common to conventional servers, including a main printed circuit board (motherboard) that provides internal wiring (e.g., a bus) for coupling appropriate integrated circuits (ICs) and other components mounted on the board.

[0123] Various examples can be realized using hardware elements, software elements or a combination of the two. In some examples, hardware elements can include devices, components, processors, microprocessors, circuits, circuit elements (such as transistors, resistors, capacitors, inductors, etc.), integrated circuits, ASICs, PLDs, DSPs, FPGAs, memory cells, logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. In some examples, software elements can include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, processes, software interfaces, APIs, instruction sets, computing codes, computer codes, code segments, computer code segments, words, values, symbols or any combination thereof. As desired by a given implementation, determining whether to use hardware elements and / or software elements to realize an example can vary according to factors such as any number of the following: desired computing rate, power level, heat resistance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed and other design or performance constraints. A processor may be a hardware state machine, digital control logic, a central processing unit, or one or more combinations of any hardware, firmware, and / or software elements.

[0124] Some examples may be implemented using or as an article of manufacture or at least one computer-readable medium. Computer-readable media may include non-transitory storage media for storing logic. In some examples, non-transitory storage media may include one or more types of computer-readable storage media capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, and the like. In some examples, logic may include various software elements, such as software components, programs, applications, computer programs, applications, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, processes, software interfaces, APIs, instruction sets, computing codes, computer codes, code segments, computer code segments, words, values, symbols, or any combination thereof.

[0125] According to some examples, a computer-readable medium may include a non-transitory storage medium for storing or maintaining instructions, which, when executed by a machine, a computing device, or a system, causes the machine, the computing device, or the system to perform methods and / or operations according to the described examples. Instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. Instructions may be implemented according to a predefined computer language, manner, or syntax for instructing a machine, a computing device, or a system to perform a function. Instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled, and / or interpreted programming language.

[0126] One or more aspects of at least one example may be implemented by representative instructions stored on at least one machine-readable medium, which represent various logic within a processor, which when read by a machine, computing device or system causes the machine, computing device or system to fabricate logic to perform the techniques described herein. Such representations, known as "IP cores," may be stored on a tangible, machine-readable medium and supplied to various customers or manufacturing facilities to load into a manufacturing machine that actually makes the logic or processor.

[0127] The appearance of the phrase "one example" or "example" does not necessarily refer to the same example or embodiment. Any aspect described herein may be combined with any other aspect or similar aspect described herein, regardless of whether the aspect is described with respect to the same figure or element. The division, omission, or inclusion of block functions depicted in the drawings does not imply that hardware components, circuits, software, and / or elements for implementing these functions will necessarily be divided, omitted, or included in the embodiments.

[0128] The expressions "coupled" and "connected," along with their derivatives, may be used to describe some examples. For example, descriptions using the terms "connected" and / or "coupled" may indicate that two or more elements are in direct physical or electrical contact. However, the term "coupled" may also mean that two or more elements are not in direct contact, but still cooperate or interact.

[0129] The terms "first", "second" and the like herein do not represent any order, quantity or importance, but are used to distinguish one element from another element. The terms "one" and "a certain" herein do not represent the limitation of quantity, but represent the existence of at least one of the mentioned items. The term "assertion" used in this article about a signal represents the state of a signal, wherein the signal is active, and the state can be realized by applying any logic level (or logic 0 or logic 1) to the signal. The term "following" or "after..." can refer to following or following after a certain or some other event. According to alternative embodiments, other operation sequences can also be performed. In addition, depending on the specific application, additional operations can be added or removed. Any combination of variations can be used, and those of ordinary skill in the art who benefit from the disclosure will understand its many changes, modifications and alternative embodiments.

[0130] Unless expressly stated otherwise, disjunctive language such as the phrase "at least one of X, Y, or Z" is understood within the context to generally indicate that an item, term, etc. may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language is generally not intended to imply, and should not imply, that certain embodiments require that at least one of X, at least one of Y, or at least one of Z be present. Additionally, conjunctive language such as the phrase "at least one of X, Y, and Z" should also be understood to mean X, Y, Z, or any combination thereof, including "X, Y, and / or Z," unless expressly stated otherwise.

[0131] Illustrative examples of the apparatus, systems, and methods disclosed herein are provided below. Embodiments of the apparatus, systems, and methods may include any one or more of the examples described below and any combination.

[0132] Example 1 includes one or more examples, and includes a device comprising: a network interface device, the network interface device comprising: an interface to a port; and a circuit module, the circuit module being used to: perform parallel evaluation of multiple rules for a packet; discard the packet based at least in part on an indication made by the parallel evaluation that communication with a target is not allowed; and allow communication of the packet based at least in part on a second indication made by the parallel evaluation that communication with the target is allowed.

[0133] Example 2 includes one or more examples where parallel evaluation of multiple rules evaluates one or more of: allowed sender Internet Protocol (IP) address ranges, allowed destination IP address ranges, allowed packet protocols, or allowed egress port ranges.

[0134] Example 3 includes one or more examples where the parallel evaluation of multiple rules is to evaluate one or more of: multiple allowed egress port ranges for different packet protocols or one or more Internet Protocol (IP) address ranges.

[0135] Example 4 includes one or more examples in which multiple rules are to restrict communication between Kubernetes pods.

[0136] Example 5 includes one or more examples, wherein: based on a match of a group with a first rule and a second rule among multiple rules, an action from the first rule is applied to the group, the first rule and the second rule indicate different actions for the group, and a priority of the first rule is higher than a priority of the second rule.

[0137] Example 6 includes one or more examples wherein the parallel evaluation is to generate at least one bitmap to indicate a hit or a miss for a particular rule among the plurality of rules, and is to indicate whether communication with the target is allowed or not allowed based on the at least one bitmap.

[0138] Example 7 includes one or more examples, wherein: the network interface device includes a packet processing circuit module to perform parallel evaluation as a match-action operation, and the network interface device includes one or more of the following: a network interface controller (NIC), a remote direct memory access (RDMA) enabled NIC, a SmartNIC, a router, a switch, a forwarding element, an infrastructure processing unit (IPU), a data processing unit (DPU), or an edge processing unit (EPU).

[0139] Example 8 includes one or more examples and includes at least one non-transitory computer-readable medium, wherein the at least one non-transitory computer-readable medium includes instructions stored thereon, which, if executed by one or more processors, cause the one or more processors to: based on a policy applied to communication between processes: generate a first rule set associated with a first packet protocol for execution by a packet processing circuit module of a network interface device and generate a second rule set associated with a second packet protocol for execution by the packet processing circuit module, wherein: the first rule set includes a first rule and a second rule, the second rule set includes a third rule and a fourth rule, based on encoding the packet using the first packet protocol, the packet processing circuit module is to apply the first rule to the packet in parallel with the second rule, and based on encoding the packet using the second packet protocol, the packet processing circuit module is to apply the third rule to the packet in parallel with the fourth rule.

[0140] Example 9 includes one or more examples wherein: a first rule checks the egress port of a packet against a first range of egress ports, a second rule checks the egress port of a packet against a second range of egress ports, a third rule checks the egress port of a packet against a third range of egress ports, and a fourth rule checks the egress port of a packet against a fourth range of egress ports.

[0141] Example 10 includes one or more examples wherein: a first rule checks a destination Internet Protocol (IP) address of a packet against a first range of destination IP addresses, a second rule checks a destination IP address of a packet against a second range of destination IP addresses, a third rule checks a destination IP address of a packet against a third range of destination IP addresses, and a fourth rule checks a destination IP address of a packet against a fourth range of destination IP addresses.

[0142] Example 11 includes one or more examples wherein: a first rule checks a source Internet Protocol (IP) address of a packet against a first range of source IP addresses, a second rule checks the source IP address of the packet against a second range of source IP addresses, a third rule checks the source IP address of the packet against a third range of source IP addresses, and a fourth rule checks the source IP address of the packet against a fourth range of source IP addresses.

[0143] Example 12 includes one or more examples in which a packet processing circuit module of a network interface device is to perform a parallel evaluation of rules in a first rule set by generating at least one bitmap to indicate a hit or miss by a packet for a specific rule in the first rule set, and is to indicate whether communication with a target process in the process is allowed or not based on the at least one bitmap.

[0144] Example 13 includes one or more examples, wherein based on a match of a packet with a first rule and a second rule in a first rule set, a packet processing circuit module is to apply an action from the first rule to the packet, the first rule and the second rule indicate different actions for the packet, and a priority of the first rule is higher than a priority of the second rule.

[0145] Example 14 includes one or more examples wherein the process includes Kubernetes pods, and the policy restricts communication between the Kubernetes pods.

[0146] Example 15 includes one or more examples and includes a method comprising: a network interface device: performing parallel evaluation of multiple rules for a packet by performing match-action operations; dropping the packet based at least in part on the parallel evaluation indicating that communication with the pod is not allowed; and allowing communication of the packet based at least in part on the parallel evaluation indicating that communication with the pod is allowed.

[0147] Example 16 includes one or more examples wherein the parallel evaluation of multiple rules includes evaluating one or more of: allowed sender Internet Protocol (IP) address ranges, allowed destination IP address ranges, allowed packet protocols, or allowed egress port ranges.

[0148] Example 17 includes one or more examples in which multiple rules restrict communication between Kubernetes pods.

[0149] Example 18 includes one or more examples and includes storing, based on matching of the packet to the plurality of rules, actions associated with the matching of the plurality of rules, and the network interface device applying the stored actions on subsequent packets of the flow associated with the packet.

[0150] Example 19 includes one or more examples, and includes generating at least one bitmap indicating a hit or miss for a particular rule among a plurality of rules, and indicating permission or disapproval of communication with the pod based on the at least one bitmap.

[0151] Example 20 includes one or more examples, and includes generating a first bitmap indicating a hit or miss for a port range check for a first rule of a plurality of rules; generating a second bitmap indicating a hit or miss for an Internet Protocol (IP) range check for the first rule; and indicating whether communication with the pod is allowed or not allowed based on the first bitmap and the second bitmap.

Claims

1. A device comprising: A network interface device, the network interface device comprising: Interface to the port; and A circuit module, wherein the circuit module is used to: Performing parallel evaluation of multiple rules for grouping; discarding the packet based at least in part on an indication by the parallel evaluation that communication with the target is not permitted; and Communication of the packet is permitted based at least in part on a second indication by the parallel evaluation that communication with the target is permitted.

2. The device according to claim 1, wherein: The parallel evaluation of multiple rules is to evaluate one or more of: allowed sender Internet Protocol (IP) address ranges, allowed destination IP address ranges, allowed packet protocols, or allowed egress port ranges.

3. The device of claim 1, wherein: The parallel evaluation of multiple rules is to evaluate one or more of: multiple allowed egress port ranges for different packet protocols or one or more Internet Protocol (IP) address ranges.

4. The device of claim 1, wherein: The multiple rules are to restrict the communication between Kubernetes pods.

5. The apparatus of claim 1, wherein: Based on matching the packet with a first rule and a second rule among the plurality of rules, an action from the first rule is applied to the packet, the first rule and the second rule indicate different actions for the packet, and a priority of the first rule is higher than a priority of the second rule.

6. The device according to any one of claims 1 to 5, wherein: The parallel evaluation is to generate at least one bitmap to indicate a hit or a miss for a specific rule among the plurality of rules, and is to indicate whether communication with the target is allowed or not based on the at least one bitmap.

7. The apparatus of any one of claims 1 to 6, wherein: The network interface device includes a packet processing circuit module, the packet processing circuit module is to perform the parallel evaluation as a match-action operation, and The network interface device includes one or more of the following: a network interface controller (NIC), a remote direct memory access (RDMA) enabled NIC, a SmartNIC, a router, a switch, a forwarding element, an infrastructure processing unit (IPU), a data processing unit (DPU), or an edge processing unit (EPU).

8. At least one non-transitory computer-readable medium comprising instructions stored thereon that, if executed by one or more processors, cause the one or more processors to: Based on the strategy applied to the communication between processes: generating a first set of rules associated with a first packet protocol for execution by a packet processing circuit module of a network interface device, and generating a second set of rules associated with a second packet protocol for execution by the packet processing circuit module, wherein: The first rule set includes a first rule and a second rule, The second rule set includes a third rule and a fourth rule, The packet processing circuit module is to apply the first rule in parallel with the second rule on the packet based on encoding the packet using the first packet protocol, and The packet processing circuit module is to apply the third rule in parallel with the fourth rule on the packet based on encoding the packet using the second packet protocol.

9. The at least one non-transitory computer-readable medium of claim 8, wherein: The first rule checks the egress port of the packet against a first range of egress ports, the second rule checks the egress port of the packet against a second range of egress ports, The third rule checks the egress port of the packet against a third range of egress ports, and The fourth rule checks the egress port of the packet against a fourth range of egress ports.

10. The at least one non-transitory computer-readable medium of claim 8, wherein: The first rule checks a destination Internet Protocol (IP) address of the packet against a first range of destination IP addresses, The second rule checks the destination IP address of the packet against a second range of destination IP addresses, The third rule checks the destination IP address of the packet against a third range of destination IP addresses, and The fourth rule checks the destination IP address of the packet against a fourth range of destination IP addresses.

11. The at least one non-transitory computer-readable medium of claim 8, wherein: The first rule checks a source Internet Protocol (IP) address of the packet against a first range of source IP addresses, The second rule checks the source IP address of the packet against a second range of source IP addresses, The third rule checks the source IP address of the packet against a third range of source IP addresses, and The fourth rule checks the source IP address of the packet against a fourth range of source IP addresses.

12. The at least one non-transitory computer-readable medium of any one of claims 8 to 11, wherein: The packet processing circuit module of the network interface device is to perform parallel evaluation of the rules in the first rule set by generating at least one bitmap to indicate a hit or miss of a specific rule in the first rule set by the packet, and is to indicate whether communication with a target process in the process is allowed or not based on the at least one bitmap.

13. At least one non-transitory computer-readable medium as claimed in any one of claims 8 to 12, wherein: Based on the matching of the packet with the first rule and the second rule in the first rule set, the packet processing circuit module applies the action from the first rule to the packet, the first rule and the second rule indicate different actions for the packet, and the priority of the first rule is higher than the priority of the second rule.

14. At least one non-transitory computer-readable medium as claimed in any one of claims 8 to 13, wherein: The process includes Kubernetes pods and the policy restricts communication between Kubernetes pods.

15. A method comprising: Network interface device: Performing parallel evaluation of multiple rules for grouping by performing match-action operations; discarding the packet based at least in part on the parallel evaluation indicating that communication with the pod is not permitted; as well as Communication of the group is permitted based at least in part on the parallel evaluation indicating that communication with the pod is permitted.

16. The method of claim 15, wherein: The parallel evaluation of multiple rules includes evaluating one or more of: an allowed sender Internet Protocol (IP) address range, an allowed destination IP address range, an allowed packet protocol, or an allowed egress port range.

17. The method of claim 15, wherein: The multiple rules restrict the communication between Kubernetes pods.

18. The method of any one of claims 15 to 17, comprising: Based on the matching of the packet to the plurality of rules, storing actions associated with the matching of the plurality of rules, and The network interface device applies the stored action on subsequent packets of the flow associated with the packet.

19. The method of any one of claims 15 to 18, comprising: generating at least one bitmap indicating a hit or a miss for a particular rule of the plurality of rules, and Communication with the pod is permitted or not permitted based on the at least one bitmap.

20. The method of claim 15, comprising: generating a first bitmap indicating a hit or a miss for a port range check for a first rule of the plurality of rules; generating a second bitmap indicating hits or misses for an Internet Protocol (IP) range check for the first rule; and Whether communication with the pod is allowed or not is indicated based on the first bitmap and the second bitmap.

Images