Hey, everyone. Welcome to today's day trading recap for Thursday, June 10th. Nice day.  All runners, no mighty 90s. Actually, two days in a row with no mighty 90s now. No pairs trades. So all of these were runners. So had a trade in the NASDAQ, MNQ, plus 212.50. Apple, my biggest loser, minus 1,670. Amazon, nice winner, plus 1210. BA, plus 500. MRNA, minus 752. Roku, plus 1,145. Tesla, plus 370. And Netflix, 632. Some of these had multiple trades. So let's go over these and I will show you what happened. Let's start with the NASDAQ, just to give you kind of an idea of why it was such a crazy day to begin with. If we expand this out, so here's the open. Let me scrunch this in. So here's the open right here. And this thing just fired up. Pre-market was the CPI number came out and stocks got started getting strong, strong pre-market and then the market opened up and they just absolutely fired up. So we were in some bullish trades doing well. In fact, I was up probably around the same amount that I ended with, about $1,600 at one point, kind of early in the morning. And then things just fell apart. And it took it all back plus more. So I was down on the day. I was in the red. But I continued to trade, ended up closing my last trade out at like one o'clock, which is a little bit later than I wanted to be trading today. But this thing bounced hard and continued to go higher. I just, for whatever reason, part of it was the CPI announcement, the initial strength. I just, I did not believe that the market was going to continue lower. And I was right. In fact, I said it during our live stream, I said, when we were down here in the dumps, I said, or maybe when it started to bounce here, but right around here, I remember saying, I think the NASDAQ and the S&P are going to close above the highs of day and look where it is right now. Now, we've still got an hour before the end of the market, cash market. And so anything can happen. But look where we are right back up at highs of the day. And this isn't to say, hey, look at me. I'm so smart. Look at me. I predicted what the market's going to do. That's not it at all. My point of even saying that is I'm just trying to tell you what I was thinking during this period where the market was selling off. I just, I didn't believe it. I just, I didn't, uh, whether it was the price action or like I said, you know, based on the first part of the market, uh, I just, I felt like we were going to bounce. And so I played, played my trades accordingly. So, uh, in the NASDAQ, what we did here is when it started to pull back to yesterday's high right here, this is when I initiated my first long in the futures. And then as it came down, the S and P at the same time was bouncing right off unchanged. NASDAQ didn't quite get there. It was a little bit stronger. So right in this area, I think pretty close to the lows, I added to that position and caught a huge bounce. And so just kind of scaled out of this as it, as it crept higher.  And this was a, actually two different trades here. Uh, one was, let me double check here just to make sure, yeah, we had one, one short, one long. So my first, uh, long trade was when we had this initial strength and it started to pull back to yesterday's high, kind of like about the same time I did the NASDAQ, uh, I got long right here and was looking for a continuation higher. Well, that's when the market just fell apart. And so I held, held, held, thought we might bounce off the unchanged mark. Didn't happen. This thing pushed through. So I ended up closing it out down here near the lows of day. Uh, so took a sizable loss on that one. And then, um, I turned around when things started getting weak, Apple, the market started really rebound, but Mark, but Apple was still chopping under yesterday's low. And so I was looking for a continued weakness. So I actually got short Apple looking for a continuation lower. And it just chopped around, chopped around. And finally it kind of started to creep up. I just, I just cut out of it, and took another loss in Apple. So I got double whammy in Apple.  Um, let's see. Whoops. Let me bring this back over. Oh, uh, let's see. Next one, Amazon. Okay. So Amazon was a nice one. I got in and out of this one really nicely. So as the market was just absolutely tanking, Amazon was holding pretty steady. It was still holding above this pivot. So got in right here. It bounced. I actually meant to get out of half my position to hold for more, but accidentally closed out the entire thing. And so there's just a couple contracts, but booked, I think it was like a $600 profit just on that bounce. Amazon's obviously a big, big product. And so, uh, then when it came back down here, I got back in and got out of half on this bounce. And then as it started to creep up here, I think I cut out of my last piece. So just those, those little bounces in Amazon book 12, 10 on that. And then BA Boeing was, uh, it was plus 500 for me on the day. So in Boeing, uh, let's see. I caught this. No, let's see. That's not it. Oh yeah. When it, when it bounced up here, uh, got short and caught this move lower for a nice $500 profit in BA.  So Apple and MRNA were my two losers. I totally blame, who gave me this? Doug? Doug gave me this. Yeah, I blame Doug on this one. Uh, just kidding. But, um, I had this nice volume spike out of the gate, pulled back, got long and had a quick push up and, uh, booked, booked some profits there, took off half my position, was waiting for a little bit more, but it just kind of started chopping around, chopping and dropping. And then when it fell, I ended up getting out of my last piece down here. So ended up net, net, took a loss on MRNA. Uh, one, one thing in hindsight, you know, I, I probably should have, I probably should have cut out of my last half once it broke below this kind of consolidation area here somewhere in here instead of waiting till down here. Uh, so it could have been a less of a loss, but, uh, you know, what are you going to do? Uh, Roku, another nice winner. So in Roku had this big volume spike here, got in on this little pullback bounced up, got out of some, came back down, got in again, got out of some more. Uh, and so I was out of three, I had one little piece left. I think it was even just one contract left. And when it started to break down with the rest of the market, I cut out of my last piece there. Uh, still booked, uh, 1,145 on Roku and then Tesla. Tesla was a wild one. Um, so in Tesla had this big, a lot of volume here. So when it, when it pulled back here, uh, actually, I think just on this little pullback here, I got, I caught this initial move up, uh, booked profits there, came back down. I thinking I was, I think I was wishing I would have added to it, but I didn't, it bounced up. And then, um, I can't remember exactly my entry, but the late day trade was, um, when it made this big push up here and pulled back, I jumped in for another long and got some profits there and pushed up again. I think I got out of my last piece right in this area. So ended up net, net booking 370 took, uh, took one loss. Oh yeah. I was still holding someone. I got caught in this downdraft and so that was the, uh, that was the part that hurt. So I booked some profits on the way up, lost some on the way down and then got back in and booked some profits on that one. Uh, and then Netflix plus 632. So I'm sitting here looking at my screen. Um, and this is a little bit later in the morning right here and all of a sudden Netflix just absolutely takes off. And so I didn't wait for much of a pullback. Got a tiny little pullback got in and this thing just shot up and I got out of half and then it pulled all the way back here. I got back in and caught some of this, took some off and then it just kind of started chopping around. So I ended up cutting out of my last piece in this area. Uh, so booked a 632 in Netflix. Uh, so that's it on the day plus, uh, 1647 50 a nice bounce back from a decent size red day yesterday. Uh, still down on the week. It hasn't been a great trading week, but, um, you know, holding, holding my own and today's 1600 plus certainly helped. So we'll be streaming live tomorrow. Look forward to seeing you in the live stream room. We'll talk to you then.


