Thank you.
Everyone can hear me?
Yeah, okay.
Hey, so hi everyone to them here to talk about a new project, which is called Grout.
So I was supposed to present this with a colleague, Christoph, but he couldn't make it.
So I will still talk about him.
So he's a software architect at Grout Hat working on NAV and Delco.
And I work with him on the Antoine integration for OpenStack and the NAV.
Delco use case.
So this is a quick overview of what I will talk about.
First question would be why did we start a new project?
Then what exactly do we want to do with it?
And how did we manage to get this running in the beginning?
I will then mention a few stuff about what we are planning in the near future.
And give a just an overview of the performance we have today.
So working on OpenStack for Delco operators.
So we had a lot of requests both from our customers and also internally at Red Hat.
How can we validate that OpenStack cluster deployment will hold and under load of traffic
when you have actual virtual machine processing will with complex network processing happening.
And until now all we had was DPDK Test PMD, which is, I don't know if you're all familiar with that,
but it's just literally a software wire that you can use.
So it's just meant to test drivers at the beginning.
But we eventually used that because it was the fastest way we could follow what packets from one place to another one.
Also we started discussing with the DPDK community two years ago.
And there was some, there was mentioned that how can we make DPDK more visible?
Because everybody thinks we're just writing drivers and how can we show the world what can be done with DPDK like a sort of flagship project or something like that?
So this is where we said, why don't we build a vendor, so vendor independent solution?
So the vendor independent part was important because when we certified that our platform will work.
We cannot say, yes, we tested it with vendor XYZ VNF, but we didn't test with ABC.
So it was hard to do. We needed something completely neutral.
We also wanted to be using DPDK as a first class citizen.
We didn't want to reinvent anything from scratch.
So there were also a few requirements that we wanted to be programmable over a API.
And the first minimum viable product was we wanted to have IP and IPv6 for learning in multiple VRFs.
So here, how did we get this done until today?
We took a leap of faith like in DPDK since approximately two years or three years.
There is a new library, which is called RT Graph.
And it's been inspired from the node library, from VPP.
And basically what it gives you is a framework to do packet processing with packet vectors that you can pass from node to node.
And it provided a strong foundation for something that we wanted to build with mostly DPDK libraries.
But then we had to ask a lot of questions about how many RFC we need to read.
How many times I need to read Linux and BSD stacks to understand why they're doing this at this place and not the other place.
We also took a very strong decision.
It was to make sure that every node in the graph was only taking care of its specific OSI layer.
So we didn't want the IP output to be writing Ethernet or that's just an example, but we didn't want to take any shortcuts.
So this is the example I took here.
So in the graph we have a hardware Ethernet port receive.
So we get the packets from all ports and then send them to, so we assume these are internet packets.
We send them to Ethernet input, which will pop the Ethernet header, possibly VLAN if there's such.
Then sends the packet to IP input if it is IP, if it's not IP, it will send it to either IP6 or ART or something else.
And we'll use the receive interface that was flagged as metadata to each packet to perform a route to go up on in the correct VRF.
And then if we need to follow out, it will be, to decrymentifiel, we calculate checksum.
And then from the next hop we got from route hookup, we can determine, oh, we can send that packet to that output interface.
Using that Ethernet destination address.
And then we can follow that. So from Ethernet how now we can push a new Ethernet header and write the correct MAC destination address.
And finally, actually send the packet on the wire.
So this was the simplified view. So now this is the current graph we have.
And I highlighted the path I just described.
So this is simplified in parenthesis, because there are a lot of nodes which are hidden, which are errors.
Like when we receive a bad checksum or TTL expires or whatever, the packets will be sent to a error node, which is hidden here, because otherwise you wouldn't see anything.
But what it gives us is that every node, when one packet passes to one node, we can get a statistic like this IP output.
Every time you see one packet going through, you will get statistics.
And thanks to that, over the API, we can see, like, for example, we received four ARP requests, which were not for us, so we just dropped them.
And you can see that in the stats. So that's what the graph gives us.
So for the I level design, so we have a graph which is a opaque object using the ART graph library.
And then we pass a copy of the graph to each of the data plane threads that we use.
And they do busy polling, it's basically pdk, but we have a little less aggressive way.
When we have mtpos, if we do busy polling, if you have zero packets, we will have an incremental sleep mechanism, which will do based on the size of the Q number of ports and speed of the connection.
And we will be able to determine the maximum sleep period will be able to achieve without dropping any packets.
And so then the control plane part is managed through a Lib event loop, which maintains a bunch of structures interface, next hops, routing tables and such.
So we have a modular framework where you can, for example, not compile IPv6 if you want.
It's just everything is bundled in an IPv6 module, so you can actually remove it.
And so each module needs to come with its own sets of nodes, entry points in the subgraph, which can be used then at runtime to plug it at the correct location in the graph.
And every node also carries its own metadata, like for example, if you receive a packet from Ethernet input, you will have the information of the receive interface.
And so for IP on the control plane side, we have route tables, next hops, plus some API handlers, and we have a built in CLI, which is just for manual interventions and stuff like that.
So currently we have, so we presented the first milestone of the project, it's September.
And we had IPv4 V6 holding VLAN and IP tunnels that we just implemented to reassure ourselves that the graph design was correct that we could just cycle back into the graph without having
crazy issues. And also we got the project accepted in the dpgeted.org organization.
And since then, so we actually fixed a lot of bugs.
We've added loopback interfaces, which are a way to terminate connections, TCP UDP, for routing demons.
So for example, if you want, we're currently working on that, it's not done, but you can run FRR, zebra, BGPD.
And if you so grout with create a loopback, which is a ton interface, and when it receives a packet, which is local, it will just send it back to the loopback.
So Linux will be able to process and terminate the connections.
It's also available in Fedora. Soon, I don't know exactly when 42 will be released.
We have a packet tracing framework, which is mainly for debugging when you're developing the new feature, and you don't understand where your packet is going.
We had the first external contributor that had the ICN PD6 simple stack, and also notifications.
So this is just a short example, but where you can see that we can trace packets, and every time a packet goes through a node, it can be called some information.
And so every packet you will see that it went through every step, and you understand why did it enter that or which node cause the drop.
So what are we working at?
As I said, we're working on FRR integration.
So this is still working progress with the ideas to be able to exchange routes through BGPD, and have zebra configure grout, but without going through the Linux kernel, so direct connection from zebra to grout.
And so Chris is actually working on that, and I'm also working on multipath routing.
So this requires some redesign of what we have currently, so we're currently working on that.
So we don't have a roadmap because it's we're two people working on the project semi full time.
We would, one of the first ideas we had is that every slope path operation, we currently need to kick the packet out of the graph, the data plane graph, and pass it to a control plane thread to be processed, like when you receive an ARP reply or something, you need to update your next hot tables.
But then so you lose the graph benefits of statistics and stuff like that. So what we would like to have is a dispatch mode, which is currently supported by RT graph, but you only can do that with pulling mode for all threads.
So for control plane, a slope path, we would like to have something less aggressive, and so in order to pass packets from one thread to another, and be able to do slope aspirations while still preserving the graph aspect.
And so other things we're planning is to do is just actually optimize the code, because currently it's just not fast.
We didn't make any optimizations yet, and a few tests that we need to, so once the FR integration is done, we need to actually test whether our control plane will hold.
And we're also expecting if anyone is interested in the project, please share your ideas.
Oh yeah, so that was the thing I talked about, how do we keep the slope path in the same graph?
So I will not spend that time. And to conclude, so as I said, we didn't spend any time to try and make it fast.
So obviously it's a comparison to test EMD, which is just software wire compared to our IPD for flooding on one CPU.
So I'm hoping we can make it better, and that's what I have.
So if you're interested in that project, please go ahead and test it and provide some feedback with a, so we're on GitHub, also have a Slack channel on the DPDK project organization.
And thank you.