Please welcome our next speaker, Govah.
Hi, so my name is Govah, which is a really not name, so you can just call me Govah.
And I'm going to talk about this great thing for the talk.
So before that, I was sponsored by the MLNet Foundation with a grant that is financed through
the European Commission called NGISU, a generation internet.
So if you have ideas and just want money, just go for it, it's actually a really cool
thing.
So now, what's this before?
So I guess the academic definition would be the programming protocol independent packet
processor.
It's a domain-specific land-range for network devices.
But it's fine, our data plane devices, switches, microtors, filters, as well, process packets.
OK, great.
But what does this actually mean?
OK, so it's an ungrade, basically, for hardware-optimized network processing.
Like, think SIMD for network, so you can just have, like, those FPGAs, DPUs, whatever,
and you can make them process network packets for you at an accelerated rate compared to
software.
So it roughly looks like C, in a way.
As you can see, like, it has the same kind of syntax, like, arguments, whatnot.
The thing is, there's a few things, there's a few oddities.
Like, you can see it doesn't, it has the state thing, it doesn't have a return.
You have transition select, what is this?
It looks a bit weird.
So let's explain this a bit.
Funds in P4 are replaced, mostly, by things called parser, control and package.
So, what is parser?
A parser is a function that is going to pass an incoming packet according to, well, the
same thing as in C, which means structs, type the effect, etc., like, say, I'm going to
define a struct, I'm going to say, if this element of a struct is this, then I'm going
to call this function.
Basically, that's what the parser function does.
You have then the control functions.
You modify your past packet, say, for example, you have this really long packet, which says,
I have up x, y, z, and then you want to remove the up x, because you're on up x, you're going
to do this in a control function.
And then, you have package, which defines basically the binding logic between the hardware,
like, oh, am I going, say, I implement a firewall, oh, am I going to add new rules, am I going
to, like, load new definitions, and whatnot.
So, that's basically it.
There are very interesting keywords, there are other things, like, that I'm not going
to explain over this, because P4 is kind of, like, that this would basically be out of
scope for the talk, and P4 is already complex enough as is.
So, how do you want to use P4 in NICs?
There's a few ideas.
My take on it is, let's make a transpiler.
Why?
A transpiler allows you to reuse for concepts within NICs, say, because P4 is a bit verbose,
because, say, you want to pass this IP, TCP packet, something.
You need each time to redefine the IP header thing is, so you want to redefine this track,
you want then to have it passed in a way, and then sometimes you want this thing, sometimes
you have this other IP strike, because you don't want to pass, like, some optional data
in the header that would slow down the process, et cetera.
So it's a bit verbose, let's just use NICs to basically implement parts of it and have
it in a nice packet.
So what is a transpiler?
In our case, it's a NICs to P4 translator, which means you can define things in NICs,
strats, enums, whatnot, and it generates P4 code.
Then you have the P4 compiler, which actually processes the code that's generated, followed
by the target compiler, which, in this case, allows you to deploy your thing to, say, an
FPGA, a DPU, et cetera.
Basically the thing that allows you to run your thing, your program.
So what does it look like in action?
Basically this is a NICs file, which allows you to define some P4 concepts.
In this case, I define a header flag, which contains a few counts, like, max-ops, standards,
ops, et cetera.
And then a few headers.
In this case, I'm just defining standard T, which has two flags, source and destination,
both of type bit 8.
That's basically just a way to redefine the annoying thing of P4, then you can also have
the include.
So this is processed, then, by this function called run-thread-spiler, mcat-transpiler,
whatever I call it now.
And you just run this, and it generates code for you, and that's great.
So we can simplify this, obviously, because that will be annoying to each type, like,
this header, this header, et cetera.
And the whole point of making this whole thing is to make it less verbose and to reuse code
so you can just have your own info, mostly in NICs and, like, a few bits and packages
in P4, so you can basically put everything in the same place.
In this case, you can just innovate things that I define in helpers, and you can do the
same thing, and you get your P4 source.
So that's a lot simpler.
And we don't have to define eternity each time, we don't have to define mac addresses
each time, which is a thing in P4, because if you use, like, standard P4, it's going
to make you have to redefine all of this at each program you make.
Which is thanks to helpers that I wrote down in my packages.
So what does the end result look like?
Because I'm saying, oh, this is the NIC code, this is what it looks like, et cetera, yeah,
it's great.
Okay.
So this is basically the transpire.
It's kind of dirty NICs in a way, like, you can see it's a lot of messy inventions, but
basically the idea is that I define a module, NICSOS module, which verifies the types of
what I give it, in this case the other, I give it a default type, then you can have,
like, the union, the content, the one-off, et cetera, which are then passed by the transpire,
which are these huge, like, nested functions, which basically just map strokes like NICSOS
at Simeon into just, like, P4 materials, and then just write it.
It just starts to start to transpire.
It's nothing fancy, but it's fine.
And so what does the end result look like after the transpire?
It looks like P4 code, but pretty clean.
You have, like, the include, the define, the ops, max ops, standard metadata, then you
have your structure, et cetera, and then you can include, like, your own code.
Then, and then, this whole P4 code is then processed by the target compiler, which then
processes it to its own platform, say, it can actually generate, like, say, EBPF code,
so it runs on Linux.
EBPF is basically, like, this canal thingy that you can run to have more privileges.
I explain it later if I have the time.
And this is BMV2, and BMV2 is just a simple model architecture.
You'll also talk about it later.
So basically, it starts to suspend compiler that has multiple status and allows you to
specify P4 functions, and we use concepts.
It's nothing fancy, but it's useful.
So now that I talked about BMV2, I think I have time to do it.
So what is it?
Glad you asked.
So the simple switch architecture is the de facto architecture that is used to basically
test P4C, which is the main compiler.
So it's basically, like, this kind of standard test setup that you can use to just see if
your code works, but it's not fast.
You can't really target it to anywhere.
It's basically, like, this low user-length thing that you can use to just test your program
that is not fast, but does mostly what you want.
It's basically just, like, this interface for targeting the switch.
It's an abstract interface, and it's also used to just verify how P4C works.
So now to continue a bit more on P4C.
To set up, like, to use P4, you need a target, and the main targets that are currently implemented
in P4C are user-length, which is, in this case, EBPF.
Some people are going to cringe at this because EBPF is technically kernel, but what I mean
by user-length is I mean it runs on a computer.
The DPDK, which as, and this is why I'm saying it's user-length, its own user-length code
that can run, but the DPDK also is like this, how do you call that?
An API, I guess.
It's an API that can target a bunch of devices.
So it's not only user-length, but it has a user-length point.
Then hardware, because you can use DPDK to also target hardware, say FPGAs, which are
like, for people that don't know, things that you can use to, say, program CPUs or whatnot.
You can basically just reconfigure the electrical level, electrical gates, et cetera, and then
Q-Storm Asics, which are like Q-Storm processors and whatnot, basically.
And then just emulated.
I'm going to call it emulated because of how slow it is.
It just basically, let's test the thing, BMW 2, I told you about it already.
So obviously, all of us need some kind of interface to work on.
And usually, you use the abstract switch interface with a few per-device changes and some, say,
some control functions usually have a definition specific for EBBA than we like.
So there are a few changes, but, overall, you can target basically all of these with
mostly the same code, which is great.
But this also needs changes to the transpiler.
So you need to have more options, so you can target every different one.
So you can, say, have the role, mess, auto-generated by a transpire.
So, say, you can just, in NICS, define, hey, I want target X, and it's going to do it automatically
for you without having to change the P4 code, which is mess.
So now, introducing FPGAs on NICS.
And I'm actually not kidding.
The thing is, I forgot to actually take the picture before going to FOSM, so imagine it
is really hard.
Basically, an FPGA connected to a computer who, say, USB or whatnot, and then connected
to the network for Ethernet.
The idea is that we are not running NICS on FPGAs.
We are using NICS to define what the FPGA wants, in this case, the network stack.
So we need to define, like, say, the devices we have in NICS directly.
So say I'm going to have, like, hardware.alastor.type is my FPGA, and then I'm going to explain
how I can define it.
Then you need some kind of auto-reload-deploy mechanism, usually, like, most FPGA providers
just provide you a way for USB.
You can also have just an auto-reload of tools through the control plane in P4 directly,
if you want to go this way, which means basically no downtime network stack, which is nice.
And yeah, you can have a data plane mechanism for feeding data to the host, right.
All of this is a work in progress for now.
So the transpiler is done.
Basically, most of the source-to-source transpiler, including the targets are done, the targets
are packaged, you can use BNV2 nowadays, you can use DPDK and whatnot, but the hardware
definitions are currently work in progress.
I haven't had the time to work on them yet, but it's close enough, close enough.
And software works.
So yeah, that's basically it.
Any questions?
Yeah?
How can you get a switch that runs P4?
So the question is, oh, can I get a switch that runs P4?
P4.
So you don't technically need a switch that runs P4.
You can just use any, say, FPGA or DPU that you can reprogram, and that is targeted by
DPDK.
You also have, like, some routers that have A6 that are reprogrammable, as long as you
can target it with DPDK, which is basically the API you can target.
You can just use it, and when P4 on it, basically.
Maybe I missed it, but what is it that makes NICs particularly happy for this compared
to other things that might be different?
Okay, so the question is, what makes NICs particularly nice in this case for P4?
So what makes NICs, in this case, useful is that it's at the border of basically this
bowing code to generate per target, and you also need to actually target an infrastructure.
And basically, NICs is this great thing where you can just define an interface, an infrastructure,
I mean, and you can then write automated code.
So NICs, in this case, has two key roles.
It's allowing you to write code with less, not having to rewrite every time thing, making
it just basically this handy source tool.
And the thing is to define your network stack in the same place as you would define your
standard infrastructure, which means, say, I want to define this server, okay, cool,
but now my server has like 100 million requests, I know.
And I need to actually, like, huffload these things for some degree, so I'm just going
to say, hey, hardware-definition.fga is my PGA, and now I have must-be magically, well,
you need to pay for the PGA and program thing, but yeah, magically.
Any other questions?
Yeah?
This is useful for things that are not network-based, right, so you can do things that have nothing
to do with networking for your target thing, your PGA, is there a scope for this, or is
it basically just for networking stuff?
So the question is, is this going to be useful for other things than networking?
And the answer is yes or no.
So the FPGA deployment mechanism, yes, is going to be useful in this case, because you
can just reuse this thing and use it outside of the scope of P4.
The reason now is that everything else is basically P4-specific, but yes, the last part
is probably going to be reusable for other things than P4, first of all.
And second of all, there's going to be a few different FPGA targets, probably, like there's
always going to be the proprietary ones with DPDK that have their own, say, deployment
binaries that are clusters that are pain, but you can always see, like, try to implement,
say, your these thing is and whatnot, so to have an open source FPGA setup, sorry.
So yeah, you can use it outside of P4, basically.
Yes?
The P4 language is heavily exposed to the non-network thing, like, a lot of people using it for non-network.
Like, Western digital, like, tax-coherent bus and the bloody thing.
If you have any kind of stream that you can process, if you can express it in a way that
it can be processed, if you'll find you can process it in a way that really remains specific
for DPUs and network processors, like you have CUDA, OpenSQL, and so forth for DPUs.
That's a really good point.
Just for the live people, basically what was said is that you can use P4 to process any
kind of stream and modify it, and it's used by other companies to process this in an accelerated
version, which is very true and very handy.
It's not the most common use of P4, but P4 is always not very common, so.
We have two minutes left.
Did you want to do a demo?
Okay, let's do that.
So, thank you.
That was me.
Go and find.
Here's my website.
Here's my email.
And, yeah, we have one last thing to show.
So, hmm?
I want to take a photo of the P4, just like that.
Ah, sure.
It should be recorded, so.
Yeah.
Okay.
Did I expect people to actually care about me, honestly?
So.
The demo is a bit of a strange thing, because the next talk is about secure boot.
Yes.
So, it's a demo about secure boot.
There's, yeah, there's one thing I forgot to mention.
I'm working P4 on this, but I'm also working on the secure boot thing, at least.
So, what I wanted to show you is that.
Let me just do that, do that, so I can just do this.
I started this small PR the other day, which is like grab support for secure boot.
So, yeah, I think now we can actually boot secure boot on XOS using Grubb.
And to add on to that, let me just show it there, because it's, I have too many windows.
There we go.
Let me just, yeah, there we go.
Welcome to Grubb.
And I'm going to, I'm just going to zoom for the live.
Okay.
Yeah.
There we go.
And basically just, this whole thing is working on the secure boot.
And as you can see, it's panicking, but it's close enough.
It's close enough.
So now.
I'm going to leave the next speaker explaining what Lensabuti is.