What is the future of online jobs? Okay, we're hearing about online jobs a lot. And is it true that you're gonna be able to work from home and what's the future of this? Is this really gonna hold? Well, if you wanna know the answers to those questions, you're gonna wanna stick to the very end on this video. Now, the effect of coronavirus and the pandemic on the workforce has really been tremendous. In April of 2020, there was an MIT survey done of 25,000 workers. Of that 25,000, 34% of those people are now working from home. And when pushed a little bit further, they found out that 15% of those people had already been working from home before the pandemic. So that means that half of the workforce that they surveyed is working from home. Now, this is also true of people over the age of 55 years old. I mean, let's face it, the workforce has changed forever because of the pandemic. It just has. And if you're not taking advantage of this, you're gonna miss out. I mean, the fact is research has proved that working from home actually increases productivity. It also helps people with life work balance and people just plain seem to be happier. Not to mention the fact that it has a drastic decrease in pollution because people aren't driving around in their cars. I mean, companies are figuring this out. They really are. New York City based real estate, commercial real estate company, Square Foot has now provided all their employees with laptops to work from home. There's even grants from state and federal governments if you let your employees work from home now.  Being able to work from home, that's kind of a privilege now. Not everybody can do that. The fact that people can do that has to do with the fact that the work they do can be done on a computer like this. Now, if the work you do cannot be done on a computer like this, then obviously you can't work from home, but that is a tremendous benefit. The fact is not all businesses agree with this and the people who didn't agree with having their employees work at home, they were worried about productivity, they were worried about they would screw off and not do their job. A lot of those companies may bring them back into the office, but will that actually hurt those companies? Will that hurt their productivity? Will that lower their overall profits because they're having to pay for an office, they're having to pay for equipment and utilities and lighting and all this stuff to keep an employee in a building and they don't even need to be there. Now there's some downsides to this. I mean, you think about sales when you're working online on a computer like this, it's really difficult to read your prospect if you can't see them. Now it's true, maybe the interest in having people work from home once the COVID thing passes or fades away that a lot of these companies are gonna go back to their old ways, but don't forget, there's a lot of them, they're gonna realize the benefits of this. They're gonna realize that it saved them a ton of money, their employees are happier and it costs them less to actually employ these people. Matter of fact, according to a lot of surveys, some of the employees that were working from home said they would take less pay if they were allowed to work from home. Now you think about that, if you paid the employee less money, in addition to that, it cost you less money to employ them. That's a huge savings. But we've gotta address other things like 17% of the people working from home said their number one problem was loneliness. They had no coworkers, nobody to talk to. So how are we gonna facilitate having these people work from home still interact with their fellow employees? Will we have luncheons out? Will we have meetings once a month? Will we do some Skype or Zoom things? I'm not sure, but something needs to be done in that area too. Now you know that when we return to the offices, those people who do return to the offices, the offices are gonna look a lot different. We're gonna probably have to space people out. We're probably gonna have to put dividers between people. We're probably gonna have bottles of Purell and sterile wipes everywhere. So it is gonna change when you go back to the office. But ideally, if you don't have to go back to the office, you shouldn't. Now, if you're trying to consider, should you work online? Should you work from home? Understand that it's not always working from home. I have the decided advantage that I can sit in my office here and I can work. But I gotta tell you, this office here is nice and my desk and everything I have is real nice, but I don't work in here. This is for videos. That's all this is for is my videos. For the most part, when I work, I'm at some coffee shop. I'm at a Starbucks or I'm at some place that has internet connection. Occasionally I will work at home, sit on the couch and work a little bit. It's not my preferred thing to do. I wanna be out with people and I think most people wanna be out with people too. That allure of always being in your house and kind of wear thin on your nerves.  It becomes the cycle of nothing ever changes. You have no scenery. So I believe in being able to work wherever I want, but sometimes it's at the lake. Sometimes it's at the oceanfront. Sometimes it's at a Starbucks somewhere. I like the freedom of being able to go to different places and I think most people do. Now I don't interact on the telephone with people that much. It's usually through Skype or it's usually through emails or texts. So I don't need a really quiet environment. When I'm in a Starbucks or something like that, if it's noisy and the coffee's whistling and people are coming in and out, it doesn't matter to me. Some jobs aren't like that. Some jobs require that somebody be on the phone all day and that they have, you know, they're very quiet behind them. So they're gonna have to figure out how to work that into their new work life. Now the other thing I want you to think about when you think about working from home, you can work the hours you want. It's no longer a nine to five.  So you take your kids to school at nine, but you got up at six o'clock and worked from seven to eight 30 before you did that. So that was some work you could get done. If you were commuting to a job, you couldn't do that. It would be difficult to do that because now once I've dropped off the kids, I've gotten that done. I can come back to the house. I can work a few hours.  Maybe broken up. You know, maybe I want to work in the evenings once the kids go to bed. I want to work till midnight. That's what I choose to do. Maybe I want to work on the weekends. The time thing doesn't matter. I know I work online a lot with people from around the world. We have employees in India. I have employees in the Philippines. I have employees in Serbia. They're all around the world. So time zones are different. So the time is not really relative to what I have to do. I try to let everybody who works with our company work on their time zone, whatever works for them. I think that's the polite thing to do. I don't need them to be awake when I'm awake. If I need to have a meeting with them, we can have a meeting. I have very few meetings. That's another thing that I think you're gonna see go away to is this meeting culture we had.  It was meeting ridiculousness, okay? We did meetings on stuff that we could have just texted each other the information. We didn't need to do this. I think a lot of the meetings was to call out individuals in front of a group which I don't think is productive at all. I don't think so. I was in a sales environment so we were showing one person sales against another person, their profitability and what they were doing and it was more a shaming meeting than anything else. So that did nothing for morale. It took up part of our day and it pitted these different managers against each other. So I never did understand those meetings. Maybe you have meetings like that with your company and if so, put them in the comments below.   I'd love to hear that. So overall, yeah, online jobs are going to increase. That's just a fact. Some companies are going to take advantage of this. They're gonna pay less money. They just are. But you're gonna save money from commuting. In addition to that, a lot of these companies are gonna be more profitable because they can let people work from home, especially any software companies. I mean, you look at places like Google and Twitter and Facebook, all these people have in-home employees now. They had them before and they're gonna have more now. It's gonna change. Other companies that weren't as traditional maybe an insurance company or a medical device company or something that had people in the office are gonna realize they don't need them there anymore. I realized this years ago with my business, now parts of my industry, we have a warehouse and we have survival food we ship out. So we have people in a warehouse. We have boxes that are going out. Obviously those people can't work from home. Okay, they have to show up at the warehouse to ship stuff out. But the employees who can work from home, the people that maybe edit my videos or that write my blogs or that work on my websites, all those people have always worked from home. They will always work from home and will never have an office form and it will never cost me money to put a desk and a computer and lighting and air conditioning and all that for those people because it's just not necessary. So if you're thinking about working online, if you're thinking about, you know, maybe your job's gonna go online, it's a good thing. I think overall it's a very good thing. Remember to break it up with some interaction with other people.  I still leave and go out to lunch. I rarely eat at home because I like getting out. I like getting away. So I incorporate that with my work day to make it feel more normal. And you can do the same thing. I hope you enjoyed this video. If you did enjoy this video, do me a favor, give me a thumbs up like this. And if you have not hit that subscribe button yet, please do so. It's a red button right down here. See, take a look. If it's red, that means you haven't hit it. Once you hit it, it'll turn gray. Go ahead and try it right now. Click, click right there. See it turn gray? Hey, did you see the bell pop up next to it? You gotta ring the bell. You gotta turn on all notifications so that every time I do a new video, every time I go live, I can tell you about it and you won't miss out. You'll be part of the Fisher family, the VIP group, who gets reminded every single time I do a video. In addition to that, what I did is I put together a course. It's a $97 course. You'll see it down in the description to scroll down a little bit. And you can click it and get it for free. $97 course for free, no credit card required. So check that out. I really appreciate you listening to this video. Really appreciate you being somebody on the channel. Please interact. Please put comments below. Let me know what you thought of this video. If you've got another idea for another video you wanna see me cover, we cover everything about making money online on this channel. I would love to hear it. Thank you so much for watching this video and I'll see you in the next one. Hey, thanks for watching my video. Don't forget to subscribe to my channel and click that little bell right here so you can be notified every time I do a new video. Also, click on one of those videos there. Keep watching on my channel.


