Hi everyone, so it's good to be back at Phorzdom, so last year we had a topic on FDIO VPP.
Last time we talked about how we can integrate open SL into VPP and leverage hardware accelerators to enhance the performance of TLS.
So this time the theme is similar but the topic is obviously different.
So what we are trying to present here is how we can leverage traffic management hardware and enhance the VPP software to deliver better traffic management capabilities.
So the brief agenda for today's talk, first we will have a brief intro on what we mentioned as traffic management or alternate.
We can call it as quality of service and we will also give brief intro on VPP, FDIO VPP.
So because today this is the first talk on VPP I will give some details so that the subsequent presenters can save the time.
And we will also talk about some of the advanced features which are available in smart nicks or smart DPUs, where they have a special hardware which allows you to have traffic management to be done in hardware and save some CPU cycles.
So the main core of this topic is to introduce a new framework as part of the VPP's data plane and we will leverage hardware capabilities of this smart nicks so that the traffic management will save you some CPU compute so that your applications software can use the extra cycles from the CPU.
And then we will provide a brief intro on the framework which we have added to the VPP so that how a user can classify a flow and then use the underlying management traffic management framework in VPP.
So after that we will just provide some brief performance gains we have observed so these are the early results we have after to be introduced this framework into the VPP.
So we will have some graphs which show how much of CPU cycles we were able to save when we try with single flow or multiple flows and with different number of course.
And we also have towards the end we show the patches which are currently almost towards the end of the merge stage and we would like people to provide more comments on the patches and then hopefully build over it to add more features into it.
So for those who are new to QOS traffic management so it is just a set of mechanism which are used to provide guarantee to the users or prioritize the traffic of a particular user.
So let us say there are a lot of traffic times right so for example you are making a call to your friend voice call right.
So you don't want your voice call to be jitter right so you should it to be low latency so the requirement for a voice call is to have a low latency.
So when it comes to let us say a video traffic so for example videos you are watching a Netflix movie right.
So you don't want your Netflix movie to stall right so that is the quality of service you expect from Netflix or any content delivery network right.
So that is and there is another hand of topic for example a general web traffic as quickly be traffic let's say.
In such cases latency is okay but you don't want your packet to be lost right so it should be reliably delivered.
So if you see here for each kind of traffic there are different kind of requirements.
So what that means is that the quality of service requirements for each of these traffic are different right.
So whenever whenever there is a user for a certain type of traffic he has to reach out to the service provider to have a certain level of.
The quality as SLS so agreed with the service provider okay.
SLS are nothing but service level agreements which says that for my kind of traffic this is what I expect it to be handled in the network's networks software systems software right.
So so how do you measure the quality of service right what are the metrics you use like for example whenever there is a traffic right.
So you want the traffic to be having low latency or so you want do you want it to be a low latency traffic or your packets should not be lost.
So these are the kind of metrics you normally use right.
So that's all on the QOS so we'll move on to the VPP right.
So for those who don't know VPP right so VPP is a user space hyperformal stack so it has all your L2 to L4 features and it all runs in the user space.
So if you are aware of a DPD here or any smart nix right so you can always process the packet directly from your nix in the user space and then handle all your software logic in the application right.
So by VPP is popular so it is very modular as like all your software can be built into different nodes and if you want to make any change in any part of your module you can just modify the node.
And then rest of the nodes will still work as is so it's very customizable right.
And also the because of its graph nature right it is very hyperformant because it has cat it handles cache better.
So you will have cat in sorry instruction cache better handle and because of the way the code is written the data cache data cache is always hot right.
So that ensures that you will have hyperformance right and VPP comes with native drivers along with your DPDK support right.
So if you have a native driver for VPP you can get the packet into the application software very fast okay.
So this ensures that the overall stack right from the packet is received on the packet I go interface into the application software the overall cycle of the software runs very fast.
Okay, so I handed it over to Alok here so we will take out the problem we are trying to solve in VPP.
Thank you.
So let's talk about the real problem here.
So today VPP handles all graph management into software development mode everything is done in the software.
But the key constructs of traffic management like shipping scheduling, polishing with multiple glass they are very CPU intensity jobs.
And with growing bandwidth and multiple classes included now in modern network and requirements it takes a lot of load on CPU.
And further further how the complexity of TM increases then it starts.
Eating up the CPU cycles which could have been used for actual packet processing.
So the thing what we are trying to say here is for the high bandwidth and modern workload we should be having a way to handle TM more efficiently,
especially by utilizing handling hardware whenever it is available.
And there is the interesting part here.
Now today smart mix and DPUs they already come with a full-flaced complex and very capable hardware TM engines.
But today VPP has no framework to utilize those hardware capabilities.
So that's what we are trying to solve here and to fill the gap.
We are building a TM offload framework in VPP which can leverage handling hardware.
Just to demonstrate what we just talked about.
So modern mix already have very capable engines which can do all these TM features in the hardware saving CPU cycles for the regular compute.
Okay so now what we did was something to bring hardware TM into VPP.
It needed a framework in scalable, generic and very what you can say hardware agnostic way.
It should not be dedicated for any particular hardware but any underlying hardware should be able to plug into the framework.
Very easily and does job with single unified API.
So that's what the key components of this framework are.
I'll go through them briefly.
First thing we talked about in E, Nickpender, in E hardware just one API can just plug and play.
And second important thing is capability base.
So in E Nick simply tells VPP what features can offer.
And then VPP's framework will decide to use those features.
Let's say if some hardware does not have a hardware TM capabilities,
this fine VPP is framework will understand.
And it will continue during TM in the software.
Add is just to say today.
And then it also allows you for the dynamic in nature.
For example, you should be able to update your TM recommends once you configured one thing.
You should be able to update it to remove some things to add new things without relaunching your application without halting a data plane.
That's what it provides.
Also it covers all the full TM spectrum, all the features that a standard TM should have.
This framework makes sure all are supported.
If handling hardware can fulfill their limitation.
And then the important part.
Suppose you have a proper TM implementation.
But then how the user interacts with it.
That's important right.
So today how it happens in VPP.
There's a classifier module.
So the user classifier is a flow that for this flow I want higher priority.
For a second flow I want more bandwidth.
And so on right.
Now this framework.
Just silently coupled with the same behavior.
So now also with this framework in place with hardware module in place.
User continue to tell is it come in the same way.
It will go to the classifier.
Relative comments.
Now classifier will link to the framework.
And it will see.
If hardware can do it.
Famer will offer to hardware get the job done.
If not.
Famer will utilize software get the job done.
So user don't need to know the exact details of hardware.
How many cues are there.
How the hardware looks.
How the architecture is.
Nothing like that.
It's just talk to VPP.
Everything is delivered silently in the back end.
And we have also a couple this framework with the standard VPP's control plan.
Which is binary pay.
So any configuration the TM can be done using the same binary APIs.
Nothing is changed.
Okay.
So that was about the brief intro of the framework.
What all it provides.
What all it can do.
Now briefly I'll just go over through the key concepts of
Traffic Management.
Not much in detail.
Just know what you.
For example, he wrote the scheduling.
He just like arranging your traffic into multiple levels.
So the highest priority traffic gets first days transfers first.
Then the lowest priority.
At the same time it can make sure others also not halt it.
Everyone gets a fair share.
You're not shaping.
It manages the traffic with two speeds.
One normal speed on which it operates.
And one peak speed temporarily.
In case the traffic spikes also.
It should not break.
It should handle that.
It's dual rate shipping.
And then Fiat in fairness as we talked about.
I have to work should get priority.
But at the same time we have to make sure that others also get the
Fiat share of the bandwidth.
And then policy thing is nothing but it just enforces.
The rules are followed.
So you have a.
Sit the limit at a particular rate.
If any traffic exceeds the limit.
It should be marked.
You should be dropped or you can take action.
It just watches whoever is following them.
We have seen the limit.
And all these things are RFC compliant as the framework.
Make sure implementation scan.
Doing proper compliant way.
Okay.
So now all this framework.
What it achieves for us right.
So very first and important thing performance.
So now at the very high speeds also.
You can actually have complete QS with any feature that you want.
With ultra low latency is.
Because now it has everything in the dedicated team.
In the dedicated team engines which are meant for those things.
Right.
Now scalability.
So now you can handle.
Hundreds and thousands of classes which is the real
requirement of QS network.
Now the TM and the communicating way more complex than the
Everworld.
And efficiency.
Obviously now all this TM compute is being handled away from
the CPU.
The heavy lifting is being done by the specialist hardware.
So CPUs, safe cycle, safe cost,
safe energy.
Reliability at very high speeds also.
Because it is being done in a dedicated hardware.
You can get very stable QS at the line rate also.
So we have implemented this framework for a
Marvel software and GPU.
We have tested few early results we are showing here.
And for.
This is for the very moderate traffic.
We are just starting up with the testing.
And for one core.
We are seeing a prox 20% gains.
We have been doing the same thing in the software.
Being the same thing in the hardware.
A focus is being foreflowers.
A prox 32% still is.
A lot more working progress.
Probably will come with a more accurate and more.
High class with the results.
And all this work is being upstream.
The patches are there in that DIO.
VPP is repo.
A standard review.
So people in VPP community please go have a look.
Suggest more improvements.
Just give a review comments.
More than welcome to just develop VPP and his feature altogether.
And as I mentioned.
This framework is intended for a hardware offload.
But it makes sure whatever today is then VPP.
That does not break.
So you will continue.
The software team as it is today.
And also all this work and patches are available in marvellous.
Open source repo also.
Which is called marvellous.
Detice liter of two solutions.
So the link is there.
They are also we can get the work.
What we will be doing on this.
Passive from our side.
Any questions?
Thank you.
Thank you very interesting.
So I was wondering about when you offload it to the hardware.
One of the things I didn't understand.
I don't understand fully the system.
Sorry for that.
So I'm trying to understand what is the impact on the
trusted computing base.
Does the hardware now also has access to the keys which
would use for communication protocol.
Or not.
That's my main concern here.
I mean you are getting performance for sure.
But if it's at the cost of security increasing the TCP.
That's not really nice.
No, yeah.
Yeah, interesting question.
So whatever we are talking right now is at the line.
Okay.
So whatever is the security protocol you want to add on to your data.
It's already done.
And it is the link on which you are sending from your code.
So the data is already secured by the time you send it.
It's just that when you're sending it on the line.
You're ensuring that your quality of service is handled on the hardware module.
Which is sitting on the same sock.
Okay.
Let me refresh my question.
Let's say so you are saying that the PLS protocol let's say has finished.
So PLS protocol has been established.
Now you're talking about what happens at the data layer.
Is it correct?
It's actually physically at not even data.
Okay.
Thanks.
There was another question up here, I believe.
So do you have any plans to add the same kind of capabilities to
Linux kernel or the DPDK framework?
Why only VPP and not can it be beneficial for kernel though?
DPDK?
So DPDK already has similar framework in place.
Okay.
And this is something which we adapted a similar framework in VPP as well.
Okay.
And what about the kernel?
kernel there is like this.
If you remember there's something called graphic TC.
Right.
I'm not completely aware of the framework as such.
There's some level of support already there.
But it is not because like you just space data plan framework like DPDK.
They are very much flexible to take new features.
It's about hardware of load.
Right.
It's not about user land or kernel.
Something done in software could be in kernel could be in user land.
But if it has interest for VPP, it has interest for the kernel.
It has for the kernel but it's about how flexible the community is to take new features.
I'm not complaining on Linux kernel people here, sorry about that.
But yeah, it's just the reality.
Okay.
Thank you.
Okay.
Any more questions?
We have time for one more.
If you have it.
No.
Okay.
Well, thank you to our speakers.
Thank you.
Yeah.
Just appreciate the VPP community who has helped us to upstream this feature.
Okay.
I appreciate them.
Thank you.