We're here at CBS 2016 in Nairobi, Kenya and I'm very pleased to be joined by Cornelius Wafula, who is lead developer for Easy Prep. Cornelius, thank you very much for being with us today. Thank you for inviting me. Now you're here representing Easy Prep, it's been selected here as one of a number of young innovators, innovating projects here that have technological solutions for socio-economic development. I wanted to ask you about Easy Prep and your project, perhaps you can give us a little bit of a pitch on that. Well, first of all, I appreciate being invited to showcase our products to this event. For us, we have a product called Easy Prep. Easy Prep is more like a virtual education platform where students get to interact with their content virtually rather than having the hard copies, the books and all that. So the platform is internet-based at the moment. So the users will require maybe a device, computer, laptop, tablet, mobile phone to access the content. And the good thing about Easy Prep is that the content is structured specifically for the student's needs. So if a student is taking a specific curriculum and he's at a certain stage of his education, the content delivered to him by default is based on that, based on the curriculum they're taking, the level of education they are at the moment, by default. So unless he wants to look for other more content from different areas and other curriculums, he can conduct a search in the platform and get the content delivered to him. And is it early days for you at the moment or are you quite far in your development process? Yeah, the development process is I can say roughly 90% complete. We are looking forward to having a soft launch early next year in January so that we can get some users on board, actual users who will probably interact with the system, give us a few feedbacks here and there, and probably can polish up on areas that might need some improvement. But at the moment it's currently under test. We have testers, some in Ghana, some here in Kenya, and during the process of uploading some content, during the test processors the testers interact with it. We are getting some positive feedback on which we are improving on it. And what is your USP? Yeah, okay. I can say innovators around the education platform, there have been quite many from way back. But our selling point mostly is how the content is structured for the user. Because most of these other platforms, they just bombard the user with the content. And students being students, the larger the quantity, the lower the motivation. So we are just trying to deliver the content in small bits, in areas where the student needs. Like on the platform, a user maybe wants to access content for science, he can maybe search for the subject science, which specific topic he wants to access, and the content will be delivered in subtopic forms. So if he is not introduced in this subtopic, he can jump on to the next subtopic and interact with it, go through the content. Yeah, so there are also other key features that are selling point, because we also have sample questions, test questions from the content, from the lesson content that the students have been reading through. We have timed tests, these are intended to improve the student timing ability, because it mimics a real exam. Because in a real exam, if it's two hours, it's two hours and two hours are over, the teacher is picking up the papers. So with time testing the platform, the student can do it a number of times and test his ability to be punctual with the test. We also have tokens during the test taking process. If a student successfully gets a question right, he's added tokens. These tokens are useful because on the platform we have also games for entertainment purposes because all work and no play makes Jack and Al boy. And these tokens are used to unlock the games for the student. So this encourages the student to be excellent in the tests. We also have social features, study groups. Students can create study groups virtually with other students and maybe have a discussion online, share content with others. So it's not specifically wired to academics. It's more like a whole school system transferred to a virtual world. It sounds very complete and the road to success is never an easy one but we wish you the very best of luck and thanks for being with us in the studio today. Thank you for inviting me as well. We're looking forward to getting more users on board and probably launch it in also schools so that the schools will also get their students to take up the product and use it more frequently. Thank you.