Hello, I'm Juliana, I'm working on NXP for almost eight years and in the last two I've been part of the Linux security team working on CamDriver, the NXP module for crypto acceleration. Today I'll talk about the crypto engine framework I discovered while working on game script and backlogging support for Cam. During the talk, I'll cover this content, what is crypto engine and what it can be used for, how can it be used and we'll talk about this API. I'll present you the improvements I've added to the framework and what performance we gained by using the new features, how a driver can be updated to include these improvements. Next, we'll discuss some ideas for enhancement and at the end we'll draw some conclusions. For what is crypto engine, I'll start by telling you one of its use cases. I found out about crypto engine while adding support for game script in CamDriver. In crypto layer, the block site for hardware engine driver patches requests from game script into its queue to wait for its thread or work queue to handle and finalize the request when finishing the encryption or decryption. However, the old method needed each hardware engine driver to implement and maintain their own queue and thread for processing requests. Linaro introduced in 2016 crypto engine framework that implements the queue and thread for pushing requests to the hardware as the hardware becomes free so that drivers could use it. At the same time, it can avoid some reduplicated code in hardware engine driver. So crypto engine, it's a queue manager. It manages asynchronous requests in form of cryptosync request. It supports SKCypher, AKCypher, AAD, and hash request. More important, crypto engine manages all crypto transformations that request backlogging. That means they have the crypto TFM Req made backlog like said. The purpose of a made backlog is to make the crypto request reliable. Without the backlog flag, if the hardware queue is full, the request will simply be dropped, which is appropriate in the network case with IPsec, for example. Blocklayer, on the other hand, should always use the backlog flag and stop sending more requests to the crypto API until the congestion goes away. So crypto engine queue, the request for later execution, it doesn't drop it. It also keeps the order of the request. This is one important aspect for the encrypt with the game cryptos case. In Kiernan, there are already a lot of drivers that use crypto engine and here is a list of these drivers. Next, we'll talk about how to use crypto engine and we'll discuss its API. As I mentioned, crypto engine is a queue manager, has its own queue, so first remove any request queue and the thread or work queue or tasklet which is used to queue request in the driver. Crypto engine only manages crypto async requests, but we can retrieve the original request by using container op. Also, crypto engine has specific function for each of these async requests as we'll see later on. There are two structures in crypto engine that each driver must include. We have the crypto engine, which must be added in a device descriptor structure. Here, there are some callbacks that the driver can provide. We have prepared the hardware to prepare the hardware when it becomes active. I'm preparing the hardware function to disable the hardware when there are no requests to do. And the do batch request callback we'll see later what this callback can be used for and I think that its name it says doll actually. Next structure is the crypto engine context as we see here, which must be added in the crypto transformation context. This has some crypto engine operation. We have a prepared request if the driver needs to do some preparation before handling the current request and undo it by setting a prepared request when finalizing one request. Drivers must provide a function to each request by setting do one request. So this last callback do one request is mandatory. In the next couple of slides, I'll show you how cam driver integrates with crypto engine framework. And from now on, we'll highlight the driver code with blue and orange will be used for crypto engine code. First, we'll talk about how the needed structure were declared and initialized, and then we'll go through the execution flow. So first, we add the crypto engine to driver's private data. Next, we call a crypto engine unlock init function to initialize and allocate the engine. After the initialization of crypto engine, we can start it by calling crypto engine start. If there are any problems or errors during queuing request, we can stop the engine by calling crypto engine stop or remove it with crypto engine exit as we have here in cam driver. The crypto engine exit function from the crypto engine API, first it calls the stop function and then removes it. Next, in order to be able to send request to crypto engine, we need to have a crypto engine context structure. This must be added as the first member of the transformation context. It must be the first member because crypto engine only manages a sync request. It cannot know the underlying request type and thus only has access to the transform structure. It is not possible to access the context using container of. In addition, the engine knows nothing about the transformation context structure from the driver. Therefore, the engine assumes and actually it requires the placement of the known member crypto engine at the beginning. Before transferring any request, we have to fill the crypto engine operation. We have to fill this crypto engine context by providing functions for prepare, unprepared request, and the do one request. As I mentioned, the last one is mandatory. In cam, we only register do one request. As you can see here, we have SKSI for do one request. The other prepare and unprepared requests are already implemented in the encrypt callbacks or finalized callbacks. This is the execution flow for a crypto request with crypto engine. When a driver receives a crypto request via encrypt callbacks, we have to transfer it to crypto engine, which adds it in the engine queue. Then crypto engine starts pumping requests by calling do one request callback from driver, which submits the request for execution to hardware accelerator. Now we wait for completion. When one request has finished encrypting or decrypting, the finalized done callback from driver is called. We call the finalized crypto finalized request function from the crypto engine API. In the next couple of slides, we'll go to this execution flow with cam driver samples on how to call the crypto engine API. We use as example SKSI for request and encrypt the encrypt callback. This is the SKSI for encrypt in cam case. We transfer the request to crypto engine by calling the crypto transfer SKSI for request to engine. This goes in crypto engine and calls the generic crypto transform request, which will enqueue the request in its queue. As we can see here, we have crypto enqueue request. Then the main execution loop starts in crypto engine. That is a crypto pump request here. A request is removed from crypto engine queue. We call here crypto dequeue request. This will call the do one request callback from the driver. This goes into the driver callback. We have in cam SKSI for do one request, which sends the request to hardware for execution. We call cam jump ring enqueue. When the request has finished its execution on hardware, the done callback SKSI for encrypt done is called in the driver. This will call the completion of the request from crypto engine. That means it will call crypto finalize SKSI for request and goes in the generic crypto engine finalized request, which marks the request as complete, as we can see here. Now, before talking about and explaining the improvements I added to crypto engine, let me tell you about some problems I found while exploring crypto engine. When trying to add backlogging support to cam, I've made the performance measurement on crypto engine. I realized that the framework is sending requests to hardware one by one. It uses a current request variable, which keeps the request in execution and is not sending a new one until this is made null on finalize. So crypto engine, it was serializing execution, even if the hardware has support for multiple requests. Also, as I mentioned, crypto engine accepts only a sync request. So any other non-API request that the hardware is capable of doing, like split key or RNG, these are some example from cam driver case. This cannot be sent via crypto engine. This will be still sent but directly to hardware. So there were cases when crypto engine sends a request for execution and from driver, a non-crypto API request was sent to hardware and the crypto engine request will return error, even if that request had the main backlog flag set. Also, the crypto engine queue size was hard-coded to 10 entries for regular requests. If the queue reached the 10 entries, the non- backlog request would drop, even if the hardware could execute them in case it has multiple entries than the crypto engine queue. For example, cam can execute up to 512 requests. For all these problems, I found the solutions. I added a retry mechanism to be able to equeue a request if the hardware cannot execute it at that specific moment. Using this retry mechanism, we can send multiple requests for execution. Actually, we can send requests until the hardware says it's full. In that case, when the hardware returns full, we stop and crypto engine will restart pumping requests when hardware becomes available, meaning when a finalized request has executed. Some hardware accelerator have support for executing multiple linked requests at once. I added support for this use case, but it's experimental. I couldn't test it. I don't have any hardware with the batch support. Also, the crypto engine queue size is not hard-coded anymore. It can be set when crypto engine structure is initialized. It can be set with a value based maybe on hardware capabilities. Now, this is the old execution flow of crypto engine, which was sequential. When a second request was transferred to crypto engine, it was enqueued. On the main loop, before sending it to hardware for execution, the previous request was checked. I recall the current queue variable I've mentioned before. If this request is still in progress, the second request is not sent to hardware anymore. The crypto engine exits and wait for the first request to finish. Now, this is the new execution flow of crypto engine. It sends requests to hardware for execution until the hardware queue is full. If the hardware has support for retry mechanism, the request is put back in front of the crypto engine queue to keep the order of request. If the hardware queue is full, we re-queue the request regardless of main backlog flag. For backwards compatibility, if the retry support is not available, the crypto engine will work as before. At the beginning, I showed you how to use crypto engine and how to integrate its API into a driver. Let's see what changes are necessary to use the new features. First, we need to use the new crypto engine unlock init and set function. This initializes crypto engine and also sets the crypto engine queue size, as we can see here. This is not hard-coded anymore in crypto engine. This can be set in the driver. As this example here, we set the crypto engine max queue length to a number based on the hardware capabilities based on the job ring entries. The new crypto unlock init and set function also sets the retry support variable. This was added for backwards compatibility. By default, the retry support is false and the crypto engine will work as before. We send requests to hardware one by one on crypto pump request and complete the request on crypto finalized request and so on. To support multiple requests in each driver, the retry support must be set on true as we have here in CAM. This will send requests to hardware until full. If we do our request, as we can see here, returns an error, the driver must not free the request, since this will be enqueued back into crypto engine queue. We call here crypto and queue request head. We put it in front of the queue to keep the order of request. When all drivers will support the new retry mechanism, I think we can remove this retry support variable. Before I commit in 2017, the crypto API was using busy return value to indicate both hard failure to submit a crypto operation to a hardware accelerator when the later was busy and the backlog mechanism was not enabled, as well as a notification that the operation was queued into a backlog when the backlog mechanism was enabled. Having the same return code indicates two very different conditions depending on a plaque was both error prone and required extra runtime check. Therefore, the return code used to indicate crypto request failed due to hardware being busy was changed to no space in crypto API. The same should be done in each driver. In CAM, here we return no space in case the hardware queue that is juggling is full. Now in crypto engine, if hardware queue is full, we return no space. The request is enqueued regardless of the made backlog plaque. If hardware throws any other error, like IO or INRAL, these are fatal errors it cannot be recovered from. In this case, the crypto engine exits. For example, in CAM driver, we use IO in case the job descriptor is broken, so there is no possibility to fix the job descriptor. This is a fatal error, so we shouldn't recue the request. If we do this, the request will just be passed back and forth between crypto engine and hardware. The new callback do batch request executes a batch of request as its name says. This has the crypto engine request as argument as we can see here for cases when more than one crypto engine is used. The crypto engine unlock init and set function initializes crypto engine but also sets the do batch request callback. On a crypto pump request, if do batch request callback is implemented in a driver, this will be executed. The link between the request will be done in driver if possible. Do batch request is available only if the hardware has support for multiple requests. We can see this here. As I previously mentioned, this is experimental and I didn't test it so far. Now, let's look on the performance results on crypto engine usage before and after using adding the new feature, the retry mechanism. Since my work with crypto engine started while adding support for backlogging in CAM, the first results are for the encrypt. I set up an encrypted partition with the encrypt setup for the encrypt and created files with different sizes on hyaluramic 6Q subreport. I used as you can see here the DD to create files. Maybe it's not the most precise tool for performance testing, although I used the F-data thing to be sure that the data is physically written to the file before finishing. We have here the speed in megabytes per second and on the X we have the file sizes, also in megabytes. Higher is better, so it's clearly the new crypto engine flow is better than the old one. We have here almost double the speed for small file sizes and here we have 60-70% increase for 4GB or 2GB of data. Next, I used the decrypt speed test. I wanted to have an internal test, no user space to here not space transition overhead. Decrypt is the crypto testing module intended for self-testing algorithm implementations. Here we have the result for AESCBC with 128 big key size run on the same hyaluramic 6Q subreport. The speed is in megabytes per second and here we have the chance of data sent for execution. As it can be seen, we have big, very big differences for small chunks of data. Here are like the 600-700% increase and for very big chunks of data we have a 50% increase here or 100% increase here for 4K. The same decrypt speed test, I've run on hyaluramics 8 which has a newer version of cam module than the hyaluramics 6. Here we also have better results with the new version of crypto engine. For small chunks of data we have 200-200% higher speed for small chunks of data and 10-20% increase for big chunks of data. Even though we have clearly better performance with the new crypto engine, we still need to further investigate why some performance results are not as expected. Why do we have such a big difference between targets? 50% gain on hyaluramics 6 and 7%, 10% gain on hyaluramics 8. Also, a big difference between chunks of data. We have 200% increase on 256 bytes of data and 10% increase for 16 kilobytes of data. Also, I believe we can still extend an enhanced crypto engine. We can add support or other than asking requests. As I've mentioned during this talk, there are drivers which has no crypto API requests like RNG in cam or a split key which are not accepted by a crypto engine right now. So the drivers need to have two paths, one to transfer the request to crypto engine and another one to submit the request directly to hardware. For performance increase, I believe we can try to remove some logs used now for all three major operations of crypto engine, transfer, submit request and finalize. But this I think will need more time to investigate and a total testing. To conclude this talk, I believe it's fair to say that the crypto engine is easy to use and the new feature add performance up to 500% higher speed for some use cases. Crypto engine is definitely the defect of queuing mechanisms for backlogging requests and not only. Crypto engine can be used in multiple applications if a driver wants to support this encryption or file system encryption for DM integrity checker of block devices and the list can go on. Also, Herbert, the crypto maintainer, the crypto subsystem maintainer said in one of his reviews that crypto engine is the queuing mechanism that any crypto driver can use to implement the queuing. That's all for me. Thank you. And if you have further questions, let me know.