Thanks everyone for coming this event.
So today we are going to talk about VTP and what is the TLS plugin inside VTP and how we
have optimized it for better performance.
So today me and Barunar here who will go through the presentation.
So my friends from VTP community has already given you introduction on VTP, I will not
go deep into the VTP internals, but just a question to everyone.
So how many of you have had CPU architecture in your university class or somewhere, right?
Yeah.
So I see a lot of people, so one just statement I want to mention is that VTP is one of
the software which leverages very basically concepts of CPU architecture, like everybody
says that okay, you need to have data in L1 cache or instructions in L1 cache, right?
How many software make sure that you always have your instructions or data in the L1 cache
before you actually execute the instructions, right?
So this is from the program point of view, I feel that VTP is one of the very few software
which leverages this and gets the best performance out of your software okay.
So yeah we will move on.
So the agenda is that we will go over what TLS plugin is and what are the contributions
we have done to TLS plugin which enhances its performance and we will also briefly mention
about DPDK user space crypto driver because we internally leverage DPDK for enhanced
crypto performance and we will provide what is the actual functionality we have implemented
to increase the performance and we have some performance numbers comparison and what
is the future scope of the work we are going to do okay.
So what is VTPTLS plugin okay?
So as earlier sessions has already mentioned that everything in DPDK is a loadable plugin
okay.
So even the TLS functionality in VTP is a loadable plugin okay.
So TLS is a transport type which is exposed by VTP framework just like you want to say
that I want to do a transport socket of TCP type or UDP type right?
Similarly in VTP you can just say that I want to do a data transfer with the transport
of TLS.
So you just go and write to this socket and the underlying TLS implementation will encrypt
the data and then send it out right.
So it also provides integration with multiple TLS libraries.
Some of the examples are open as a cell and P-COTLS and M-M-M-M-TLS.
For the scope of this talk we will concentrate on the open as a cell because that is where
we had done some tests and performance comparison.
And in VTPTLS plugin we have the session management which is done within the TLS plugin
so that any application data which is sent to the TLS layer will know what kind of TLS
case to be used and case and then what is the underlying TCP connection on which you
have to send the package.
So it also provides some quantitativeability on what are the keys and certificates you have
to use for the data application data.
So going over the contribution which we are done to TLS plugin so for those who are aware
of open as cell software there is a it is not very recent but in earlier open as cell
they have introduced a concept of asynchronous crypto jobs.
So we have leverage that and then adapt to the same thing into the TLS plugin where you
can have a crypto job let us say you want to do a RSS sign operation.
So you can go and submit the instruction as a synchronous job you do not if there is an
accelerator which can work on the other side you do not need to wait for the operation to
complete the core comes back and it can do the application work and then by after some
time if you go and check like the crypto operation is done you can go receive the response
and then complete the overall request.
So that way we can save the time in which the RSS operation is getting done or any
crypto operation is getting done.
So we have also after adding this right we have verified this functionality with the
marble open as cell engine which we have written so that we can leverage the hardware accelerator
capabilities of marvell's DPU.
So these are the patches we have pushed to add the performance enhancements okay we can
go over it later.
So the marble open as cell which I have mentioned in the earlier slide it internally
uses DPDK crypto PMD so basically what it does is it goes and submit instructions using
the DPDK RTE APIs and then the underlying PMD will take care of the submission to the
actual hardware okay.
So just brief introduction on DPDK user space crypto as why it is faster it works on the PMD
basis.
So there is no interrupt handling or interrupt contact signatures so the performance will
be higher because of that and as synchronous passing so it allows you to submit the instructions
as synchronously and the two you can do it in a burst basis so that if you want to do 10
requests at a time you can go and submit 10 request and then go back do your work do your
application was come back and see how many are done once what like if X number of requests
are done you go and resume those operations and it also provides flexibility because there
is a software open as cell based crypto implementation in DPDK so you can have a comparison
against your hardware accelerated PMD versus software open as cell crypto implementation.
So that way you can say my implementation is like X percentage better than the software
based implementation and also we maintain session within the engine so that we for a certain
session we do not need to set it up multiple times basically if you have hundreds of
packets flowing to the same session the same session can be used once it is set up first
time and it is a standard API so instead of saying that if you are moving from one implementation
to another implementation underneath in the DPDK you do not need to change your code
match.
So Varun will take over here and then you will explain what is the actual work done at
the code level.
Yeah.
So this particular flow is explaining how the TLS plugin handles the TLS processing.
So whenever the TLS plugin which acts as a server receives any TLS traffic will see the
hand request type and it will send it to the open as cell engine using the SSL library
calls.
So the underlying library will check if the asynchronous mode is enabled or not.
If it is enabled then it checks what is the return value of the API.
If it says I want a sync then it passes the request to the next level which is a more
very open as cell engine which internally encodes the actual process to the hardware where
the actual work will be done and once the work is done the hardware accelerator will respond
back to the engine saying that the job is finished.
Where in the TLS plugin plugin will continuously pull the engine for the asynchronous
request completion whenever a request is completed we will get a call back and in the call
back we will see what kind of event that was completed.
So we are maintaining two different cues one for the handshake messages and the other
one for read and write events.
So based on the event type the particular event will be anchored into the respective
cue and it goes for the next level processing in the plugin.
So in this way the plugin will keep pulling the engine and in the next iteration what
it does is it decodes the cues and it processes the event based on the handler which
was written for the particular event type.
So there the actual work will be done and it completes the request and it will send the
response back to the application.
So here the TLS plugin acts as a server and it will respond back to the client.
So this particular is flow is showing the same thing.
Yeah these are the performance comparison numbers which we have captured with the software
and with the hardware acceleration.
On the left hand side we can see we have tested with one and two cores with different
file sizes and the right hand side we can see the hardware accelerator performance.
And the set set up is a simple DUT which is connected back to traffic generator where
it sends the packet and it gets the encrypted encrypted packet outside.
So we could see that the software numbers with software we are able to achieve up to 6 or
7Gbps up to different file sizes whereas in hardware accelerator the performance is much
better than the software one with asynchronous mode enabled and the testing conditions are
mentioned in the slide we have used RSA for RSA 4K and that very spare second improvement
that we observed was approximately 20% and when we are submitting this particular asynchronous
process to the hardware accelerator we saw an improvement of up to 50% in the CPU utilization
like where the CPU was free for processing something else in the PPP context.
We have also introduced this pipeline feature in the recent patch so these are the numbers
with different pipes with different record sizes so what pipes means like we can configure
in in number of pipes where a particular record of record will be given to those many pipes
and the hardware will process those many pipes of packets entirely.
So here we can see the performance with different number of pipes configuration.
So what we see here is like we expected much better performance with larger number of pipes but
it was not observed in that way but yeah this is something which we are which we will
be taking as a future scope.
So these are the future scope that we are planning where we are planning to upstream our
open SL engine to the marvel as a lecture to VPP as a separate plugin and also we are planning
to give the provider support in the TLS plugin and optimizing the performance with multiple
workers and multiple pipes. These are the things that we are planning in the future.
So along with TLS we have multiple data plan based accelerated solutions which can work on
marvel GPUs. So we have a open source GitHub repo where people can directly go and look
what are the solutions we are providing on our GPU. So we call it as a marvel doubt that data
acceleration of load GitHub. So there are multiple solutions based on DPDK, VPP, OVS and AMAAML
related solutions. So this is a GitHub repo so if there is anybody who is interested in data
plan networking solutions for it. There are some cool solutions you can try it out.
It's you cannot expect on a small hardware like a DPU like you can achieve like 100 MPPS of
L3 for a application. So you can just go over it. Try it out if you have any issues or any
ideas we are ready to help and work on it. That's all we had. Thank you.
Thank you. Any questions?
Hi, thanks for this work. Just a quick question. Are you relying on the crypto
async framework in VPP or is it your own type of framework on type of engine that's implemented
with marvel? Yes. So this is PLS implementation based on open SSL. Open SSL has its own internal
async crypto framework. Okay, so we create an async framework for open SSL not for
you. Okay, thanks. Okay, thank you very much. Thank you.