Elon Musk's takeover of Twitter has been very enlightening because not only did we learn for those that didn't know yet that he's not a genius, but we're also learning that he is a terrible tyrannical boss. As the Washington Post reports, Elon Musk issued an ultimatum to Twitter employees Wednesday morning, commit to the new hardcore Twitter, or leave the company with severance pay. Twitter is shifting to an engineer-driven operation, one that will need to be extremely hardcore going forward according to the midnight email which was obtained by the Washington Post. Employees were asked to click an icon and respond by Thursday if they wanted to stay. This will mean working long hours at high intensity, he said, only exceptional performance will constitute a passing grade. Now this is the email in full for anyone interested in reading the whole thing and as you can see, there is indeed a form and employees have to click yes if they want to remain at the company, otherwise they will be sent packing automatically. So it seems like a very healthy work environment where your boss sends you an email at midnight and says, hey, click yes on this, otherwise you're done. I mean, wow. Now apparently sources for the Washington Post say that there is a mass resignation being planned by Twitter's trust and safety team who is responsible for moderating hateful content and they are very important if Elon Musk wants to win back advertisers who are concerned about Twitter devolving into a cesspool and it's already a cesspool when it comes to impersonation thanks to his new Twitter blue verification program that he had to pause by the way, but in the event hate proliferates on the platform even more, advertisers just aren't going to come back.  He's also going after employees who criticize him publicly. So he tweeted this out on Sunday. By the way, I'd like to apologize for Twitter being super slow in many countries. App is doing greater than 1000 poorly batched RPCs just to render a home timeline. Now one of Twitter's engineers, Eric Frohnhofer, actually responded to that saying, I have spent about six years working on Twitter for Android and can say this is wrong. Now Elon Musk responded to that saying Twitter is super slow on Android. What have you done to fix that now that engineer responded with a bunch of tweets using technical jargon that none of us are going to understand. And ultimately Elon Musk decided to fire him announcing it on Twitter for everyone to see essentially publicly humiliating his own employee. Now look, I understand that it was very brave of that engineer to tell Elon Musk, who is a megalomaniac, he's wrong, because that wasn't going to go over well. But still you shouldn't get fired for simply correcting something that your new boss says, right? This is an engineer who's worked with the company for a lot of years. So for him to be fired by Elon Musk, because Elon Musk was embarrassed and corrected, is just sad. But it's par for the course for a gigantic man, baby, with a very, very huge ego and thin skin like Elon Musk. And apparently anyone who criticizes him is out like that. The New York Times explains Mr. Musk's team was asked to comb through messages in Twitter's internal chat platform and make a list of employees who were insubordinate. People briefed on the plan said they also sorted through employees tweets looking for criticism. Those deemed rule breakers received emails around 1 30 a.m. Pacific time on Tuesday, notifying them that they were fired according to emails viewed by the Times. Several Twitter employees who shared news of Mr. Frohnhofer's firing and internal chats were cut, said six people familiar with events. They were told that they had been terminated for violating company policy according to email seen by the Times. So violating company policy now presumably includes criticizing Elon Musk. Now, look, I understand that if you go out of your way to antagonize your boss, you're putting yourself in a bad predicament, which is why I think that we need unions because this employer employee relationship is very exploitative in nature. So sometimes bosses are wrong and they need a pushback. But if you have a boss like Elon Musk, who's incredibly just narcissistic and thin skinned and can't take even a shred of criticism, then it's going to lead to you getting fired. That doesn't necessarily mean that you shouldn't push back. And after news broke that he's firing employees who criticize them, this is how he responded. I would like to apologize for firing these geniuses. Their immense talent will no doubt be of great use elsewhere. Now, he also made fun of another employee who challenged his ineptitude publicly, but then got fired, saying she had a tragic case of adult onset Tourette's. And let me just remind you here, he's responding to Libs of TikTok. This is a hate account whose lies led to literal bomb threats against the Boston Children's Hospital. But Elon Musk is here chumming it up with this hate account. And he's doing so while making fun of his own former employee. I mean, to say that he lacks professionalism would be the understatement of the century.  And I can say that because I'm not one of Twitter's employees, but I am a user of Twitter. So maybe he'll penalize me in some way. But just seeing the ways in which he has bungled this to see the comparisons between the Trump White House and how he's running Twitter is hilarious to me. I said this once, I'll say it again. I sound like a broken record at this point. He has made Twitter a lot more entertaining. I will give you that because essentially everyone on the platform is shitting on him, but I've got to say I feel really horrible for the employees at Twitter and they must unionize if they want to survive his reign of terror. But if there's any hint of unionization, then he's going to fire them because Elon Musk has a history of being a union buster at Tesla.  Yes, these geniuses can go and their talent can be used elsewhere. Like who does things like that? He's not even acting like an adult. He's just acting like a teenager. If you gave Twitter to a random teenager who's like 15 years old, I'd argue that they'd probably be more capable and competent at overseeing Twitter's day to day operations than Elon Musk. That's how bad he is at his job. And again, he overpaid for Twitter. So now he's desperate to make it profitable because he wants to recoup that losses. And it's just the whole situation is sad. So honestly, to this point, if anyone still simps for Elon Musk, and there are many Elon Musk simps, but if you still simp for Elon Musk, I just got to ask, why? I mean, don't you have better heroes on their different icons you can, I don't know, look up to? Why do you simp for anyone, first of all, but to have Elon Musk be the individual who you simp for?  But either way, he'll still have his simps and Twitter will still continue to be run into the ground and we'll just all have to watch and try to be entertained by it as it happens. So, yeah.


