Migrating Unicore Network Packet Processing Applications to Multicore

Transcription

1 August, 2009 Migrating Unicore Network Packet Processing Applications to Multicore Challenges and Techniques (1.0) Wilson Lo Architect, Network Software Division, NMG service names are the property of their respective owners. Freescale Semiconductor, Inc

2 Outline Characteristics of Unicore Network Packet Processing Applications Potential areas to be considered for multicore migration Multicore Migration Strategies (SoC with homogenous cores) SMP/AMP/Hybrid/Partitioning Advantages/Disadvantages Deep Dive into SMP Strategies for multicore-based real applications Stateless Packet processing applications E.g. Routers/Bridges Stateful Packet processing Applications E.g. Stateful Inspection Firewall Proxy-based Applications E.g. POP3, IMAP Proxy with Anti Virus & Anti Spam, Web Proxy with URL Filtering QorIQ P4080 features for SMP/AMP/Hybrid Examples for Migration Models Example for SMP Model Example for Hybrid Model service names are the property of their respective owners. Freescale Semiconductor, Inc

3 Unicore Network Packet Processing Applications - Characteristics service names are the property of their respective owners. Freescale Semiconductor, Inc

4 Stateless Packet Processing Applications - Characteristics Examples Characteristics No Special State maintained across packets Switches, Routers etc. Lookup tables e.g. Routing DB/Forwarding DB - Looked up on a per packet basis (Frequent reads) - DB update infrequent (Infrequent writes) - Potential large number of routes/fdb entries Statistics - Updated on per packet basis (Frequent writes) - Read by management applications (Infrequent reads) Packet ordering - Typically packets are not re-ordered, with exceptions such as QoS service names are the property of their respective owners. Freescale Semiconductor, Inc

5 Stateful Packet Processing Applications - Characteristics Examples Characteristics Session data structure to track states across packets belonging to a connection -Session Lookup and update on per packet basis (Frequent reads and Frequent Writes) Typically millions of sessions maintained in a Session Table Sessions fairly independent of each other, with a few exceptions Stateful Inspection Firewall, IPS, IPSec-VPN etc. Simultaneous access of a session across multiple processing contexts is infrequent Deletion based on inactivity/lifetime and/or special packets Packet Ordering -Packet re-ordering across sessions is not expected. -Packets should not be re-ordered within a flow Offload accelerators - Pattern matching engine, Security Engine Configuration Data -Frequent access upon session creation (Frequent reads) -Infrequent updates by management agents Statistics -Update within a session - Frequent updates on a per packet basis -Update across a session Relatively infrequent, but not necessarily small. -Infrequent reads by management applications. service names are the property of their respective owners. Freescale Semiconductor, Inc

6 Proxy Applications - Characteristics Examples Characteristics SMTP, IMAP, POP3 Proxy with Anti Virus/Anti Spam, HTTP Proxy with URL Filtering, etc. Socket based applications typically multithreaded -Master and Worker, threads or processes -Threads/Processes handle multiple sessions Session fairly independent of each other, with some exceptions Offload dedicated computational chores to other processes. service names are the property of their respective owners. Freescale Semiconductor, Inc

7 Application Migration Strategy for Multicore service names are the property of their respective owners. Freescale Semiconductor, Inc

8 Migration Strategies Asymmetric Multiprocessing (AMP) Single Image Multifunction AMP Map different functions of application to different cores SINGLE IMAGE AMP CORE-1 -Function 1 IMAGE-1 Packets visit multiple cores for different function processing Queues and Inherent pipelining Example Firewall/IPS/IPSec-VPN in three different cores CORE-2 -Function 2 CORE-3 -Function 3 service names are the property of their respective owners. Freescale Semiconductor, Inc

9 Migration Strategies AMP (Contd..) Multiple independent applications Independent application images or functions mapped to different cores In this scenario, packets are distributed such that a given packet needs to visit only one specific core for application processing. Example - Based on VLAN ID to customer mapping, a specific core could be dedicated to particular customer MULIPLE INDEPENDENT APPS CORE-1 -Function 1 CORE-2 -Function 1 IMAGE-1 IMAGE-2 MULTI IMAGE AMP CORE-1 -Function 1 CORE-2 -Function 2 IMAGE1 IMAGE2 Multi Image AMP Simple variation of Single Image AMP Different images run on different cores each offering a specific function Packets visit images through queues for complete processing Use Case Integration with third party images CORE-3 -Function 1 Fig-1 IMAGE-3 CORE-3 -Function 3 Fig-2 IMAGE3 service names are the property of their respective owners. Freescale Semiconductor, Inc

