Okay, I'm Martin Taichmann. I'm coming from the European
expert. Yeah. We are running the world's largest x-ray laser. Why does it think
go so fast? Yeah, I just use the other keys. So we are running the world's largest x-ray
laser. So most of us is in tunnels. So it's three and a half kilometers long that's quite
some big size. We are publicly refunded research facility in Hamburg, Germany. And as you all
can kind of imagine in a large x-ray facility like that, we certainly need an electron
bio-fingent polarization focus, EVPS. I've put up a picture of that. So it's actually
down here. You can actually see it, but well, I just put a picture anyway. What you're seeing
here is just some bunch of electronics. And that bunch of electronics controlling those
motors, which you see up here, which is a motion. And this electronics is using the EVP either
cut protocol, which is a very versatile bus system that they use throughout every area throughout
the facility. We have a huge number of installations from that. It's effectively enough
hardware-wise to just control everything we need. Unfortunately, the software is just awful
and it's close source. So we try to replace that with the nice open source software.
Okay. How does this protocol work? Well, in that protocol, you just have a just a normal computer
that sends out either net packets, with two of those terminals, which you just saw on the picture
before. And that easy change shows the packet to the first one, which is set to the second one,
and so on. And the last one just sends it back to the computer. And so reading from the
terminals, by the way, you do by those packets being modified on the fly by those terminals,
and you're just other stuff coming back than you sent. And now you might immediately see the
application for EVP F, because what I'm not doing is, well, EVP F is running in the
in the lowest corner, and it's running pretty fast, and it has direct access to the network via
XTP programs, with the program type XTP. And so what we are just doing, we just are just within
this loop. So the packet we send out a packet, it goes through all the terminals, comes back, goes through
our EVP F, and send out again, and so on just in a circle, there's a nice loop. And on a high
level, all the flows, so this is the fast stuff, and all the slow stuff we can just do in the
user space, from Python. So what I want to talk about this in this talk, just after this fast introduction.
So I want to show how you can use EVP F cap to make XTP programs with some simple examples.
XTP, as a reminder, is just the program type and EVP F for network transport. Then I show
it actually works. Then it goes through some EVP features that are already supported. And as promised,
it shows some cool motion stuff from as an application for EVP F. But we are all constraints
from developing this software, well, we need to be highly dynamic. And so we only get the hardware
set up at runtime. We read out the terminals, we read out what's going on, how they are set up
at runtime. So you have no clue about how to send out data before we have actually seen it.
Even the actual logic inside might be not clear at compile time, so we just, it's just discovered
always at runtime. We also have, as I said, many installations of those, and we would like to be
able to just run several installations on one computer. And so we wanted several IPBF programs programs
to run in parallel. And those programs must be replaceable at runtime, because we want to be able
to replace hardware at runtime and then just change the accordingly. So simplicity is another
important thing. Most of the programs, most of our programming is done by scientists,
and not by programmers, and those scientists. There are no Python. Python is huge in our community,
but they might not be the best programmers out there, and that's not really their jobs.
I should be simply enough that they can deal with it. Also flexibility, I did not want to write
a thing which just solves my problem. I just wanted it to be usable for many other purposes.
My ideas that EVP F can be used as a speed boost in Python programs, so they can just offload
the inner loop of your Python program into the Linux channel. Okay, let's just jump directly
in and give a full example. Here we have one. This is an entire code. Well, no. It doesn't
like me here. This is an entire program. This is not just a code snippet. This is really the
entirety of the program. You can just like that Python and it will do it. It's a very
simple example of just accounts, the number of packages that are coming in. It looks like no,
a Python code. You might not even notice anything special, but this is actually EVP F from.
How do you see? So let me just go through it. The EVP F part is this part here.
You only see from the fact that it inherits from XDP, so then XDP program.
We like always the Linux kind of after for which license we use, we are at first them. So
obviously that's GPL. We can declare a clear and airy map for a communication with user space
and then also declare a variable that lives in that airy map. This here is now my EVP F program.
Then comes the user space part. And what we do here, we just
insensiate this class here. Say run. Then it gets attached to this network port. And while it
while the EVP F is running in the kernel, we can just talk to it. And now the interesting parts of it.
So this part here generates EVP F. And I will repeat that probably 10 times during this talk.
This is not the code that is actually executed in the kernel, but this code is only executed
once at the very beginning. And generates code that then is injected into the external,
and runs then in the external, the result of that. That's the first thing.
The second thing is you might notice that this variable here, and this variable there,
is the same. And they look the same. It's the EVP F care that in the background
to make them the same. And so you can access the same variables from EVP F and from user space
without even feeling it. Yes. XDP doesn't really make sense if you want to see the packet.
Do you want to see the data that is coming in? So for that as a first thing, we need to declare
a minimum packet size so that the verify analysis, otherwise we just drop the packets or do
something else. Does matter here. Then we can declare a packet variable, so a variable that
lives in the space of the packet. And if you know either an protocol by heart, you know that
a position 12, you have the either type. And the either type is actually unsigned to 16 bit
in a network byte order. And we are following the Python's struct package convention,
very just H, which is unsigned to 16 bit, and the summation mark means a network byte order,
just Python programmers. They all know that don't they. And so you keep our user spaces
stuff the same. We have our program. And now we can just filter for either type equals is 0,
that is by the way IPv4. And as I said, already this code is executed only once,
and you better execute all the code. So this is why we cannot have if statements. Because if
you have an if statement, you do not execute all the execute all the code. So what you do we just
abuse the Python with statement, which in the beginning looks a bit awkward. You get used to it.
So now it's the next thing you might want to have more than more than one test for example
we could check how many want to know how many FPV6 pay packets are passing through.
How do you do that?
That is how you do it.
We just make another user space variable.
And test is nice with condition as else.
And with else, comma is nothing else than what you normally read as illiff.
And yes, it looks a bit unused.
It's strange, but it's not too far of a normal programming.
So how does it actually work?
Well, as you might have noticed, those declarations appear.
They are Python descriptors.
And in Python descriptors, you can have,
don't get and don't set methods.
And those don't get and set methods can do whatever you like.
Usually, they set the value of your variables somehow.
But you can also just make them generate ebps code.
And so it happens.
So it just sees there's just self that speed.
Speed knows it's okay.
It's a packet variable in the background.
ebps can't have set up that the packet.
Start with the packet point.
I will be in register eight here.
We know that in offset of 12, we just put the 12th in.
At the same time, we have our area map, which if you path in the background,
put it's a base pointer to register nine.
Set up some, laid out some, the user space variables so that they are at position 16.
You put that into registers.
And then the rest statement will just generate a jump that jumps over that code.
If the condition is not met.
Okay.
So the advantage of all of that is that I don't have any dependencies.
So technically, it's written in Python.
So yes, Python is a dependency.
And yes, Linux is a dependency.
No, I will not plot that to Windows just in case you're wondering.
And yes, lib c is actually a dependency.
So I think you will have a hard time running that in Alpine Linux.
But okay.
So it's just to pip install the ebps can't.
And it's there.
It doesn't even do not in dependencies because it has no dependencies.
And I think that's very useful, especially for beginners.
You can just start working.
Some features that we already have.
Why does that jump go?
Is this a no?
What I call permanent local programs.
So what I showed you until now.
Always the program was running while the Python program was running.
So this is this example here.
If you program, we insensiate it.
You say program that run.
It's within a viz block.
And within the viz block, your ebps code is running.
And you can do whatever a business logic you want.
But you also want my might want to have that the program is running all the time.
Even after your Python program has finished.
Well, you can also do that.
You just insens instantiate your Python program.
Then you just attach this to the ebps port.
And what you can then do is you can pin all the maps to the bps file system.
Then you can just do whatever business logic you want to do.
Your program finishes.
The bbps continuous to run.
It still filters all the packets and whatnot.
And in a later time, you can just insert in a new,
newly started Python program.
It can just insensiate that thing again with this nice parameter load maps.
It will just load all the bps maps back.
So this means you can still access all the user space variables from again.
And you do whatever business logic that you want to do.
And in the end, you just detach it and you're done.
OK.
So I promise you to do a show you how to do motion control with the app,
which is something really weird.
So how would you do that first?
The first thing is, what do you prepare to cut does for you?
And you don't need to do that yourself.
It reads all this app's self descriptions of the terminals,
which are on your bus.
And then you create an evened package that contains from that self description.
It knows how the terminals want to be talked to.
Then you generate an evened packet that contains all the interesting information
that sure is in header.
And then in the package, somewhere there's whatever in the encoder positions,
like you're in readout, some motor speed that you want to move your motor build,
some limits which are said, whatever you might be in your hardware that there is.
Can be a lot actually.
Then you have to program all the terminals so that they know how this packet is supposed to look like.
And only then we can generate the EBPF program the same way as I have just shown in
the last example.
Then we just send one of those prepared packages on the network.
It goes through all the terminals, comes back.
Then we process by XDP, get sent out again and all over again in a big circle.
And this is how you do your motion control.
The while there's a slow code at the same time to communicate with the outside world,
they'll just run as is in user space.
One other feature that I need for that is to tell you that we want to be able to address different kinds of hardware at the same time.
Also independently from each other.
The way I do that is that I start some permanent program that has a Pint Prog area map.
And then into the header, I just secretly sneak in some breadcrum, some number from which I know which part of the hardware this packet is supposed to talk to.
And then what I just do is I call tail call into that program area.
So I just know which number it is.
Okay, and then I know which program area to tail call.
And then any program that wants to actually communicate with one part of the hardware can just start.
Well, instead it's even if program into that program area will be called for all the data that it needs.
And once it's done, it just removes itself from the program area and everything continuous at continuous as before.
So Python gives you the large advantage.
This is that you can just go to a much higher level of much higher level of programming of understanding.
And so what you can do in ebf is ebf cat in my library is that you can abstract out all those details about packets or whatever.
And have this kind of programs where it's really focused on this control part of ebf cat.
For example, you have in in a motor device you want to a motor usually has something like a velocity it usually has a position from an encoder.
That is something that you communicate with the hardware.
So and ebf cat sees not just one of those but has probably many of those for all the coaches that you have in your system.
And it will just lay out the packet as it will and then just assigns the where it will be.
Also then you're talking to talking to the user which I hear then call a device law.
It will just then also just take all the motors the communication with the user lay out the map to communicate with user space.
And so that in the ebf program.
Doesn't see anything of that anymore.
And it just for you it's just velocity and entire position if you ever did motion control you can see that this is just kind of the easiest way to do a position control of a motor.
And the nice thing is that you don't you don't really see that this is actual you know ebf code that does a lot of things just going on in the background.
You can do this very high level version of programming and I hope that then even my colleagues will be able to do that.
Okay, I'm already at my summary.
So with ebf cat you can generate ebf code from Python.
It can be used generically to use ebf programs especially exp programs and as a special case it can be used for computer controls of either compatible hardware.
Everything can't be found and get up the documentation here and for those who are super interested to hear are all my motion control things are in this additional really repositories.
I'm thanking my colleagues and to you for your attention.
But just before you get to come up with your questions I want to then show you the result on how it looks like.
Okay, now I would need to know how to get to there it is.
How is such a motion that looks like and.
There is this is a ebbbf moving in sync as you see you two different motors three different motors actually to keep them all in sync.
Questions.
Thanks so very interesting talk so if I just and correctly you are generating.
Bbf instructions directly out of the Python code right you're not using any like L of a more anything.
Exactly.
I can imagine must be a hard task so are there any limitations like I don't know you run out of registers.
Can you store stuff on the stack or you know that must be like it's a hard task.
Absolutely this is a hard task but absolutely I'm not done yet.
I'm kind of always writing as I go and I thought actually that this would be a much bigger problem than it is.
Weirdly so.
I have so.
The entirety of that code is less than 10,000 lines.
So it's not a huge code and two thirds of that code by the way is that either could protocol which is not simple.
So it is until now pretty simple and yes I know I until now it's right.
I have not yet written a proper register allocator and do that very greatly and yes if you need too much register it will just crash until now.
But interestingly I have have actually I've had to have written a rather complicated code.
Already and until now I have not yet been into the limitation and will run into that I will figure out how to fix it.
That's cool.
I think we'll talk.
I'm not that familiar with neither is a cart or BTF but I guess you do so the question is could it be used to implement hard real time communication with is a cart.
Maybe.
If so there is other people doing talks about using EPPF for controlling the scheduler for example.
And there's even I've read somewhere somebody apparently is even working about working using EPPF for the scheduler of the packets going out of the hardware.
And if I have that then then I can do hard real time.
So please just work scheduler for packets outgoing packets please.
Would be really nice for me then I can do a real hard time.
Until now what I'm doing is just I'm just so fast with EPPF.
Then just fast then everything that the normal real time people do is just to blast them just away.
Okay thank you.
Any other questions?
So you mentioned not having any dependencies does it also mean that you do all of the BFF's schools manually instead of using that that's actually pretty challenging as well.
I know I don't experience so.
As I said it's in total less than 10,000 land of code it's the very fires alone is bigger.
And Python is just very very short.
Really impressive.
Cool thing.
Can you talk a bit more?
You've been choosing XTP specifically because of the I guess low latency or are there also lots of packets that are going to.
It's it's really the latency I actually even have I even have the problem that many hardware is optimized for high bandwidth which is usually not good for low latency.
This is why I'm running XTP on a Raspberry Pi because Raspberry Pi's do not have the necessary buffers to do for high bandwidth.
But this way have a pretty low latency.
Did you also use this in combination with busy polling or something?
The busy polling of what.
So kind of what I'm kind of doing is constantly polling yes.
So that the the the packets constantly flowing so usually usually at least 10 kilohertz the packets going in out in out constantly.
So it sucks this cycle goes really the 10 kilohertz if not 20 kilohertz.
That is effectively that's busy polling.
I think that's the thing that's what it is.
I don't think you've been running that in production and what what feedback you get from the other uses of the project like did they stumble on some.
Maybe if stuff somehow like how is the experience.
So I've been working on that since five years.
It started very slowly but it's now taking speed.
My colleagues at the when I switched over from the closed source stuff that used to before to this.
They didn't even notice which I think is a it I think it's a good thing.
So it was just working so I asked them did you notice any problems anything.
They thought I'll find.
I have presented it to scientific conferences to scientists and they were just they were really happy to.
They're the only question that the the meanest question that I got.
I didn't you're just right all of that in C++ and.
So they also loved it so until now I got a lot of positive feedback.
And it's just because it's just working.
Have you heard from the lawyers from the company sitting the proprietary stuff yet.
Until now no.
So the company insists that they have a pattern and all of that but they are very fruit they say that if they only.
They're only interested in the hardware side.
So that's it's an open protocol so everybody can.
Even make hardware like that but I'm softer and they always they say that for softer they have no issues because.
They want to sell the hardware and that you send the sell the software makes software for it.
They're officially state that.
Go for it.
Very good.
Thank you.
Any other question.
Yeah.
Last question.
Yeah.
Thank you.
How is it now if you want to give that to other scientists.
I assume you you probably will need some UI of some form like.
So you have your device view and your health checks and all that stuff that.
Twink and then the others do.
So this certainly this.
The second link on that page is the communication to the communication.
Layer that bridges it to our in-house control system called carbo.
Which then so it gives you all kinds of UIs and whatever you want to have.
It's by the way all open source.
Look at it.
It's actually pretty nice.
Maybe somebody wants to work on that.
Just.
All right.
Thank you.