Live from San Francisco, it's theCUBE, covering Google Cloud Next 19, brought to you by Google Cloud and its ecosystem partners. Welcome back everyone, live here in San Francisco at Moscone, this is theCUBE's live coverage of Google Next 2019, hashtag Google Next 19, I'm John Furrier with Stu Miniman, as well as Dave Vellante who's been co-hosting, he's out there getting stories and getting all the scoop. We're here with two great guests, Cube alumni's, which are glad to have a partner seen a group product manager at Google, and Hen Goldberg, director of engineering at Google, both the architects of the big wave that we're riding, containers, Kubernetes, and Anthos, guys, great to see you, thanks for coming on again. Thanks for having us, great to be here. So we're, you were smirking last night when we saw each other at the press gathering, knowing what was coming, watch the keynote, I watched the keynote, it was awesome, I didn't get a chance to see the spotlight session you guys just had, but Anthos, also the rebranding and the additional integration points for making things run end to end, this is our dream come true, DevOps, infrastructure as code is happening. We've been talking about this for a while, you guys are behind it all, give us the update. Yeah, so we've been hard at work over the last eight months since our last next, can you believe that it's only been eight months? Yes. And last year we were here announcing GKE on-prem, this year we've rebranded CSP to Anthos, and enlarged it, and we've moved it to GA. So that's the big announcement, in our spotlight we actually walked through all the pieces and gave three live demos, as well as had two customers on stage, and really the big difference in the eight months is while we're moving to GA now we've been working throughout this time with a set of customers. We saw unprecedented demand for what we announced last year, and we've had that privilege of working with customers to build a product, which is what's unique really. And so we had two of those folks up on stage talking about the transformation that Anthos is creating in their companies. Well I'm going to get to the customer focus a little bit later, but I want to just get it out on the record while you're here, because there's not a lot of time on stage other than the great demo Jennifer Lynn did. What actually is the difference? What's the new things? Because obviously it's a rebrand. Some people might say oh they're just rebranding the announcement from last year. What were the new things? What are the new elements of Anthos? Why is it important? What does it mean? Under the covers, tell us what's new. Yes, so first of all let's talk about what is Anthos. So Anthos is a Google opinion-managed solution that lets you write once, deploy anywhere. And really the key thing about Anthos is choice. What we've been hearing from our customers, how much they appreciate choice in their journey to the cloud and modernization in general. So the main thing that we've announced is that everything we've announced last year is GA. We're talking about GKE on-prem and Anthos now. Anthos config management and our marketplace and the control plane for managing multiple clusters. All of that has moved to GA. But when thinking about choice, we've added new capabilities. And one choice that customers are thinking about, do I need to choose a single cloud provider? And now we had a discussion just yesterday with one of the customers and they said when they exclude a cloud provider from their strategy, they're actually blocking their own innovation and that might create even a bigger risk for them. So we know that customers are adopting a multi-cloud strategy. So the big announcement here is that we are moving towards or maybe we are even leaning more into multi-cloud. We already had other solution that we're talking about and definitely with Kubernetes and Istio talking about open APIs, but we are leaning in towards multi-cloud strategy. So that would be one. The second thing that talks about choice is how do we start, okay? And one thing we are hearing from our customers is the importance that they want to innovate with what they have. So Anthos Migrate lets them take their existing applications, package applications that are running today on VMs and onboard to Anthos automatically and see value. So those are the top two announcements and I think the third one would be around all the partnerships, which is part of the people we've been working with for the last 18 or 18 months. I'm sorry, the Migrate piece, that's not GA yet. Is that my understanding? No, no, it's moving to beta. It's moving to beta this quarter. So Istio, you and I have been talking about applications, Renaissance, multi-cloud, obviously is a reality for enterprises, and now you got the hybrid model. This is kind of in the main themes of what this all means with Anthom. So it's holistically looking at the cloud, as you said, not just Google Cloud. This is a key nuance. It's kind of embedded in the announcement, but it's not just Google Cloud. That's right, and I think in that sense, Anthos is a game changer. It's not just an incremental improvement to something that's existing for customers. It's not like it's just something faster or cheaper or adds more features. It's actually something that allows them to do something they couldn't do before, which is have a consistent platform that they can use to write once and deploy their workloads anywhere. On-prem, in GCP, and that we had, but expanding that to any cloud, not just Google Cloud. I want to give you guys thoughts here because you got the brain trust inside Google Cloud, because I've been talking on theCUBE about this and publicly, there seems to be confusion around what multi-cloud means. So a company is an enterprise. There's a lot of things going on in the enterprise. So certainly the enterprise will have multiple workloads. So there's certain situations that some people say, hey, this workload would be great on this cloud. This workload would be great on that cloud. So it's not about having a cloud for cloud's sake. Oh, we got to standardize on Google. We got to standardize on Amazon. Instead, what I hear and I want to get your thoughts and reaction to is, I'd like to have a workload that has data, highly addressable, really low latency for this workload and a cloud for this workload, but together it's multi-cloud. This seems to be a trend. Do you guys agree with that? Is that something that you're seeing? Is that the main message here? Is that it's not so much standardize on the cloud, but have multiple clouds pick the right cloud for the job kind of philosophy? What's your thoughts? This is kind of a philosophical question. So this is exactly what we are hearing from our customers about their multi-cloud strategy. And exactly what you're saying. So this is actually, for most of them, is a reality, either because they've been organically building things in the cloud or they want to get to multiple geographies. And it's not only a cloud vendor. We need to remember that on-prem, is where most of their workloads are still running and where they still need to innovate. Or when you talk about retail or banks, they have their branches and the stores where they need to have computer at. So really services are spread all over. Now the question is, this kind of situation creates a lot of risk for our customers. Security risk and talent fragmentation, which are related. So how can I manage all of those environments? The risk is multi-cloud or one cloud? So multi-cloud actually increases the risk. Even further. So they already have a multi-cloud reality. Okay, that's their strategy forward. But how can they mitigate risk with that reality? And we are talking about Kubernetes gave you portability of workloads, but how can you do portability of skills? And making sure that your talent can really focus where it matters and not be spread too thin. So this is one example that I think Anthos is really unique about using it from our hosted control plan on GCP. So let the workloads decide what's best for the workloads and let the clouds naturally use Kubernetes. Yeah. So I mean, one thing I've seen in our customer base is the line of business wants to innovate. And they want to use the best service for whatever it is that they're doing. And the different clouds have different types of services. They have different strengths. So you don't want centralized IT to say, hey, no, actually you can't do that. You have to follow this policy. We've seen many examples where centralized IT is taking months to approve cloud services. And they've got a backlog of hundreds of services that they need to approve. That's really slowing down innovation. And why is that happening? Because you don't have a consistent platform that you can run and use across clouds. Like you said, Kubernetes actually solves that. And so that's why we're introducing Anthos based on Kubernetes so that you don't have that risk. You don't have that fragmentation. And I hold on to one more question. And I think what compounds the complexity is old procurement rules might slow it down. I got to buy this. And so the old baggage on procurement standards, it's kind of a moving train. Right, right. Yeah, I mean, your enterprise has its policies. I mean, we've been talking to some of the largest banks. We had HSBC on stage with us. We had LaBla, which is one of the largest grocers. We have Coles. These companies have policies and they have compliance requirements and these are very valid compliance requirements. And they need to be adhered to. It's just how can you speed that process up? And if you have a platform that actually spans environments, doesn't look different in each environment, you can imagine that that simplifies the process. Right, it simplifies the approval process because the platform's already pre-approved. And then new services as they come online, if they follow a certain pattern, right, there are Kubernetes approved services, then it's much easier to approve them and it's much easier to unlock that productivity without increasing risk. Okay, if I could poke on that just a little bit, Kubernetes approved services isn't a term I've heard yet. When I look at, you know, there are dozens of providers out there that have Kubernetes. Yes. Anthos I know is different, but if I go out there and use Kubernetes from a different cloud provider or a different service provider, you know, Kubernetes is not a magic layer. Everybody builds lots of stuff on top of that. And a concern is if I just have a platform that spans all of these environments, there's skillset challenges and do I also get a least combat denominator? It's cloud is not a utility. GCP is very different from the other cloud. So how do I balance that? And how do I make sure that I'm, you know, actually being able to get the most out of why I choose a specific platform or cloud? Right, so that's where Anthos is that layer that actually is more than Kubernetes. We have in Anthos an opinionated platform from Google that utilizes Kubernetes, but it isn't just pure Kubernetes as you would experience it, say from the open source with the fragmentation. We're working with certified Kubernetes distributions and we've got this marketplace where the applications that are in the marketplace have been tested and certified and are supported by a set of partners as well as by Google cloud to run on these different distributions that you connect and register with Anthos. But to give maybe another perspective for that, what we have seen with Kubernetes is that customers do appreciate that consistency. Right, they've been demanding for example that all Kubernetes distribution will be conformant and you know we had an announcement with VMware on stage today about consistency and how we can integrate PKS into Anthos. Right, so I think what customers are telling us that they really appreciate, they don't want us to innovate in that layer, right? So they appreciate us using open APIs and using sensibility which is predefined and actually allows that interoperability of services. And this is something that's really in the foundation of Anthos. Well you guys done a great job. We've been following the progress from day one and watching the foundation of Google Enterprise grow.  Congratulations to your work. It's great to see the progress and it seems to be getting the trains moving faster on the tracks. So congratulations. I guess my final question for you guys is, boil down Anthos to the folks watching that are in IT. They're trying to solve some problems. Like again, a lot of people realize and wake up, well I got multiple clouds. And that's not anecdotal, that's reality. They see billing statements from multiple vendors. They still want maybe hybrid. What does Anthos mean to those people? What is it about, what is it? Like I mean, I'm trying to get bumper stickery. What's the bottom line? What is Anthos? So Anthos gives you choice without the risk. That's the bottom. That means that they can choose an existing service or a new greenfield service to use on-prem or in the cloud, containerized or uncontainerized. And they can build on top of that at their own pace. So that's the choice. And they can mitigate risk by giving those tools to manage that consistently. And the other thing I would say for something that we are not talking a lot about because we are focusing about technology and requirements and constraints, is what we hear about our customers that Anthos is good for the engineering teams. And what we hear our customers say that because they are choosing this technology, their talent is appreciating that that they can use the best and latest technology and their skills are portable to other areas as well and they can attract the best talent. So that to me is a very big value for those that are looking to do digital transformation. Okay, I'll take a crack at it as well. So Anthos is Google's opinionated solution for hybrid and multi-cloud. And it is like Hans said, something that mitigates risk and gives users choice so that they're not locked into a particular cloud and instead they can build once and deploy anywhere. From a technical standpoint, it's three things. There's a multi-cluster, multi-cloud management plane that's hosted in Google Cloud.  And then number three, we have an awesome marketplace from which you can deploy Google services, you can also deploy partner services and you can deploy them into anywhere that Anthos is registered and can run. So Anthos embraces the cloud. All clouds, all services. It does. Anthos embraces the user and it puts the user first. And business benefits, good choice, lock-in options, negotiating contracts. A thousand flowers bloom, right? Cellophers love it, ops going to love it. That seems to be the three areas. Guys, congratulations. Thanks for the insight. Love the explanation of Anthos. Thanks for sharing. Appreciate it. Thank you to partner Hen. Thanks for coming on. Cube coverage, here live in San Francisco. We're breaking it down. Google next 19, day one of three days of live Cube coverage. We have all the thought leaders of Google executives, all the engineers coming on to explain to us what's happening. Thanks for watching. Stay with us for more after this short break.