10 Migration Strategies Symmetric Multiprocessing (SMP) All cores do all functions; no need for function to core mapping Packets typically visit one core for all processing Runs packet processing to completion Example Use Case Security Appliance that includes Firewall, IPSec-VPN and IPS functions running on Linux Kernel or Bare Metal OS SINGLE IMAGE SMP IMAGE1 CORE-1 -Function 1 -Function 2 -Function 3 CORE-2 -Function 1 -Function 2 -Function 3 CORE 3 -Function 1 -Function 2 -Function 3 service names are the property of their respective owners. Freescale Semiconductor, Inc

11 Migration Strategies Hybrid SMP and AMP SMP and AMP in single image Some functions in SMP mode on some cores Some functions in AMP on some cores Queues between the functions Example - Some cores running Firewall/VPN/IPS in SMP mode, One core running SSL-VPN and the other core running Proxy applications Single Image CORE-1 SMP -Function 1 Function 2 Function 3 CORE-2 SMP -Function 1 Function 2 Function 3 CORE-3 AMP -Function4 IMAGE 1 CORE-4 AMP -Function5 service names are the property of their respective owners. Freescale Semiconductor, Inc

12 Migration Strategies Hybrid SMP and AMP (contd..) SMP and AMP in separate images (Partitioning) Some cores run SMP image Some cores run AMP image Queues between the images E.g.- Third party or legacy application integration SMP And AMP Image CORE-1 -Function 1 Function 2 Function 3 CORE-2 -Function 1 Function 2 Function 3 IMAGE 1 SMP SMP and SMP Image CORE-1 -Function 1 Function 2 Function 3 CORE-2 -Function 1 Function 2 Function 3 IMAGE 1 SMP Multiple SMP Images used in AMP model (Partitioning) Some cores run one SMP image Some cores run another SMP image Queues for communication between images E.g. Control Plane/Data Plane model. CORE-3 -Function4 CORE-4 -Function5 Fig-1 IMAGE 2 AMP IMAGE 3 AMP Fig-2 CORE-1 -Function 4 Function 5 CORE-2 -Function 4 Function 5 IMAGE 2 SMP service names are the property of their respective owners. Freescale Semiconductor, Inc

13 Comparison Migration Strategies AMP (Single Image or Multiple Images) Advantages Minimal and easier changes in code; Fast development Efficient use of core specific caches for code (IC) Disadvantages Pipelining Issues Latency may increase Out of order Each core runs different functions. Since some packets may have to traverse additional cores for required processing while others do not, there is high chance of out-of-order packet delivery. Uneven core utilization Difficult to predict traffic behavior Some functions require more cycles than others Scaling issues when there is less functionality and more cores available to map. SMP Better utilization of processing power Any core can do any work. Cores are not reserved for functionality. Improved latency No pipelining issues Code changes may be required. Single threaded user space applications, Linux kernel space or bare metal applications do require code changes Possible performance Impact [*] Cache thrashing if cache is dedicated to the core Contention for protected shared data In AMP memory required for each function has to be reserved and assigned at design time In SMP memory is accessed by all cores and does not require any reservation. [*] SMP Techniques discussed later in this session help in reducing the performance degradation due to SMP service names are the property of their respective owners. Freescale Semiconductor, Inc

14 Implementation of SMP Strategies for Multicore-based Real Applications service names are the property of their respective owners. Freescale Semiconductor, Inc

15 Stateless Application - Migration into SMP Mapping Techniques Characteristics No special state maintained across packets Lookup Tables -Potential large number of routes/fdb entries -Looked up on a per packet basis (Frequent reads) -DB update infrequent (Infrequent writes) Statistics -Updated on per packet basis (Frequent writes) -Read by management applications (Infrequent reads) Packet ordering - Typically packets are not re-ordered, with exceptions such as QoS Mapping Technique No special considerations Read/Write lock for routing table, forwarding table -Packet forwarding with read lock -Routing table update with write locks -Per core statistics + consolidation -Decorated storage(p4080) Special hardware features such as ORP in P4080 service names are the property of their respective owners. Freescale Semiconductor, Inc

