WEBVTT 00:00.000 --> 00:14.000 Hi everyone, so it's good to be back at Phorzdom, so last year we had a topic on FDIO VPP. 00:14.000 --> 00:25.000 Last time we talked about how we can integrate open SL into VPP and leverage hardware accelerators to enhance the performance of TLS. 00:25.000 --> 00:30.000 So this time the theme is similar but the topic is obviously different. 00:30.000 --> 00:46.000 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. 00:46.000 --> 00:56.000 So the brief agenda for today's talk, first we will have a brief intro on what we mentioned as traffic management or alternate. 00:56.000 --> 01:05.000 We can call it as quality of service and we will also give brief intro on VPP, FDIO VPP. 01:06.000 --> 01:14.000 So because today this is the first talk on VPP I will give some details so that the subsequent presenters can save the time. 01:14.000 --> 01:34.000 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. 01:34.000 --> 01:59.000 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. 01:59.000 --> 02:16.000 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. 02:16.000 --> 02:26.000 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. 02:26.000 --> 02:40.000 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. 02:40.000 --> 03:02.000 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. 03:02.000 --> 03:19.000 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. 03:19.000 --> 03:28.000 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. 03:28.000 --> 03:38.000 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. 03:38.000 --> 03:49.000 So when it comes to let us say a video traffic so for example videos you are watching a Netflix movie right. 03:49.000 --> 03:58.000 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. 03:58.000 --> 04:05.000 So that is and there is another hand of topic for example a general web traffic as quickly be traffic let's say. 04:05.000 --> 04:13.000 In such cases latency is okay but you don't want your packet to be lost right so it should be reliably delivered. 04:13.000 --> 04:18.000 So if you see here for each kind of traffic there are different kind of requirements. 04:18.000 --> 04:24.000 So what that means is that the quality of service requirements for each of these traffic are different right. 04:24.000 --> 04:36.000 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. 04:36.000 --> 04:41.000 The quality as SLS so agreed with the service provider okay. 04:41.000 --> 04:53.000 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. 04:54.000 --> 05:03.000 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. 05:03.000 --> 05:16.000 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. 05:16.000 --> 05:22.000 So these are the kind of metrics you normally use right. 05:22.000 --> 05:32.000 So that's all on the QOS so we'll move on to the VPP right. 05:32.000 --> 05:43.000 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. 05:43.000 --> 05:56.000 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. 05:56.000 --> 06:11.000 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. 06:11.000 --> 06:16.000 And then rest of the nodes will still work as is so it's very customizable right. 06:16.000 --> 06:26.000 And also the because of its graph nature right it is very hyperformant because it has cat it handles cache better. 06:26.000 --> 06:38.000 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. 06:38.000 --> 06:48.000 So that ensures that you will have hyperformance right and VPP comes with native drivers along with your DPDK support right. 06:48.000 --> 06:55.000 So if you have a native driver for VPP you can get the packet into the application software very fast okay. 06:55.000 --> 07:07.000 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. 07:07.000 --> 07:17.000 Okay, so I handed it over to Alok here so we will take out the problem we are trying to solve in VPP. 07:17.000 --> 07:20.000 Thank you. 07:20.000 --> 07:26.000 So let's talk about the real problem here. 07:26.000 --> 07:34.000 So today VPP handles all graph management into software development mode everything is done in the software. 07:34.000 --> 07:41.000 But the key constructs of traffic management like shipping scheduling, polishing with multiple glass they are very CPU intensity jobs. 07:41.000 --> 07:50.000 And with growing bandwidth and multiple classes included now in modern network and requirements it takes a lot of load on CPU. 07:50.000 --> 07:57.000 And further further how the complexity of TM increases then it starts. 07:57.000 --> 08:05.000 Eating up the CPU cycles which could have been used for actual packet processing. 08:05.000 --> 08:16.000 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, 08:16.000 --> 08:20.000 especially by utilizing handling hardware whenever it is available. 08:20.000 --> 08:22.000 And there is the interesting part here. 08:22.000 --> 08:30.000 Now today smart mix and DPUs they already come with a full-flaced complex and very capable hardware TM engines. 08:30.000 --> 08:36.000 But today VPP has no framework to utilize those hardware capabilities. 08:36.000 --> 08:40.000 So that's what we are trying to solve here and to fill the gap. 08:40.000 --> 08:52.000 We are building a TM offload framework in VPP which can leverage handling hardware. 08:52.000 --> 08:54.000 Just to demonstrate what we just talked about. 08:54.000 --> 09:04.000 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. 09:04.000 --> 09:14.000 Okay so now what we did was something to bring hardware TM into VPP. 09:14.000 --> 09:23.000 It needed a framework in scalable, generic and very what you can say hardware agnostic way. 09:23.000 --> 09:29.000 It should not be dedicated for any particular hardware but any underlying hardware should be able to plug into the framework. 09:29.000 --> 09:32.000 Very easily and does job with single unified API. 09:32.000 --> 09:35.000 So that's what the key components of this framework are. 09:35.000 --> 09:37.000 I'll go through them briefly. 09:37.000 --> 09:43.000 First thing we talked about in E, Nickpender, in E hardware just one API can just plug and play. 09:43.000 --> 09:46.000 And second important thing is capability base. 09:46.000 --> 09:50.000 So in E Nick simply tells VPP what features can offer. 09:50.000 --> 09:53.000 And then VPP's framework will decide to use those features. 09:53.000 --> 09:57.000 Let's say if some hardware does not have a hardware TM capabilities, 09:57.000 --> 09:59.000 this fine VPP is framework will understand. 09:59.000 --> 10:01.000 And it will continue during TM in the software. 10:01.000 --> 10:04.000 Add is just to say today. 10:04.000 --> 10:09.000 And then it also allows you for the dynamic in nature. 10:09.000 --> 10:14.000 For example, you should be able to update your TM recommends once you configured one thing. 10:14.000 --> 10:22.000 You should be able to update it to remove some things to add new things without relaunching your application without halting a data plane. 10:22.000 --> 10:24.000 That's what it provides. 10:24.000 --> 10:28.000 Also it covers all the full TM spectrum, all the features that a standard TM should have. 10:28.000 --> 10:31.000 This framework makes sure all are supported. 10:31.000 --> 10:34.000 If handling hardware can fulfill their limitation. 10:34.000 --> 10:36.000 And then the important part. 10:36.000 --> 10:39.000 Suppose you have a proper TM implementation. 10:39.000 --> 10:42.000 But then how the user interacts with it. 10:42.000 --> 10:43.000 That's important right. 10:43.000 --> 10:45.000 So today how it happens in VPP. 10:45.000 --> 10:47.000 There's a classifier module. 10:47.000 --> 10:52.000 So the user classifier is a flow that for this flow I want higher priority. 10:52.000 --> 10:54.000 For a second flow I want more bandwidth. 10:54.000 --> 10:56.000 And so on right. 10:56.000 --> 10:58.000 Now this framework. 10:58.000 --> 11:02.000 Just silently coupled with the same behavior. 11:02.000 --> 11:06.000 So now also with this framework in place with hardware module in place. 11:06.000 --> 11:09.000 User continue to tell is it come in the same way. 11:09.000 --> 11:11.000 It will go to the classifier. 11:11.000 --> 11:12.000 Relative comments. 11:12.000 --> 11:15.000 Now classifier will link to the framework. 11:15.000 --> 11:18.000 And it will see. 11:18.000 --> 11:20.000 If hardware can do it. 11:20.000 --> 11:22.000 Famer will offer to hardware get the job done. 11:22.000 --> 11:23.000 If not. 11:23.000 --> 11:25.000 Famer will utilize software get the job done. 11:25.000 --> 11:28.000 So user don't need to know the exact details of hardware. 11:28.000 --> 11:29.000 How many cues are there. 11:29.000 --> 11:30.000 How the hardware looks. 11:30.000 --> 11:31.000 How the architecture is. 11:31.000 --> 11:32.000 Nothing like that. 11:32.000 --> 11:33.000 It's just talk to VPP. 11:33.000 --> 11:37.000 Everything is delivered silently in the back end. 11:37.000 --> 11:43.000 And we have also a couple this framework with the standard VPP's control plan. 11:43.000 --> 11:45.000 Which is binary pay. 11:45.000 --> 11:49.000 So any configuration the TM can be done using the same binary APIs. 11:50.000 --> 11:52.000 Nothing is changed. 12:01.000 --> 12:02.000 Okay. 12:02.000 --> 12:04.000 So that was about the brief intro of the framework. 12:04.000 --> 12:05.000 What all it provides. 12:05.000 --> 12:07.000 What all it can do. 12:07.000 --> 12:11.000 Now briefly I'll just go over through the key concepts of 12:11.000 --> 12:13.000 Traffic Management. 12:13.000 --> 12:14.000 Not much in detail. 12:14.000 --> 12:15.000 Just know what you. 12:15.000 --> 12:17.000 For example, he wrote the scheduling. 12:17.000 --> 12:22.000 He just like arranging your traffic into multiple levels. 12:22.000 --> 12:27.000 So the highest priority traffic gets first days transfers first. 12:27.000 --> 12:29.000 Then the lowest priority. 12:29.000 --> 12:32.000 At the same time it can make sure others also not halt it. 12:32.000 --> 12:34.000 Everyone gets a fair share. 12:34.000 --> 12:35.000 You're not shaping. 12:35.000 --> 12:38.000 It manages the traffic with two speeds. 12:38.000 --> 12:41.000 One normal speed on which it operates. 12:41.000 --> 12:43.000 And one peak speed temporarily. 12:43.000 --> 12:45.000 In case the traffic spikes also. 12:45.000 --> 12:46.000 It should not break. 12:46.000 --> 12:47.000 It should handle that. 12:47.000 --> 12:48.000 It's dual rate shipping. 12:48.000 --> 12:50.000 And then Fiat in fairness as we talked about. 12:50.000 --> 12:52.000 I have to work should get priority. 12:52.000 --> 12:55.000 But at the same time we have to make sure that others also get the 12:55.000 --> 12:57.000 Fiat share of the bandwidth. 12:57.000 --> 13:00.000 And then policy thing is nothing but it just enforces. 13:00.000 --> 13:01.000 The rules are followed. 13:01.000 --> 13:03.000 So you have a. 13:03.000 --> 13:05.000 Sit the limit at a particular rate. 13:05.000 --> 13:07.000 If any traffic exceeds the limit. 13:07.000 --> 13:08.000 It should be marked. 13:08.000 --> 13:10.000 You should be dropped or you can take action. 13:10.000 --> 13:12.000 It just watches whoever is following them. 13:12.000 --> 13:13.000 We have seen the limit. 13:14.000 --> 13:17.000 And all these things are RFC compliant as the framework. 13:17.000 --> 13:19.000 Make sure implementation scan. 13:19.000 --> 13:21.000 Doing proper compliant way. 13:24.000 --> 13:25.000 Okay. 13:25.000 --> 13:26.000 So now all this framework. 13:26.000 --> 13:28.000 What it achieves for us right. 13:28.000 --> 13:30.000 So very first and important thing performance. 13:30.000 --> 13:33.000 So now at the very high speeds also. 13:33.000 --> 13:36.000 You can actually have complete QS with any feature that you want. 13:36.000 --> 13:38.000 With ultra low latency is. 13:38.000 --> 13:41.000 Because now it has everything in the dedicated team. 13:41.000 --> 13:44.000 In the dedicated team engines which are meant for those things. 13:44.000 --> 13:45.000 Right. 13:45.000 --> 13:46.000 Now scalability. 13:46.000 --> 13:47.000 So now you can handle. 13:47.000 --> 13:50.000 Hundreds and thousands of classes which is the real 13:50.000 --> 13:51.000 requirement of QS network. 13:51.000 --> 13:54.000 Now the TM and the communicating way more complex than the 13:54.000 --> 13:55.000 Everworld. 13:55.000 --> 13:57.000 And efficiency. 13:57.000 --> 14:01.000 Obviously now all this TM compute is being handled away from 14:01.000 --> 14:02.000 the CPU. 14:02.000 --> 14:05.000 The heavy lifting is being done by the specialist hardware. 14:05.000 --> 14:07.000 So CPUs, safe cycle, safe cost, 14:07.000 --> 14:09.000 safe energy. 14:09.000 --> 14:12.000 Reliability at very high speeds also. 14:12.000 --> 14:14.000 Because it is being done in a dedicated hardware. 14:14.000 --> 14:17.000 You can get very stable QS at the line rate also. 14:17.000 --> 14:20.000 So we have implemented this framework for a 14:20.000 --> 14:22.000 Marvel software and GPU. 14:22.000 --> 14:25.000 We have tested few early results we are showing here. 14:25.000 --> 14:27.000 And for. 14:27.000 --> 14:29.000 This is for the very moderate traffic. 14:29.000 --> 14:31.000 We are just starting up with the testing. 14:31.000 --> 14:32.000 And for one core. 14:32.000 --> 14:35.000 We are seeing a prox 20% gains. 14:35.000 --> 14:37.000 We have been doing the same thing in the software. 14:37.000 --> 14:39.000 Being the same thing in the hardware. 14:39.000 --> 14:41.000 A focus is being foreflowers. 14:41.000 --> 14:43.000 A prox 32% still is. 14:43.000 --> 14:45.000 A lot more working progress. 14:45.000 --> 14:48.000 Probably will come with a more accurate and more. 14:48.000 --> 14:50.000 High class with the results. 14:50.000 --> 14:53.000 And all this work is being upstream. 14:53.000 --> 14:55.000 The patches are there in that DIO. 14:55.000 --> 14:56.000 VPP is repo. 14:56.000 --> 14:57.000 A standard review. 14:57.000 --> 15:00.000 So people in VPP community please go have a look. 15:00.000 --> 15:02.000 Suggest more improvements. 15:02.000 --> 15:04.000 Just give a review comments. 15:04.000 --> 15:10.000 More than welcome to just develop VPP and his feature altogether. 15:10.000 --> 15:12.000 And as I mentioned. 15:12.000 --> 15:15.000 This framework is intended for a hardware offload. 15:15.000 --> 15:18.000 But it makes sure whatever today is then VPP. 15:18.000 --> 15:19.000 That does not break. 15:19.000 --> 15:21.000 So you will continue. 15:21.000 --> 15:24.000 The software team as it is today. 15:24.000 --> 15:28.000 And also all this work and patches are available in marvellous. 15:28.000 --> 15:30.000 Open source repo also. 15:30.000 --> 15:34.000 Which is called marvellous. 15:34.000 --> 15:36.000 Detice liter of two solutions. 15:36.000 --> 15:38.000 So the link is there. 15:38.000 --> 15:40.000 They are also we can get the work. 15:40.000 --> 15:44.000 What we will be doing on this. 15:44.000 --> 15:48.000 Passive from our side. 15:48.000 --> 15:50.000 Any questions? 15:50.000 --> 15:52.000 Thank you. 15:52.000 --> 15:53.000 Thank you. 15:53.000 --> 16:07.000 Thank you very interesting. 16:07.000 --> 16:11.000 So I was wondering about when you offload it to the hardware. 16:11.000 --> 16:15.000 One of the things I didn't understand. 16:15.000 --> 16:17.000 I don't understand fully the system. 16:17.000 --> 16:18.000 Sorry for that. 16:18.000 --> 16:21.000 So I'm trying to understand what is the impact on the 16:21.000 --> 16:23.000 trusted computing base. 16:23.000 --> 16:27.000 Does the hardware now also has access to the keys which 16:27.000 --> 16:31.000 would use for communication protocol. 16:31.000 --> 16:33.000 Or not. 16:33.000 --> 16:35.000 That's my main concern here. 16:35.000 --> 16:37.000 I mean you are getting performance for sure. 16:37.000 --> 16:41.000 But if it's at the cost of security increasing the TCP. 16:41.000 --> 16:43.000 That's not really nice. 16:43.000 --> 16:44.000 No, yeah. 16:44.000 --> 16:45.000 Yeah, interesting question. 16:45.000 --> 16:49.000 So whatever we are talking right now is at the line. 16:49.000 --> 16:50.000 Okay. 16:50.000 --> 16:55.000 So whatever is the security protocol you want to add on to your data. 16:55.000 --> 16:57.000 It's already done. 16:57.000 --> 17:01.000 And it is the link on which you are sending from your code. 17:01.000 --> 17:05.000 So the data is already secured by the time you send it. 17:05.000 --> 17:08.000 It's just that when you're sending it on the line. 17:08.000 --> 17:13.000 You're ensuring that your quality of service is handled on the hardware module. 17:13.000 --> 17:15.000 Which is sitting on the same sock. 17:15.000 --> 17:16.000 Okay. 17:16.000 --> 17:18.000 Let me refresh my question. 17:18.000 --> 17:22.000 Let's say so you are saying that the PLS protocol let's say has finished. 17:22.000 --> 17:24.000 So PLS protocol has been established. 17:24.000 --> 17:27.000 Now you're talking about what happens at the data layer. 17:27.000 --> 17:28.000 Is it correct? 17:28.000 --> 17:31.000 It's actually physically at not even data. 17:31.000 --> 17:32.000 Okay. 17:32.000 --> 17:33.000 Thanks. 17:33.000 --> 17:34.000 Thanks. 17:34.000 --> 17:38.000 There was another question up here, I believe. 17:38.000 --> 17:47.000 So do you have any plans to add the same kind of capabilities to 17:47.000 --> 17:51.000 Linux kernel or the DPDK framework? 17:51.000 --> 17:56.000 Why only VPP and not can it be beneficial for kernel though? 17:56.000 --> 17:57.000 DPDK? 17:57.000 --> 18:02.000 So DPDK already has similar framework in place. 18:02.000 --> 18:03.000 Okay. 18:03.000 --> 18:09.000 And this is something which we adapted a similar framework in VPP as well. 18:09.000 --> 18:10.000 Okay. 18:10.000 --> 18:11.000 Okay. 18:11.000 --> 18:13.000 And what about the kernel? 18:13.000 --> 18:16.000 kernel there is like this. 18:16.000 --> 18:19.000 If you remember there's something called graphic TC. 18:19.000 --> 18:20.000 Right. 18:20.000 --> 18:22.000 I'm not completely aware of the framework as such. 18:22.000 --> 18:24.000 There's some level of support already there. 18:24.000 --> 18:30.000 But it is not because like you just space data plan framework like DPDK. 18:30.000 --> 18:34.000 They are very much flexible to take new features. 18:34.000 --> 18:36.000 It's about hardware of load. 18:36.000 --> 18:37.000 Right. 18:37.000 --> 18:40.000 It's not about user land or kernel. 18:40.000 --> 18:43.000 Something done in software could be in kernel could be in user land. 18:43.000 --> 18:47.000 But if it has interest for VPP, it has interest for the kernel. 18:47.000 --> 18:54.000 It has for the kernel but it's about how flexible the community is to take new features. 18:54.000 --> 18:59.000 I'm not complaining on Linux kernel people here, sorry about that. 18:59.000 --> 19:02.000 But yeah, it's just the reality. 19:02.000 --> 19:03.000 Okay. 19:03.000 --> 19:04.000 Thank you. 19:08.000 --> 19:09.000 Okay. 19:10.000 --> 19:11.000 Any more questions? 19:11.000 --> 19:12.000 We have time for one more. 19:12.000 --> 19:13.000 If you have it. 19:13.000 --> 19:14.000 No. 19:14.000 --> 19:15.000 Okay. 19:15.000 --> 19:17.000 Well, thank you to our speakers. 19:17.000 --> 19:18.000 Thank you. 19:21.000 --> 19:22.000 Yeah. 19:22.000 --> 19:27.000 Just appreciate the VPP community who has helped us to upstream this feature. 19:27.000 --> 19:28.000 Okay. 19:28.000 --> 19:29.000 I appreciate them. 19:29.000 --> 19:30.000 Thank you.