So people have been teasing me the last couple of days about how do you spell fizzar or phyar or whatever we're calling it. So Matthew, which was your preferred embodiment? It was your name? So this spelling. OK, so I got it right this time. I think I made up the fizzar by accident at one point. OK, so this has been kind of a percolating issue for quite a while. We have some hacky solutions to some of these problems in some of the places in the kernel. This is an effort to kind of give us a solid footing where we have solutions to these problems that we can actually build on and make the world better instead of abusing Scatterlist. And Scatterlist has been the bane of a lot of these sort of things. So Matthew kicked this off with the number one here. He was interested in speeding up user pages, right? If you've got 1 gig or 2 meg or whatever, you still fragment them into 4K and return them in a linear array. And that's just awful. Really, really is. I'm interested in number two. I would like something called peer-to-peer DMA to work you. Steven Bates talked about this on Monday. And his version of it uses struck pages. And there's another version of this that we're very interested in, especially for VFIO that just uses raw PFNs. And we had a little side panel on the mailing list about this. And it basically turns out, VFIO runs in so many environments that you're not going to get struck pages for it. Because it's not going to work on S390. It's not going to work on RISC 5. It's so far away. So we need a non-struck page solution for that. But number two is just PFNs. It's the struck pages. No metadata. It's the struck pages. It's a problem. No, but I mean, the solution you're going for is just PFNs or are you looking for a little bit of it? There will have to be some metadata, I think, because that's the way the DMA API works. The DMA API needs a little bit of metadata to know where the page originates so that it can compute the correct PCI offset when it does mapping on strange embedded ARM platforms. Don't ask. We are not going to go into that. It's an issue. We need a little bit of data. And you can see the data already in the struck page environment, because when you create the pgmap for P2P DMA pages, that little bit of data is in there. And then number three, this was talked about by Keith. This is, I would like to make the block API run faster, because I've got this silly thing where I take a BIO and then I just mem copy it slowly to a scatter list after allocating the scatter list. And then I allocate, then I do a map, and then I get the same numbers back and it's all kind of dumb. And in RDMA land, we have these crazy users that would like to pin memory quite a lot, like hundreds of gigabytes. And that's their application. They pin 100 gigabytes of memory, and they do IO to it forever. So currently, we store all this in a scatter list. And we use 28 bytes per chunk. And you waste a healthy amount of memory in your system just keeping track of the stuff so that I can unmap it and then unpin it. It's kind of useless. And this is so far down the list here, but the IOMMU driver interface under the DMA API is just horrible. It's really slow. Every single page, it walks the page tables and then carefully inserts it, and then it goes to the next continuous one and it walks the page tables again and inserts it. So that could be improved too. Yeah, Matthew. If I can channel Kristoff and add number six, cleanliness, Kristoff really, really hates it that we have the scatter, oh. I've got a whole slide about that. So one of the challenges in this area has been the scatter list. Kristoff really hates the scatter list. I think we all hate the scatter list. But the problem with the scatter list is that it's everywhere. It's absolutely everywhere. And every leaky abstraction that it has has been abused and misused some place. It's just being used wrong and what you do with that. I know Logan tried to tackle some of this in a very narrow, and it was hopeless, there's just too many drivers. So any hope of doing something better in scatter list is gone, I think. I think it's a write off. I don't think anybody wants to see that. I'm bringing this up mostly to kind of share this, but yeah, scatter list is what we've had and if you're not familiar with scatter list, this is kind of weirdly designed for the future that we live in. Scatter list was based on this idea that you would allocate a linear bit of memory and you would have some goofy arm or something that had a gart and it might translate only the pages that were above 32 bits because you were running on old hardware that didn't support 64 bit addressing. So you'd have a mismatch of translated and untranslated addresses. But we don't live that in that world anymore. After you do a DMA map, you either get the CPU addresses you passed in, maybe plus an offset or you get a single chunk of linear IOVA. So we do not need all this complicated stuff of having like every pages in general. We need it in special cases still, but in the fast path, like in keys fast path, we don't need this stuff. Like you can get away without it. So you can optimize towards the fast path where you can say my DMA map is the same as my CPU addresses where my DMA map is described by 16 bytes. So we can significantly reduce the amount of memory, the amount of cache lines we dirty, everything. We can do a lot better. So I got into this because I wanted to do something with VFIO. I've been working on VFIO for a while. I replaced the management of the IOMMU with something else and in the process, I removed the VFIO support for peer-to-peer DMA that had been hacked in and had a kind of a security issue. So I took it out because I didn't want to put the security issue back in. And now I would like to bring it back and I want to, what I want to do is create a DMA buff that is the handle for your peer-to-peer memory that doesn't have truck pages. I would like to pass that to the IOMMU stuff and I would like to put in the IOMMU and hold the reference count so I don't have a security problem. And currently DMA buff is designed around scatter lists. So I did the obvious thing that DRM has done and I did what DRM did and Kristoff didn't approve. So we're going to try and make an improvement to the DMA API that will allow us to do all these things. I had some time with the DMA API maintainer earlier today and maybe we have some agreement of what it will look like and it's probably not going to be quite like this but this is kind of the big picture here. So you have these new concepts where you do something without a scatter list. You DMA map this new thing, you'd go in and you get back a DMA list and we can introduce the optimizations I talked about where we can optimize for IOMMUs where you only have the 16 bytes of storage and you can optimize for identity. You can make peer-to-peer work. Peer-to-peer doesn't really work today unless you have to start pages which is kind of an annoying hassle. And from there then we can talk about maybe we can use the same structures, maybe the same API we can put in pin user pages, maybe we can return folios from there. Like it's kind of an adventure. And as I started looking at this I realized that the possibility of doing this in like a one-shot conversion is basically nil. There's too much code, there's too much entanglement check into scatter list. Like even RDMA, I can do most of RDMA in one shot. But somebody added DMA buffs to RDMA. That might have been me. And so then I have to convert DMA buff as well and that's too big. Like I can't do all that at once. So I want to see this kind of incremental world where we can still take a scatter list from DMA buff. I can feed it into an API adapter and I can use it in a new world after I convert RDMA. And then I'll go on and fix DMA buff. But I can't do it all at once. So my idea has been to create effectively a non-leaky API for iteration over these concepts. So you can iterate over your CPU pages, you can iterate over your physical page, your physical PFNs, you can iterate over your DMA buff. And under that non-leaky abstraction, I will hide the details. And we will make it so that one of those things is you can iterate over a scatter list. So I can take in a scatter list and I can feed it to new code and then I can fix it. Piece by piece, slowly, slowly, slowly. So it's a little bit different because scatter list was micro-optimized to be like minimal number of CPU instructions everywhere. And this is the opposite. We have made an API which is really solid that we can put behind the scenes what we want, but you're gonna pay a penalty. You're gonna do more branches, you're gonna do more function calls to get there. So, yes, it would be- More instructions per range, fewer instructions per page, right? Yes. Well, this becomes into the interesting question. So a lot of the users at the hardware level, once you get these things, you need to program hardware. And there's two popular ways to program hardware. You're either programming range lists, like SGL is typically called, or an SGE or something, or you're programming page lists. And I think something like NVME has both and something like RDMA has both. So if you're programming a page list, you need to take your range, you need to break it up into pages and you need to iterate over, maybe my hardware only does 4K pages, so I have to break it up. So in RDMA, we've already built abstractions and APIs to do this, and part of what I drafted is I took those and I put them in a common code so anybody could use them and you can take your ranges and it breaks it up into 4K or 8K or whatever you want. And it just gives you what your hardware asks for. You tell it what the hardware wants and it gives it to you. Like, yeah, saves lots of code. So when I started working on this, I'm like, this doesn't sound too bad. And I started at the logical point because the DMA API is kind of the line. To do anything useful, the DMA API demands a scatter list. So to do, if I wanna do something else, I need to get the DMA API to do something different. And this is where I got quickly an education in why this is so fricking hard. So we have 23 of these DMA API implementations called DMA mapping ops, DMA map ops. And that's a lot. And they all implement, right now, they all implement weird old fashioned IOMMUs, often guards, often weird things. And they've all been kind of micro-optimized for their weird little architectures in their time period that they were written for. So I really don't wanna touch them. In the modern world, we're encouraging everyone to use the IOMMU layer and something called DMAIOMMU.C, which is like the common code for operating an IOMMU. So you either have identity mode, which is common code, or you have this common IOMMU code. And that covers all the modern, cool hardware, except for PowerPC and some ARM32 stuff, which hopefully can be fixed. Oh, and S390, which has been fixed. It just needs to be merged. So we're doing pretty good. But there's gonna be some kind of problem with the DMA API. And my sort of feeling is we're leaning towards getting to being able to do number three on this list. So number three is we convert the modern world. ARM32, S390, I don't know about PowerPC. It would be nice to convert PowerPC, but I don't know about PowerPC. And then we just provide some backwards compatibility for the old stuff. It'll still work. It'll be very slow, but it'll still work. And we don't try and do number four with the scream face there, which would be trying to add this to everything everywhere perfectly. Damn, I was hoping to ship you the contents of my basement. I don't want your basement, Matthew. I don't have room for your basement. So I don't wanna touch these old architectures. I think they're fine the way they are and they're never gonna run RDMA or NVME anyway. So why do we need to fix them? Okay, so this seems, does anybody disagree? Okay, that's a consensus. I'm moving on. Now the other challenge that I've been looking at, so that was the DMA API. I think we got some ideas how to get there. The other side is the gup side. And gup today is used in so many different places and some of them are really performance critical, like feud exes. We wanna do a page walk for a feud ex and we wanna do that really fast. How do I make it return something different than a page list? I wanted to call a function call to append it to my abstract API that I built. I wanna go append this chunk that I've read from the page table and something else will deal with it. So what are we comfortable with here? Are we comfortable with adding some slowness to gup to do this in direction? Maybe some static branches. Maybe some indirect branches. I don't know.  We need lists. Realistically, we need lists, right? Like the use case that everybody has is they wanna get a chunk of user VA and they wanna get a list of what that is. If it's two make folios or a couple two make folios and a 4K folio, they want the list. So my reading of this is that we need to, we do have two different users, two different kinds of users. You're right, we have the feud ex case and I haven't really been thinking too hard about the feud ex case. But I think the feud ex case can be get user page. Yeah, Lorenzo's work has been moving, I think, in that direction nicely where we will have like a get user page that's really good for that. And then the other use case is basically get user range where you want physical addresses for this array of, for this range of, you want a vector of physical ranges. So you have a physical start and you have a length and you have two pulls of that. Yes, I think that's likely the case. It's a little bit complicated because in various places in all of this, we do sometimes need to know if the struct page is there. And we do need to pull information out of the struct page. As counterintuitive as that is, the DMA API actually pulls information out of the struct page when it's working, which is annoying, but that's how it's been built. I mean, we can convert back from physical to struct page. If you know that the struct page is there. Right, and so then you have to handle the cases when it's not, but today that fails, right? That's an E fault. If you call get user page and there is no struct page, you get an E fault. Right, but what I'm looking at is like the whole picture. I would like to go with a kind of a similar language, a similar API from get user pages through DMA map to hardware, and I would like to solve the pace where get user pages always returns folios. I would like to solve the DMA buff case where I don't always get folios. I get PFNs as well, so you want a range and you want a bit that says this is a struct page memory, this is not a struct page memory. That's like the generalization of that concept. And then even further, to be really efficient, what you want is like here's my handle for my non-struct page memory that tells me where it came from, what it's for, how do I DMA map it, which is that other little piece. Now we could still use one bit and we could use like an interval tree or something to get back to the handle by looking at the PFNs, it just depends how efficient you want this to be. It doesn't really matter, I think, for my use cases anyway. So, but the few dexes and things like that, like how do we structure gup that everybody's happy? Like if we have a single, if we have a gup get single page, you would still have to substantially duplicate all of gup to do all the page table walks, all the fast stuff, all the slow stuff. Is that what we want to do? Like we already have a couple copies of gup in the tree. We have the pagewalk.c, we have gup, we have a couple places where just open codes, like you can see it sometimes like PMD, PGD, there are a lot of them. Do we want to do something here? I know Matthew had talked about making like a page table iterator thingy at one point and I thought that was neat and terrifying. Who said no? No, that's too bad. Just do it and call it something else Matthew says, okay. Jason, one question, like you mentioned that you want something that doesn't have a struct page or like return something, but how would you actually like protect that it's not going away or getting reused or is that another concern? I mean, if you have a page, you can like pin it, you increase the restaurant and whatsoever, but how would that be handled? This is what the DMA buff is for. So the DMA buff is the handle that protects the memory and when I ask the DMA buff to give me a list of the memory that's held inside of it, I promise not to let go of the DMA buff until I also let go of that list. So it moves the reference count from being like a per PFN thing to like a per file thing effectively because the DMA buff is a file. It would be like ref counting pages if you ref counted the VMA, which we don't do in the MN, but we can do this for these special cases. Okay, and the other question I have is, I think right now we disallow, get user pages when we have a PFN map. We do think. And I... Would you have to change that or does it not apply? Because otherwise you always have like a struck page, you can do your ordinary PFN to page and your PFN to folio, et cetera. I don't propose to change gup at all. I think gup should stay where you always get struck pages back because there's no other way to get an object and hold a reference counter. At least it's very hard. I mean, maybe we could... It's hard. I've thought about it. It's kind of hard. What I want, I want some pages to come from gup and I want some pages to come from DMA buff is what would be nice.  I'm just gonna get a DMA buff. I'll stash it away. I'll hold a ref count. Then I'll get the pages out of it and I'll append them to my list so I can handle like mixed maps and other weird things. And places that care about this, and I think there's really only one place that would want something so complicated and that is VFIO. They can do this extra work. I don't need to put it in the core code. So couldn't you like implement that, that you have like your new fancy function and it calls old style, get user pages and if that phase whatsoever and then you just convert from whatever like array of pages you had or folios ideally or whatever we're able to come up with internally just convert that to your new representation that you don't have to duplicate each and every gup function just to handle both types. Well, it's not duplicating a gup function. When you go to get the pages out of the DMA buff it gets them from somewhere else. Yeah, right, but I mean it's like it's just like one part of the implementation if I get it right.  Well, in a lot of cases the DMA buff things are passed in by file descriptor.  You already have a file descriptor. The only kind of wonky case is historically VFIO has used VMA as the handle for these things. So for compatibility it would be very nice to be able to go from a VMA to get the DMA buff file descriptor and then just do the DMA buff special stuff as though you had passed the file descriptor and I think that's good enough. I don't know that we need to go deeper into that rat hole with gup. Gup is already kind of difficult. So I'm more for leaving it the same. Yeah, just on the structure of gup.c or whatever it occurs to me that you wanna put on your new API, put it in there and then just opportunistically factor stuff out. And I think one of the big opportunities is the page table walker because I don't care what you call it. That's what the duplication is. Yeah, it's all right. But I don't think you should call it gup v2 exactly. It's more like you've got this additional thing, it's get fizzer pages or whatever.  So there's kind of two approaches I thought about. One, we could kind of do that. We could put if statements like if new gup mode then call a function, old gup mode, append the array and then maybe you factor and stuff. And gup v2 would be kind of like I take gup.c and I compile it twice maybe. If we really, really cared about performance, we could pull a stunt like that. So then the fast version is fast because it doesn't change and the slow version is slow. But then you've got two copies of the thing. It's not appealing. It depends how much we care about the Feudex case and other really performance sensitive cases. But I thought your new thing was for users that understand the new thing. Like why do you care about old users calling the old thing? Well because we have about a thousand lines of page walking code in gup that is exactly the same for the old thing and the new thing. And the old thing is people care about performance a lot. So how do I do that? How do I think of a thousand lines of code and just I just need to change it a little bit. Little tiny changes without affecting substantially the performance. Inject a BPF thing. I'm moving on now. So I think I already kind of talked about these pieces in the other slides. But yeah, I've kind of realized that even for NVME, they have page lists. It would be really helpful to be able to have the segmentation approach that RDMA's got. I know DRM has the same issue. I see this in other places. And DMA buff gets kind of fixed. So this is a distillation of keys, or yeah, key slides. So today it goes through this adventure. What I've been sketching is we take the BIO and we can convert it into, like I said, like an adapter for an iterator. And then we can feed it through the new API. What Kristoff has sort of proposed is that we change the way we view the DMA ops to be more modern. And instead of having the DMA ops actually process like a BIO or something, we expose more of the underworkings. And we say the DMA ops are more like you allocate an IOVA space and you map something in the IOVA space like the IOMMU lets you do. And then we let NVME deal with the BIO and use these primitives so it can be super efficient. So it's sort of decomposing the problem. It's moving the code we have to just different places. I think it could work out. It needs a little work in the IOMMU to factor it, but that's OK. But I think the kind of the general dream is you get to a world where you could take the BIO.  When I look at this from a reusability perspective, especially if you don't care about micro-optimizing what was it, 12 million IOPS per core, then you probably want some helpers. You probably want something like StatterList where you can just stick stuff in it. You can call a function and then you get something out of it and you can make your simple driver that way. So I have been sketching this RList kind of API that is that. It lets you have lists of CPU stuff. It lets you have lists of DMA stuff. That was one of the cardinal sins of ScatterList is that it didn't have the type safety. So let's put the type safety in. And it gives you a set of helpers to work with in your respective worlds that are useful for drivers and things. So I'll negotiate with Kristoff. He seems quite interested. So that's the end of what I had prepared for slides. Oh, I'm right on time. Feedback, I've posted a couple things about this and there's been devastating silence. So sorry. Oh, that's in general. Yeah, I didn't understand it. No, I understand it better. So I can ask some comments. Actually, no, yeah. It sounds the same like the, or actually question like the ScatterList is still going to, like if this is useful for the new world order, like the ScatterList needs to be like, is that just for completeness or like you really see the need to go back and rewrite all the ScatterList users? No, I don't want to do that. Good Lord, no. I mean, it's like Matthew's x-ray conversion, right? It should be super cool if people could use the same new easy to use API. And that would be great, but realistically, it's even worse in x-ray. It's even worse in radix tree. There's a 10 times the users of radix tree. So it's. Also, so your ScatterList conversion is more about like people that want to do it the ScatterList way, but do it in a type safe new way. Like it's for new ScatterList users? Yeah, yeah, new ScatterList users. So yeah, you're sorry. Yeah, so there'd be a new API that you could use if you wanted to. And my thinking, again, is sort of based around this very abstracted iteration thing. And you could put ScatterList inside it. So when I'm doing conversions, I can do them piecemeal. I can say, this part of the world is still ScatterList. EMABuff is still ScatterList. This new part is the new API. And I can bridge them, at least for this time, for this kernel release. And I can remove the bridge in the next kernel release. And I can do things incrementally, because even the sketch I've got so far is like 20,000 lines or something. It's completely nuts. I need it to be smaller. I can't get that merged in that form. So when I was looking at this, and I probably overlooked something major that you can just explain to people I overlooked, I was thinking that we would just leave ScatterList the hell alone, introduce the fire, fire to ScatterList conversions, and then once every single user of SG underscore page and SG underscore was, we could actually remove that from the ScatterList. And then drivers would just be unconversed and be able to, you know, we just shrunk the ScatterList. What did I get wrong? What did I miss? That you could ever do that, right? Like, there are so many SG to page callers all over the place. I swear there were like five when I looked. Oh, maybe I'm thinking of the SG page? SG underscore page, yeah. No. I missed something there. Oh, OK. OK, I see. So the ScatterList is two things, right? It's a list of CPU things and a list of DMA things. And they're sort of inseparable. They become unified at the DMA API level. So a lot of places, there's not that many. A lot of places, oh, I have to stop. But a lot of places, the subsystem creates a ScatterList for you and feeds it into a driver. So the subsystem does the SG page bit. And then the driver gets it pre-populated. But the driver is still mucking about with it.  Oh, well, thank you.


When you look at the Christian God, it's like they say no sex, no drugs, no f***ing this and that.  It sounds like Satan's like he's like popping off down there.   But Jesus came to this earth to take the punishment that we deserve, take all that wrath of God that was supposed to be placed on us. It was now placed on Jesus when he died on the cross, so we can be free. We can be exonerated from all that punishment and guilt and shame and live eternally with God.   It's going to be where you experience the full consequences of the pain of sin, trust in Jesus and escape the wrath to come.