16 Stateless Application - Migration into SMP Other Details Expectations from multicore hardware for packet distribution Packet Distribution -Interface based -VLAN header based -3 Tuple based -Round Robin scheduling of interrupts to cores Priority-based scheduling -When core asks for work, hardware returns the next packet based on QoS priority. Performance degradation due to SMP How to mitigate? Most multicore processors mitigate cache thrashing by having shared L2/L3 cache. Contention for protected shared resources is much less because of infrequent updates. service names are the property of their respective owners. Freescale Semiconductor, Inc

17 Stateful Application - Migration into SMP Mapping Techniques Characteristics Session to track states across packets belonging to a connection -Frequent reads (Lookup) and writes (updates) on per packet basis Sessions maintained in Session Table Sessions fairly independent of each other, with few exceptions Simultaneous access of session across multiple processing contexts Deletion based on inactivity/lifetime and/or special packets Packet Ordering -Packet re-ordering is not expected. -Packets should not be re-ordered within a flow as new packets processing is impacted by state left by previous packet of the session. Configuration data -Frequent reads (upon session creation) and Infrequent writes (upon update) Statistics -Update within a session - Frequent updates on a per packet basis -Update across a session Relatively infrequent, but not necessarily small. -Infrequent reads by management applications. Mapping Technique Session parallelization technique Map multiple sessions across multiple cores such that one session is processed by only one core at any point of time. Read/Write Lock Write mode for session creation and deletion; read mode during packet processing Use locks Use Reference counting technique Multi-step delete handling i.e.- Mark first, delete later Special hardware features such as ORP, FMAN capabilities in P4080 Backlog queue in session parallelization technique Read/Write Lock Read mode for packet processing; Write mode during update Within a session -Implicitly handled by session parallelization technique Across session -Decorated storage (P4080) /Per core statistics service names are the property of their respective owners. Freescale Semiconductor, Inc

18 Stateful Application - Migration into SMP Session Parallelization Technique Why it is needed Removes unnecessary core spinning if same session were to be processed simultaneously by multiple cores Description of Technique One session being processed in only one core at any point of time While core x processes session a, core y can process session b and so on. Multiple sessions mapped to multiple cores Variations of Technique Static session pinning to core where all packets of a given session can be made to be processed by same core by hardware packet distribution No Static session to core affinity. Packets of a given session can be processed by different cores at different times service names are the property of their respective owners. Freescale Semiconductor, Inc

19 Stateful Application - Migration into SMP Session Parallelization Technique Received Packet Session Lookup Core 1 Backlog Q Empty Session IN USE == NO, Set Session IN USE Session Function 1 Session Function 2 Backlog Q!= EMPTY; Dequeue Packet Received Packet Session Lookup Session IN USE == YES Core 2 Queue in Backlog Q Exit to Main Loop; Process next pkt Received Packet Session Lookup Session IN USE == YES Core 3 Queue in Backlog Q t0 t1 t2 t3 Exit to Main loop; Process Next packet service names are the property of their respective owners. Freescale Semiconductor, Inc

20 Stateful Application - Migration into SMP Other Techniques Technique Why it is needed Description Reference counting Deletion handling Operations on a session such as deletion or update may happen simultaneously from different cores. Because multiple references may be held, immediate deletion is not possible Increment reference count while session is being accessed. Decrement reference count when session is no longer needed. When reference is held, the session cannot be freed. Multi-step deletion Markup for deletion and subsequent cleanup Critical section Avoid race conditions Use Locks Improve performance by using fine-grained locks service names are the property of their respective owners. Freescale Semiconductor, Inc

21 Stateful Application - Migration into SMP Other Details Expectations from multicore hardware for packet distribution Packet Distribution -Interface based -VLAN header based -3 Tuple based or 5 Tuple based -Round Robin scheduling of interrupts to cores Priority based scheduling -When core asks for work, hardware returns the next packet based on QoS priority. Performance degradation due to SMP How to mitigate? Most multicore processors mitigate cache thrashing impact by having shared L2/L3 cache. By virtue of session parallelization technique, resource contention is greatly reduced. service names are the property of their respective owners. Freescale Semiconductor, Inc

