 So Jonathan is here to talk about the DPDK burst replay tool, which is a tool for DPDK testing, is it? Yeah, to burst packets. Hello everybody, everybody. My name is Jonathan Ribas and I come from Marseille to present you today a tool called DPDK burst replay. We will talk about why I developed this tool, what can it do, how it works, and what are the future plane evolutions. But first, first slide on quick information on the tool. So it's Linux command line tool. It uses DPDK stack. It only needs two packages, DPDK and LibNuma. It's an open source available on the DPDK Git repository. It's early stage and it already has a big community of one developer, me. So why I developed this tool? In fact, in my company, we want a way to burst wheel packets, a real pickup file into DPDK ports to make some stress tests and also functional tests. And the two difficulties with the common TCP replay is that it uses the TCP, IP stack of the kernel. And it can be struggled by the IO of the hard disk drive. So we want a tool which is fast, so to bypass the Linux stack by using DPDK. And simple, we just have a tool of the TCP replay kind. So with this tool, we just have to specify the file you want to replay and the port you want to replay on. And we also want the application to be scriptable, to be easily integrated into some Jenkins scripts or whatever. So what it can do? First, it can load the pickup file. So the pickup is a standard format for all the network dumps. We put all the packets in cache to be able to send it directly without reading them into this drive. And we can burst the packets on multiple ports. And we can replay the same twice, several times in a row. And at the end, we put some statistics about how went the replays. And yeah, it abstracts DPDK stack so you don't have to understand and to configure manually all you will patch your DPDK setup. The goal is to have a simple tool. So how to use it? There are two little prerequisites. The first is to have huge pages available. So huge pages is a standard Linux kernel mechanism to have memory area shared between kernel and user space. With this example, we can create four pages of one gig. And after, you also have to bind the port you want to use into DPDK with the IGB UIO, which is the DPDK driver. Then just call DPDK burst replay tool by specifying the file and the port. In this example, I want to replay the pick up on four ports and we want to replay it 10,000 times. A quick word about its internal design. So let's say we have the tool linked with DPDK library and DPDK driver and pick up file which we want to replay on four ports. First, the tool preloads the pick up. It will count all the packets and remind the biggest one. Why? To be able to calculate the needed mempool for DPDK to store the packets. So we initialize the DPDK, we create the mempool and then we read again the file and now this time we put all the packets in different caches. One per port. The idea is to avoid lock contention, context switching, just to be sure that there is no disturbing action between just sending the packets. After, we initialize the ports, set up maximum TXQs for the NICs. We spawn the threads. So in this example, four can be just one, it can be 10, whatever. Once everything is set up and ready, we replay all the pick up in the different ports and at the end, we output some stats. On the terminal, it looks like this and you can retrieve the six steps explained before. The preload, the allocation of the mempool, the unique initialization and at the end, some stats. So per ports and at the end, a total stats of bit weight, packet per sec and send. Quick word about future revolutions. So the goal is to fit a little more with the TCP replay style. So adding options to play with the bit weight to limit it or to run a pick up respecting the timings. Maybe I have an option to select multiple pick up to send on each port or maybe to change them or maybe run just one pick up, but throwing the packets on all the ports. Many, many things can be achieved. Other ideas is to create a Python module to integrate this application directly into a Python application. Another thing can be to add a config file to let the advanced users to be able to configure the internal parameters of DPDK, initialization, kind of stuff. And most important part, it's you. So if you are interested, if you have some feedback, ideas or contribution, please you're welcome. And that's it. Thank you. Any questions? Yeah. In fact, it's not a generator. So we don't try a generator. We just want to take a pick up and replay it. Yeah, it's possible. OK. But I don't know if it catches all the packets on memory or... No. In fact, no. Yeah. Sorry. You mentioned something like contention on the cache. Yeah. Each kind of... I mean, my three ideas that those caches and those caches are really only for the players, for what it is. So why are you saying that it's contention? It doesn't mean you repeat the question for the camera class. Yeah. He was asking me why we create different caches to avoid some contention. What is the contention? In fact, when we send the packets to GPDK takes NQ burst, we give the packets to the GPDK stack. And we want to give the same packets to multiple threads, to multiple intents of... To multiple intents. I'm not sure that it will work very well. OK. She's made of buffers. Like buffers that you transmit. Yeah. It's mem buffs. OK. Yeah. OK. Sorry. I was just curious about the packet science variants. I was just playing around with that initially. And is there a top constraint in packet science? No. No constraints. It can be jumbo frames or... Yeah. Depends. But... Any more questions? Thank you, Jonathan. Thank you. Thank you. Thank you. Thank you.