Hi everyone, I guess I've got the superb slot lighting slot during the lunchtime.
So I'm a matchec, I'm based in the Englands and I've been spending glass 25 years teaching
and I've been spending glass 10 years working with FDIO and the VPP.
So I'm going to talk about therapists and bench working and specifically in the context of FDIO and the VPP.
So for those of you who are in the room, how many of you know about the VPP and FDIO?
Okay, over 50% of the room, how many are you using?
Over 50% of the room, how many of you speak it?
About 50% actually.
So I'm supposed to go over there but I'm quickly briefly talked about VPP and assess it and then go into the bench marking some results and some new stuff that we have.
That would be good.
So, there was a previous talk about with by Marvel team talking about VPP.
They showed some details about what VPP is.
But basically it's about vector processing.
It's doing it fast.
It's scaling it linearly and I have the steam called trumpet.
So if you Google turbo VPP, you will hit number of different demos, videos and paper technical papers showing the VPP scalability.
We are currently at over two terabits per 2 socket server and going higher with the next gen and IMDs, arms and zeans.
Future which later playing, but it all comes down to being aware of how the CPUs and GPUs today basically process was work.
And being able to process the buckets in the vector and keeping the caches both data and instruction hot.
It's a pluggable architecture.
So just do it and plug into it.
And there's number of plugins at the link.
Since it is a partner core project in FDIO, it's almost like a marriage.
And what we're doing is we're basically benchmark data playing based on DPP and also benchmark DPDG.
With that, we have a quality gate with the technologies, but we also have to optimize testing methodology.
So I'm pleased to say that we are just in the publication queue for the MLR search and RFC.
In the ATF, and we'll be augmenting Galaxy 2544 specifically focusing on software tracking and basically benchmarking pipelines.
We publish a lot of data and a lot of analytics.
And the good news is that since it goes, it's not always visible, it actually running multiple labs mainly hardware vendors.
Number of those vendors actually use it to develop their products and talk to them because they'd be speaking today.
Why do we need to replace the RFC to 504 by their search is just to slow for us to keep turning for the volumes of tests that we do?
So that's why we implement quite a evolved characteristics I'll go with MLR search to speed things up.
What we benchmark, we rely on donations.
So in the bunch of Zions, we have some other arms, so Marvel team isn't in Oct. 10, we test them.
You can see all the results in the open just and know how to find them. I'll show you.
We also have a new NDDA grace server for a year now, so you can see how they perform with DPP.
So it's all quite a lot of goodies, latest nicks, and we are currently willing folks to get us latest DPPs like NDDA blue fields.
And it does lots of lots of things.
So this shows a bit of the challenge.
There's probably a guess we need help with a UI.
So any of you UI designers, please come and help us.
But the blue boxes on the left is basically test selection and the legend configuration.
The top right is our trending screen that shows daily trending and for the PDR and NDDA rights PDR is basically some tolerance to the packet drop.
The bottom one is our release tests that test various variations.
Much higher number of combinations of the packet sizes, cores, numbers and so on.
There's quite a lot of analytics data.
The good news is that this is for you to browse, but all of this data is downloadable.
And you can see here out of one core for large packets.
We are 200 gig for specifically self high rapids here.
At the time it's with about 64 gig.
This is a similar view, but for a great server.
So again, anybody with UI experience, please, please help us.
And so it's a lightning talk, so I'm rushing a bit.
I'm around later for you to ask any questions.
Now what I wanted to talk now and slow down is to talk about the new think that the VB thoughts and many of them are actually in the room and available for questions and follow-ups.
So we are in this introducing a new type of flow or packet processing in the VB and that's the stateful data plane.
So suddenly we're dealing not with packet by packet lookup, but we are actually organizing packets into or detected.
So the classifying packets into sessions and dealing with those session sessions and sessions are stateful.
So what are the capabilities?
It's an alternative to take on sessions.
And the idea is to have the basic session parts within the VB pipeline.
But make it pluggable so that any more sophisticated stateful engines like firewalls, like Snord, so it got us IPS systems, can actually plug into it and offload the verdicts for fast-potting.
And it's basically removing a lot of redundancy to deal with the session lifecycle.
So we have sessions coming from the left on the picture.
The classified with SOTP lookup and then we're going through some basic notes that are integrated with L for lifecycle.
And then basically they are managed.
The packets are managed as part of this session.
The sessions are multi-dependent.
There's a bit of the hierarchical service training for what's in reverse.
And most importantly, the service chain can be updated over the lifecycle of the session by doing what's happening with the packets and the verdicts.
So we call it the dynamic service training.
There are a number of existing SOTP services already in the repo.
There is a, you can check the source, there's docs, Muhammad here, and few folks wrote a block.
So I feel free to get familiar with with that.
So SOTP is kind of a big deal for VB.
I would believe it's a brand new thing.
We are testing it in SOTLabs with T-Rex.
So we're limited to the multiple 10 geeks.
And we sort of stretch in T-Rex a bit for stifle.
We have our partners in Intel Labs doing this with Dixia.
At a number of hundred geeks.
We have the first benchmarks in on ML rapids.
So we observe three million connections per second on UDP, TCP, on the single Z1 core, which is encouraging.
And there are the links to the latest locks.
You can check it yourself.
And please watch the space.
And now going forward.
We're going to continue developing our stateless packet tests.
We are ready.
We're putting, we're starting to put all the energy into stifle part.
So the baseline of SOTP data plane.
Then the services over SOTP.
And then we want to go after a bit more complex stuff.
Like integration with Snort.
I'm talking to the Sorycata colleagues.
And friends and see what they think about fast-puffing the Sorycata relics.
And of course, we're adding the new hardware,
GPUs and such as I have mentioned.
Now what we're looking for is.
We need to count with traffic generator folks.
And if you hear in the room or you're talking to them,
please implement latest standards from ITF.
I want to allow a search draft to make it seem like a compatible.
And help us with stifle tests.
And of course, for VPP, for VPP community up here,
please keep your reviewing patches,
contributing the services.
And now adding the stifle stuff.
And we're very excited about that.
And help us ship it.
And I'm 10 seconds.
Cool.
Okay, thank you much, Jack.
Do we have some questions?
Yes.
Yeah, thank you, Mr. Paul.
For the amazing part of the seat,
because I was checking benchmarking results after a new release.
It's a kind of big deal.
And my question is, is there a way to run those benchmarks with
directs on hardware?
On your own hardware?
Yeah, of course.
And I mean, last question is how?
Yeah.
Well, let's chat.
There are actually folks who presented before.
And that was the previous talk.
Who would be running it for a while.
And then they've been actually using it as part of their network.
But we have a number of people who replicated SSIT.
So we're very happy to help you.
And actually, there are people in the room here who also run SSIT in the labs.
And on their own machines.
So happy to assist.
Thank you.
Okay.
Great.
Well, thank you very much, John.