22 Proxy Applications- Migration into SMP Characteristics Mapping Socket-based applications typically multithreaded Master and Worker, threads or processes Threads/Processes handle multiple sessions Sessions fairly independent of each other, with some exceptions Assign threads/processes to cores Use Mutex/Spin-locks to protect critical section/resources Offload dedicated computational chores to other processes Assign threads/processes to cores. service names are the property of their respective owners. Freescale Semiconductor, Inc

23 Memory Migration into SMP Memory and Performance Implications Marginal increase in memory requirement To support locks Per core statistics variables duplicate variables across cores Queues and variables required for Session parallelization technique Performance If there is no resource contention, there is no performance degradation. Quantification In a pure firewall application, performance increases almost linearly with more cores. If firewall has features such as rate limiting across sessions etc. (which causes some resource contention) there could be around 5 to 10% performance degradation. service names are the property of their respective owners. Freescale Semiconductor, Inc

24 QorIQ P4080 Processor service names are the property of their respective owners. Freescale Semiconductor, Inc

25 QorIQ P4080 Processor Feature FMAN QMAN ODP/ORP Decorated Storage Shared L3 cache Hypervisor Support Atomic variable Enabling Applications for Multicore Packet distribution Inter-function/Inter-Image Queuing in AMP/SMP or hybrid model Packet order preservation and restoration Statistics Mitigates cache thrashing Partitioning in AMP/SMP/hybrid model References, Critical resources Lock routines required in SMP are typically available in Linux or bare metal OS service names are the property of their respective owners. Freescale Semiconductor, Inc

26 Migration Models - Examples service names are the property of their respective owners. Freescale Semiconductor, Inc

27 Model SMP Model All cores running all functionality in SMP Mode Functionality Firewall IPSec-VPN IPS Anti-X Proxies TCP/IP Anti-X SMTP/S Proxy POP3/S Proxy HTTP Proxy L3/L4 Attack Defense Migration Model Single Image SMP VortiQa Software with U for Enterprises IKEV1/v2 PKI (SCEP,OCSP) XAUTH, EAP IRAS, IRAC L2TPoIPSEC ACLs Embedded Management: CLI, HTTP, LDSV, SYSLOG, Firewall/NAT ALGs QoS- Traffic Policing Proxy Infra LAN/WAN Mgmt DHCPC, DHCPS PPPoE, PPTP, L2TP Dyn DNS, DNSRD Routing (RIP v1/v2) IGMP proxy Intrusion Detection & Prevention Engine Session Management P2P/IM Detectio n Engine HA Infra. VSRP HA Monitor HA Xport IPSec Engine QoS- Traffic Shaping Authentication LDAP RADIUS Local DB High Availability User Space Kernel Space Ethernet, VLAN, Bridging, WAN Protocols, WAN Load Balancing Hardware Frame Manager/Ethernet Controller Security Engine (SEC) Pattern Matching Engine service names are the property of their respective owners. Freescale Semiconductor, Inc

28 Model Hybrid Model Control Plane SMP Data Plane SMP CP-DP communication QMAN Functionality Firewall IPSec-VPN IPS/P2P Migration Model Control Plane/Data Plane Hybrid Model VortiQa Software with U for Service Providers IKEV1/v2 L3/L4 Attack Defense PKI (SCEP,OCSP) XAUTH, EAP IRAS, IRAC ACLs Firewall/NAT Embedded Management: CLI, HTTP, LDSV, SYSLOG, ALGs Proxy Infra LAN/WAN Routing Protocols DNSRD DP Monitoring QOS- Traffic Policing & Shaping CP-DP Communications CP-DP Communications Intrusion Detection & Prevention Engine Session Management Authentication LDAP RADIUS Local DB P2P/IM Detection Engine IPSec Engine IP Reassembly CP-DP Database Sync Route Updater ARP Helper Interfaces Helper CP-DP Dynamic Databases Routing Interfaces ARP VSGs Control Plane Data Plane Ethernet Interfaces, VLAN, Bridging Light Weight Executive (LWE) Hardware - Data Path Acceleration Architecture (DPAA) Frame Manager Queue Manager Buffer Manager Security Engine (SEC) Pattern Matching Engine service names are the property of their respective owners. Freescale Semiconductor, Inc

29