Recently, with new hardware architectures such as Reconfigurable Match Tables and languages such as P4, the Software Defined Networking community has started to bring linerate dataplane programmatic flexibility inside switching chipsets. Nowadays, the most diffused approach to packet manipulation is to have a pipeline of match/action stages in which the packet”flows” while being modified according to match events. Great effort has been put on improving the programmability of the match engine of the hardware architectures that implement this sort of pipeline, but very few attempts has been made to make the actions truly programmable, remaining stuck with aconcept of ”atomic” action. We will see how a domain-specific HW architecture, called Packet Manipulation Processor (PMP), is able to efficiently support micro-programs implementing such programmable actions. About the author: Marco Spaziani Brunella is a Researcher for CNIT at University of Rome Tor Vergata. In the last year, he focused on CPU architectures suitable for SDN and hardware-implementable data structures such as Cuckoo hash and Bloom filters for networking.

1. Packet Manipulator Processor:
Smashing «atomic» ac8ons
Speaker: Marco Spaziani Brunella
marco.spaziani.brunella@uniroma2.it
DevLab 19 & 20 September 2017
San Josè, CA

2. Talk Summary
1. Current state and background
2. What is Packet Manipulator Processor?
3. Programming the PMP
4. Packet Manipulator System
5. Performance highlights
6. Synthesis details
7. Future works, resources and acknowledgements

3. 1– Current state and background
Open Flow
Match Ac8on
Very flexible
Pre-
implemented;
can only be
“chosen”
Custom NAT?
Custom
encapsula8on?

4. NAT
IP in IP
ARP reply
Packet
Manipulator
Processor
Hardware-implemented ac8ons
Sodware programmable “ac8ons”
NAT
rou8ne
IP in IP
rou8ne
ARP
Reply
rou8ne
Instruc8on memory
Sodware code
Eg. ASM, C, P4 …..
1.1 – Our proposal
Idea 1: MIPS processor
Idea 2: VLIW processor
Too slow!!!
Custom
ac8on
rou8ne
Had to build it from
scratch ☺

5. 1.2 – PISA differences
We don’t want “atomic” ac8on on a packet going on a pipeline. Instead, we want to collect all the matches for the
packet and then arrange the code to perform the desired ac8ons op8mizing the hardware.
Programmable Parser
Match
Gatherer
Scheduler
Ac8on
Performer

6. • Sta8c 8-issue microprocessor (VLIW)
• 32bit dataplane
• 32x32bit general purpose registers and 32x1bit branch registers
• VHDL described
• Branch predic8on
• Lane forwarding
• Unaligned output memory handling
2 – What is Packet Manipulator
Processor?

7. 2.1 – Architectural overview 1/2

8. 2.1 – Architectural overview 2/2

9. • The ISA is derived from the one of the MIPS (altough has been enriched with specific
instruc8on to handle branches and fine-grained memory opera8ons).
• At the current development phase, the compiler toolchain is missing, altough we have a
parser that translates ASM to bytecode.
3 – Programming the PMP

10. To ease the task of implemen8ng the PMP, we provide a complete PMS (Packet Manipulator
System) wich includes:
• PMP Core
• AXI-S Input interface
• AXI-S Output Interface (providing unaligned memory)
• Instruc8on Memory
• Toolchain (early development stage)
4 – Packet Manipulator System

11. 4.1 – AXI-S input interface

12. 4.2 – AXI-S output interface

13. • One instruc8on (= 8 syllables) per clock cycle
• 3-stage pipeline for each lane
• 3 clock cycle delay
• 1 clock cycle branch penalty
• Heavy use of prefetch (data to be used in decode stage are required in fetch stage…)
• 256 bit parallel load/store in one clock cycle (ideal for AXIS NetFPGA-SUME data interface☺)
• Lane forwarding to avoid penalty arising from the pipes (if data required is the same as the
one currently in writeback, the data is forwarded in an earlier stage of the lane to avoid data
hazards)
5 – Performance highlights

14. 5.1 – What we have achieved so far
• Full data-plane programmability
• 50Gbps worst case packet processing (in some applica8ons, we reach 100+
Gbps)

15. Very small HW footprint on a NetFPGA SUME, equipped with a Virtex 7 FPGA
6 – Synthesis details 1/2

16. Fully synthesized at 250MHz!
Way over 156.25MHz needed for in-out
interface!
6 – Synthesis details 2/2

17. • Provide a complete toolchain for the PMP (including a new programming language)
• Por8ng of the ISA to RISC-V (almost done!)
• Adding more network-specific instruc8on (eg. Fast checksum recalcula8on)
• DPDK sodware integra8on
• Use Intel® Smart NICs to validate & improve the design
• Ul8mate goal -> ASIC produc8on
7.1 – Future work

18. • hwps://bitbucket.org/marco_spaz/pmp
• hwps://devmesh.intel.com/projects/packet-manipulator-processor
• hwps://devmesh.intel.com/projects/open-packet-processor
• hwps://riscv.org/
7.2 – Resources

19. Q&A

20. 7.2 – Acknowledgements
This project has been developed within the European project Superfluidity.
Thank for your awen8on!