Yeah, that'd be, that'd be quite a [LAUGH] quite a lecture. Yeah. Great. Okay. So thanks a lot. Today Dan Daily, who's a chip architect at Intel is, is here to talk to us a little bit about Flex Byte. So, thanks for joining us Dan. >> No problem. I wanted to ask first to start off, like what, what are the origins of the Flex Byte project, and what sort of, what, what demands were kind of driving this, this new chip set, were they requests from vendors or, operators, new applications, something else? When did this come about? >> Well, I think the flexibility was designed given the size of our team. We were, a startup at the time. And we had a lot of requests from different places, we didn't feel like we could, you know, build a chip that had the perfect pipeline for everybody. So we, took a lot of the different requests that we had and we built a pipeline that was flexible. So that we can evolve it over time and, that allowed us to kind of react to new protocols as they came up. Sort of, STM began, began to mature and new things kind of, kind of popped us and it was, kind of straight forward for us to go and take our pipeline and, and reprogram it to do the things that they needed. So, from that prospective it was, it was successful. We needed to be. we, we need to be flexible. [LAUGH] In order to, to handle this you know. This, this, you know, a lot of these changes that were happening in the network. And then we you put something in a. And even in sort of an established environments someone will come up with something new that they need. Or if it's an embedded device and they, there's some sort of tagging that's happening inside the system, it's really, it's really good to be able to you know, programmably parse. Any sort of packet. Programmably, modify the packet in, in arbitrary ways. Because you're essentially the glue between, you know, multiple endpoints. And so if you're, you just want to get out of the way and make sure all the pieces fit together. >> Yeah, that's, that's, that's cool. I guess it, so yeah, you saw a need for this I guess and then you sort wanted, you said you wanted to design a chip that was as flexible as you know, as flexible as you could possible make it or you know, given. >> Right. >> Given what you were seeing. I guess. That brings me to another question, it's just like, it sounds like you, you were just, you know, didn't know really what was out there and you just sort of, or you didn't know what was coming, I guess you could you could say and you just wanted to make it super flexible, but at some point you had to decide on some set of actions. So was there, where did you decide to draw the line or how did you, how did you basically come to the, come to the decisions on the sets of, of actions that you would put in your processor? >> Right. Well, we had a lot of experience from our previous design the, the Bolly, FM4000 chip. So we had a, truer baseline, understanding of, what people were doing with these chips. And so, we took that and Expanded on it. Understood some of the, the requests that we had, and and added a couple of things in for good measure, just to make sure that you know, we have that extra flexibility and head room. But If you think about just the primitives of what a chip has to do it's not that large of a set. There are some, curveballs like being able to do, IP check sounds and, putting the, the hash of a packet into the header like you end up needing for VXland, those are the types of things that You know, you kind of put in there understanding that maybe someone will want and then, you know, six months down the line something does pop up like VXland that needs both of those features and you're happy that you had them. So you know, I would say, the set of thing is, is not that large, you just have to be able to combine them in an arbitrary way. >> Yeah. That did, so when you saw, I mean you mentioned the VXland and and you also pointed out that it, it didn't exist when, when you first designed the chip. And did or, it, it sounds like in that case, you, you were you know, you, you made the, I guess, the right decisions. And that you were sort of. The sets of features that you, and actions that you had on the chip were, able to handle that that set of functions. >> Right. >> But are you seeing, now that there are things that you didn't anticipate? Such that like the, you know, what is the, the next version of Flex Byte going to look like? Do you think it's, going to include more things or, or maybe less things? Maybe, maybe it's more specific because you have a better idea of maybe things you didn't need, or, or do you think you left things out? >> Well I, I would say you know, I think there, as we evolve the architecture we really want to focus on, being able to, to scale and, this might just come from you know, a different perspective as being part of Intel but, you know, the, the ability to interconnect. Large numbers of processors is, is really important for us, and you know, we, sort of, have the, you know, a new type of, relationship with, you know, what's going on with that processor because of the, things that we're doing with, you know, software data plans. So it, it just gives us a little more perspective and, and, and we have a lot more of that information that we didn't have before [LAUGH] in terms of what are the types of things you want to do, and maybe we can be a little more, bit more focused. But you still want that flexibility, you still need to, you know, there's going to be innovations. You can't really. Predict, so it's, it's good to have that tool set. But you know being an interconnect for for research data center, that's really the focus. You have to really get that right. And then the flexibility is sort of you know, a feature on top of that. So, I think that's, that's that's how sort of, flex Byte will evolve, it's, it's a fairly complete set of, of of of actions and primitives and just take it on to the, to the, you know, the next generation after that. >> Yeah, you mentioned you mentioned software a little bit and sort of integration of software and I think that's kind of an interesting like discussion that's, that's circling around in various ways and, sort of, what functions belong in software,. versus, versus in hardware. And I wonder if you could talk just a little bit, just generally about that, I have some specific questions, but, but you know, you know, what types of things should be placed in, you know, on a host or on a server that's sitting in the network, versus on the switch itself? And so Intel obviously does, does both now, so, so, [LAUGH]. >> So what, what do you think about that? >> Well, I think, not just for Intel, but for everyone ideally, you'd want everything to be, totally flexible, totally programmable. Everything in software. So. >> Okay. >> You know, that's where the Nirvana. Is to put everything into a software pipeline and >> Do you think it's going to happen. I mean, do, do you think, You know, do, do you think that software, will eventually catch up if you will or, or do, so, do you think there's always going to be some kind of gap? >> Well, I, I mean, right now the gap is pretty large. So, you know, if you try to- >> So-. >> Do a, switch on, on one, on one processor, you know, it's, it's maze. Or there's a 92, depending on the type of software they use. But the processes are getting faster every, every year, and we're figuring out, better ways to distribute types of workloads on each processor, so you can combine them together in different ways. So I think, one of the obvious things that happened in SDN was sorted of evolved from, you know, starting on the hardware, this is how you this is how you Software and define a network, instead of having that run on ASIC it, it immediately jumped over to the host because, that's where he could do all this really interesting stuff. You didn't have to wait for the ASIC to catch, to catch up. So you know. Given that understanding, you, you have to, you have to go back to the network and say okay, well, you know this is going to happen. The, the, the hosts are getting smarter, we can move more and more of the network to the edge. You know, what is the role of the network at, at that point. Does it still need all of that flexibility that we. That we, wanted to have, does it's does it's role change, does it get marginalized completely? And that's the balance that you have to, they have to, you know, find out, and a lot of the different customers that we have are all on different ends of the spectrum, and they're all Intel, customers, so. >> Mm-hm. So, one possible way you might see that going is, is there's. There's, Really complex tagging. And, and manipulation processing at the, At the, At the end host, but then, the switches have relatively simple sets of operations that they do, based on, tags that exist on packets. Or, something like that. Is that? Kind of where you see, you see the things going. >> That's one possibility, yeah, there is still, a lot of value in the, the fabric. You still have to be able to, there's a lot of value in trying to engineer that fabric and, and, but, you know, there might be a lot of things that, That, certainly everything stateful is great to stay on the host and you're just sort of plumbing. You're just trying to get the packet in and out. You want to make sure that you know, you can avoid drops, avoid large latencies. You know, avoid misrouting. Avoid, avoid bottlenecks. You know, if you, if you look at sort of, the Flex Byte that we did today was very focused on, packet processing. Flexible parsing, flexible modification, and then sort of, the flexible type of control flow that you have in open flow with multiple tables. But there's this whole other world of, you have this fabric. You're, very focused on, on the quality of that fabric. How does it, how does it deal with congestion, you know, what is its latency characteristics, not just, low latency but, you know, worst case latency. These are the types of things that. You start to think about, once the once you have a, flexible forwarding and you can handle any sort of tag that's coming off the host, any sort of service tag that the host is using to, to do sequencing now you want to focus on, okay, I want to make a. A forwarding interconnect that, that the, that the host could sort of forget about, it's just always there. It's always just a, always an available connection that, you know, doesn't have a lot of pickups. >> Hm. Yeah now, that's, that's, that seems that seems definitely like one way, one way things could go with. I think another, another another question of course, was, was software as you could imagine the host. Doing things at the edge, tagging packets, just reading the network as sort of an intraconnect based on the these tags as you said. And another place for hosts is like in the network itself, right? So another thing that kind of didn't really exist, you know, when, when Flex Byte started is, you know, as you noticed, is, is things like service chaining, right? So you could imagine boxes sitting in the middle of the network in addition to. You know, you know, the end host doing tagging and other things at the edge so What kind of role do you see? Like what kind of splits do you see in the network itself? Like in terms of, where are these boxes going to sit? Are they you know, you could you, could imagine them, you know, being all over the place. Like you know, one at every switch location across the network. What you know. What's going to, what, what, how do you see the, the whole placement of, of software switches or software middle boxes if you will going? >> Well, I think, certainly if I was building a network, I wouldn't want to, have to, decide where my box has to sit. I'd kind of of want to just, let some other guy, let some other person decide where the boxes need to be placed, and how they need to be wired, that's based on their physical, locality. And I'd like to, virtually, you know, if I need this frame to go through, box A, box A, box C. I'd want to do that in software, and that's where the service change is coming from. And that's going to, that's going to, potentially break up some of these specialized boxes that were requiring you to. Part push packets through them specially, and, [SOUND] be able to control that virtually. And I see that to being really compelling. so, it's very likely, that you know, people will have their way. That's, that's what people want. They just want, their, their hardware to, to look very. uniform. And, you know, I do like to get rid of these boxes. Because, the, the box problem is, once you have, you know, one box, and you need, one extra flow more than that box can support, you're stuck. Now you gotta buy another box. You gotta rewire everything and, this is what the, this is what NFE is, is, is promising. Or [UNKNOWN] is promising is, that we can sort of. Smooth out that, that clipper's curve, of, how much, you know, middle box logic do I need. If I can just do it all virtually, and use the same hardware for no box that I'd, use with my application, then that's a big win. >> Yeah, no, I see like a, a really nice kind of a, substrate there where you know, basically as you, as you put it the cut, everything is uniform if you will and you don't as a, as a network designer and operator, you don't have to worry about what box that is, because they all kind of do similar things and then if you run out of space just drop another one in. Is that. Is that kind of the, the real idea? >> Yeah, I think that's the Nirvana, yeah, if you can keep everything uniform then it doesn't, it doesn't really matter, what function, you know, you just buy box, you just buy servers, and you know, you, you, you're work load will determine how many servers you need to to get your job done, so. Yeah >> How far away are we, from that? I mean. On the one hand, there's like a ton of, of legacy-deployed equipment. On the other hand, like certain kinds of networks have those short upgrade cycles or, relatively short. So, do you think we'll ever be, in this Nirvana, both in terms of. I mean, one is like, do you think we're, we're getting closer in terms of design, or? You know, that's one is how closer are we in terms of design and the other is like, logistically or you know, deployment wise do you think will ever get there. >> I think some people already there. [LAUGH] I, I think some of the big, the big guys who have, you know, money to spend and they are, are motivated too. Make, make their. You know. Make their operations very low cost you know, they need this type of function. I'm not going to go out and buy, middle boxes, so it's how do you make that more broadly available. And I think that the, the middle box vendors, Have seen this as well, and they're, they're, they're trying to evolve towards it. because they have a lot of value in that box. And, historically they've just been wrapping their value in metal, but value is still in the box, and there's no reason why that couldn't move to a. You know, a, a software environment. But for them, it sort of what do you lose from leaving the box? And that's again where the fabric might come into play. If the fabric can provide some of the, some of the, value that you had in a control system. And you can get that same type of value in a. In, in a standard network you know? Again, that's, that's another place where, you know? There's, there's, there's innovation to be had, right, right? You might just understand a network, but, if that network can give, That, Middle box function, some of the functionality that it had, when it was a controlled system, that's, that's. That's a big deal. >> That's interesting you might see a lot of these as you put like these companies that are, that are selling thing that are wrapped in metal just become pure softwares companies or something like that right, like here's the software and it could be dropped on any, any one of these uniform boxes as Matt said, that might be one direction you think. >> Yeah, yeah. This is, is possible. It's kind of hard, as a, you know. Sometimes it's, it's a, you know, just, if your a hardware company, selling software is hard. [LAUGH]. >> Hardware company. So but yeah, that's the challenging hand. It started as. If you feel it's inevitable then, you have to go do it, so keep going. >> Yeah, you, you referenced sort of, you know, being a hardware company, but also Intel has these other interesting projects like Raprix for example, which is like if you're. You know, I guess you might say, it's pure software router in the sense that it's a cluster of servers that will do to, high speed forwarding and then you've got complete programmability in some sense. because all of your, decisions are being made in software. How do you see system like RouteBricks, fitting into the network, you know. Particularly with respect to, you know, with the, it's [UNKNOWN] chip set out there. You see that they're going to be. Switches, with the Flex Byte chips, and then some RouteBricks routers in there, do you think, I mean how do you see that playing out? >> Yeah. I think the RouteBricks, application is just one example of what you can do, you know, in a software data plan. And you know, RouteBricks uses a tool that we call the DPDK. It's a data plan developers kit. And, what that allows you to do is, is take your, software data plan and accelerate it, using, you know, using the, the I.A. instructions underneath. And so, you can, move your packets in and out of that box a lot faster, if you use DPDK, rather than if you just used, you know, standard Linux kernel. and, and these types of applications. You know, routing is one thing that you can do but it's one of the simplest things that people want to do on these software platforms on these, on these server based platforms. So this development kit really, you know, accelerates that work. Whatever your, like go back to those hardware vendors, whatever their value add is, they don't really, you know, they don't want to spend a lot of time. Optimizing the packets in and out. They can, they can, leverage what Intel has done, and just focus on their application. And so, RouteBricks is, is, Is our way to experiment, and understand the requirements of that type of system. But we have, a lot of customers doing, you know, very similar things. But they, they, they have a pipeline that's much more complicated than, than just scalable routing. And scalable routing, don't get me wrong, is. It's also, you know, a hard nut to crack, but there's a lot of applications that you can do on these server-based platforms. >> That's, that's really interesting actually. That clears up a lot of things because you could sort of been just a view RouteBricks as a. Demonstration application of what can be done on a server based platform at high speeds. >> Right. Right. You can think of it like that and certainly if you took RouteBricks and like combined it with like spite that would be another great demonstration, of how you can, integrate something happening on the server with, something that's happening in the fabric and, and let them work together you know, and trade off their, their, their very different strengths, you know? >> Yeah, that's, that's really interesting. So on one, one sense you've got servers with this DP, DPDK architecture running in the host, and then you've got, switches with Flex Byte in the network. And, there's some, I guess some relationship between the two which I seems, is like do you see specific things where you know, one could take advantage of the other, or vice versa? >> Hm. Yeah, I think so. I think, you know, ASICS have their place. [LAUGH] But the focus is, is how, how do we make that, how do we make that. Intel architecture server platform, the best platform for doing doing forwarding, inside the network and, and how to take, network functions and, and put them on that, on that platform. That's really the focus but we think that the, that having, fabric be a part of that. You know, gives you a special advantage. You know, if you, if you, if you can, again, we have a special development kit just to get the packets in and out of that server. And so, we want to be able to, focus on that IO. And, and, and have, you know, making, make sure the IO isn't the problem. The, the, the bottleneck should be in the compu, in the function that you're trying to. That we're all valueless. >> I want to tell you, I wanted to dive into just a little bit to, to the design of Flex Byte itself. I mean, I asked a couple questions in the beginning like how you decided the set of actions and so forth, but also what about layout? But you know, you, you had particular decisions that you needed to make when, when, laying out the processing pipeline and so forth that, ask some more specific questions about that in a minute. >> Mm-hm. >> But, you know, for example like a protocol that requires matching of two fields, it could be implemented as two tables in sequence. Right, each matching on a single field or it could be, implemented as a single table containing both fields and you could do some kind of cross products there so, that would be like one example where you have to make a layout, kind of decision but is that something that you faced and what other kinds of layout decisions did you need to make when designing the architecture? >> Well, I think that one thing, we tried to focus on in the P4 paper was the the control flow, of the matching, right? To understand the logic that the the application is going through when you're trying to, process this packet. So, you know. You could think of, you know, you know, maybe that the logic of the application is going to, do one look up, come to some, result, and then want to use that same result, you know, farther down the line in some other process, that might of been created by some other application. And having that sort of. Serialized operation in your pipeline is, is, is sometimes really useful. Because you know, it would be nice to be able to, segment some of these functions, in a single pipeline. So that, one application can be programming one table and another application can be programming on the other table. Don't necessarily need to be, synced together. and, and that I think is, is really useful but we, what we also, determine in the P4 paper is that, you don't necessarily have to have hardware matched out exactly, so if you, determine that in your application you need two tables. But your, hardware only has one table. Something that, you know, something like an open an open V switch would do, is just take that Cartesian product of the two tables, flatten them. And so you, luckily you can always, you know, you can always stick something into a really, really big, flat table but it's not very efficient. And so. From our standpoint we wanted to make sure that, that you could, break up these tables in the same pipeline without having to flatten them, without having to make you know, large expansions of the table set just, just because you know, you couldn't do that, that serialized lookup. >> Mm-hm. You know, you mentioned P4, just, just briefly. And I wanted to ask, like, one question about that. >> Mm-hm. >> I mean, it seems like. >> Mm-hm. >> There's a, there's a, you know? That's a language that would basically allow you to, kind of, like, define, some properties of, of, of the underlying target, hardware, in terms of layouts of tables, and, and pipelines and so forth. What kind of factor. Like, presumably, that's a language. And then you'd need some sort of compiler that would. You know, consider various constraints of the underlying target, and, and, and make decisions. I mean, what do you, what do you think the compiler, is going to most need to consider? You know, going from a high level language, describing the layouts to the actual, describing the functions to the actual layout. I mean, is it power, area, latency, some kind of combination of these things? Is that something that, that the designer or programmer is going to have to, to specify or you think there's, there's some sort of general, set of axioms they have to define. >> Yeah, it's unclear. It just depends on the hardware, you know, our hardware it is sort of. there, there really isn't a, a power latency trade-off that you have when you use new features. So it's, it's, you know, it's you know, very efficient in that way, and it's very deterministic in terms of its behavior. But other designs might not be that way. They, they might, you know, if you turn on one feature, it may, completely change the, behavior of that, of that device. That's going to be a challenge for, compilers, you know. It's sort of I, I was running great and then I. I added this new, function that called this, you know, special action and now I've lost, a bunch of performance or it's, it's the box is running really hot or there's such a thing. It's going to be challenging for compilers, so I, I can't imagine, I would imagine that a lot of the early compilers for this type of language might come from the. From the vendor themselves? Say, here is, you know, you know, here is a, sort of a, something that's been put out there in the, community and this is how I match to that compiler and, and this is sort of how. You know, you can use it, but ideally, you know, ideally there would be an open source compiler, that would just, be able to handle a lot of different hardwares. And that's the certainly, from my perspective that, that's sort of Nirvana, but initially there's so much, knowledge that you need to know about the system. That you know, it sort of has to come from, from us. But it, it sort of influences our process too. So, once these compilers exist, you'll start making less trade-offs that are hard for the compiler to, to rock. You know, if it's, you know. You know, maybe I won't make that hardware, you know, trade-off in the future. Because I know that's going to cause the, the, the compiler all sorts of, of headaches. And it's going to be hard to express into the, high level of extraction. So, I think it does, it will definitely impact our, you know, our future devices, if, this type of, of things sort of would emerge. >> Mm-hm. You, actually. Another thing that. Before we, kind of, chat a little bit more about Flex Byte, I wanted to ask you. You mentioned. >> Yeah. >> A little bit of the design of Flex Byte was, was. Someone is, or. I'm sorry. A little bit of the design that your layout, decisions are somewhat, Motivated by. Things that you were thinking about when did P4, which kind of led me to think, In what? In what sense does the, language drive the hardware design, and in what sense does the hardware drive the language design? Is, is there sort of a co design going on there, like how does, how do you think that in to play works? >> Well, I think when we designed Flex Byte, there was no P4. But we need to hurry up, we have a sort of overarching, goal, that we wanted the pipeline to be very deterministic. >> Right. >> So we didn't want, because it was so flexible, we didn't want you to go, and enable some feature. That you know, that was part of the hard spec, but then have the hardware behave really differently. We wanted the latency to be consistent, we wanted the, performance to be consistent, you know, power, all of that should be, the same so that you sort of felt free to program it the way, that you needed. That's our architecture and a different architecture, if you, if you don't have that, then it's very hard for the compiler, basically the compiler will say I can't turn that feature on because I can't, predict how this box is going to behave when I have it on and so. That's where I think the, the compiler really influences things. Where you may in your future designs say you know what, I, the compiler wants this, people are using this feature the, the compiler exposes it. I better make sure that it's, that it's performance and. That it's, it's not, it's not an exception case. Now that's where I think the, that's where the loop, comes in. Because when you're, designing this hardware, inevitably you come up and say, well, you know, either this didn't work the way I thought or, it's going to just take too long for me to. Do this right, so. Do I? Do I do it, not exactly the way that I like? And, you know? You think you'll think that. You'll take a harder look at that, when you know that, eventually, this feature will be exposed in a compiler, and can be used in a lot of different ways. Right. >> Mm-hm. Mm-hm. Yeah, it seems like, it seems like there are a lot of sort of interesting open questions there, and sort of design of whatever this compiler, eventually becomes. [LAUGH] >> If, If when yeah. [LAUGH]. >> Yeah, yeah, I mean who, where do you think, I guess that;s, you mentioned if right, so what do you think the, what do you think the compiler is going to come from, do you think that's a. Are those you know, is that an industry question? Is that, is that something that researchers should be working on? If, if, if the latter, what do you think of the, the hard problems there? I mean, you mentioned [UNKNOWN] already, but. >> Yeah, no. I. >> Do you think that there's some that, in particular, that researchers should focus on? >> Yeah, I think it's, I think it's a really interesting research problem to, see if you can make a compiler that could work on lots of different hardwares, and could, you know, maybe focus on the kind of the least common denominator. And be able to take well, sort of, what will be cool in P4 is be able to take the intention, of the application or the programmer of the network, take that, that stated intent and put it into hardware. And you know, you, you're not always going to be, successful in getting it all in there. And so how do you report that back? And say, well, you know, I got your program in there. But, you know, when you go over this number of rules, or when, you do this particular operation, it's going to have this performance. And, you know, wha, all you're really doing is trying to replicate, the environment that you have on the host. Right? On the host, it will always compile, it will always run, it just might not run very fast. And this, did, the new, I guess, challenge that you have on the switch. Is that, that variance in speed is, can be really big, [LAUGH]. >> Mm-hm [LAUGH]. >> So, that's the challenge. Maybe the, maybe the answer is just move everything into, new software, like we said in Nirvana, just, everything should just be software. And, you know, maybe the network shouldn't be, programmable, that's one answer, but, you know. Having a compiler that, that can do, this type of thing, on a network device is. Would, would be. Would be really interesting. >> Mm-hm. Do you think, I guess, one more question about the compiler. Do you think that, that the right answer is, like, oh, it always runs, but, sometimes, it might just run super slowly? Or? Do you think the answer might be, oop, sorry, can't do it? Like, you know, com, compile failed, try again. [LAUGH]. >> Almost like a, you know, compile, a compile time fail. >> Right. I think you should always run. You, you, you >> Uh-huh. >> What happens on a host should always run. >> Right. It might run, it might run super slow or if you know, if you have hosts nearby it might just go run on the host somewhere, so it's very easy for the ASIC say I can't do this so I am going to go and send it somewhere else. so you know, I actually think that this compiler would have to take that into account and, and and look at it more of a, a system level. And say, well, I can't do this but I might have some other pipeline or, some other method to, to get it done. And you know, maybe for a live applications that's acceptable and you're, you're sort of. Standard forwarding is very high performance, but there's some, exception cases. There's some control point functions that you'd happily run, as slow as you can, but you want to use the same interface that you did, for the you know, for the, for the, for the bread and butter data path, so. It would be, really nice if the programmer could just say, this is what I want. This is a description of my system. This is how I want you to forward it, and you know. Tell me. Tell me pieces might, might, might run slow and I either don't care or I'll use that information to, you know, better improve my, my program in the future. >> Mm-hm. You mentioned, like with the compiler, the, the, the holy grail or something with a Nirvana. [LAUGH]. >> As you say, would be, you know, compiling to multiple target architectures. I imagine Flex Byte would obviously be one of them. But what other. What other chip, chip architectures that are out there, you know, compiler designers, you know, should they, should they appear you know, what, what should they be, considering? >> Well they should always consider X86 [LAUGH] [LAUGH]. >> And >> Of course. >> And maybe that's what they should start, you know, you know. >> Right. >> You could imagine. Well let's take a complier, that runs X86 and, if I could maybe take parts of that function and push it on to a, a different pipeline that's. Flex Byte, that might be one approach to the compiler or you could flip it around and take it the other direction and say I want to start, with a compiler that fit focused on, a particular, pipeline like the logical architecture we had in P4 and then the things that don't fit, I will put into a generic. X86, pipeline that's, those are certainly two ways you could do it but I, I think you sort of have to, incorporate somewhere a software data plan. And and we sort of see that in scores with SDN's and SDN sort of looked at the. You know, the, the, the market in general looked at all the data plans and said, you know what? For me to, add my value and to, for my startup to make lots of money, I need to have, ultimate flexibility. So a lot of that landed on, on, on these switches. >> Mm-hm. What about, eh, there's some other, I guess, chipset architectures that's being developed as well, like, like this ROT architecture. >> Mm-hm. >> I was, I was wondering if you could sort of compare and contrast Flex Byte to RMT a little bit. Like, what are, what do you think the major differences are between those two, those two chip designs, you know, in, in, in, actually, I guess, maybe this isn't the question for you but why do you think that Flex Byte already, been already existed? Do you think there's a need for both of these, like what are their major differences, do you think they are complimentary, do you think, you know, what's, what's the way to land here? >> I, I think they're really similar. I, I mean, I think that RMT was inspired by Flex Byte in some respects. >> Hm. >> At least as an existence group. And I'm sure that they'll argue that. But they both have. Programmable parsing, very similar programmable parsing functions, they both have programmable, modifications, you know, they, they both are sort of, flexible in terms of how you match, whether it's Tcam or logs prefix, or exact match. yeah, the, the main difference I would say is that You know, the flex Byte was designed for that determinism. We wanted to have, the, the pipeline behave exactly the same, every time, even down to latency. so, that means that a lot of our computation happens in parallel, so that, you can, you know, do a bunch of matches all at the same time and then gather results and then, use that for your. For your forwarding. Well, RMT is much more serial. And it's certainly a trade-off in terms of you know, serial has a lot more power. I just mentioned that, example before where you might want to have one table come up with the, result. And then the, the the result of, that table Jimmy looked up in the next table. And so I would say that RMT Flex Byte is a bit more parallel, but they have a lot of similarities, and I think that They're similar enough, that if you had to go and make a, compiler that, could do both, I mean, they're probably two chipsets, that, that are probably a good example, because they are similar enough without being exactly the same. >> Hm, I see, yeah so those might be two, two targets to consider as well for, for a compiler, designer. I, yeah. What do you think are the major differences that result from the decision? You mention, RMT being, more serial Flex Byte being a little more parallel, do you think there are performance implications here or you know, other implications for the programmer? What, what do you think the upshot is, with the differences here? >> Its really the difference between serial and parallel just mean differences that control flow, so if if you have a, a lot of parallel functions, you know, a function for POS you know, a function for forwarding, function for monitoring a function for security. All four of those can run in parallel but if you have to serialized them you know, that, that might have a performance implication. But if you have a function that is going to look at a tag and create some meta data, then look at the meta data and, and look at another part of the frame, and then create some more meta data for a later. You know, ACL or, or flow match, that can be very powerful to this realization. So, I think, you know, what we end up doing is just sort of influencing other, you know, later, later, Flex Byte, might be more serial and, and later, RMTs might, might have less of a, you know, a much more deterministic. performance. That's most likely I think the result but you know, if I was writing a compiler, it'd be, fairly straightforward to you know, switch between the two, because they both have it's really that the The, the lowest common denominator between the two is pretty large. And it's that programmable parsing, that is a big deal. It, they're both kind of protocol independent. >> Mm-hm. They're not, they're not required to only match on, sort of, the, the two [UNKNOWN] that's defined in an early open flow spec. >> Mm-hm. So yeah, so, I mean, you mentioned that, you mentioned in the programmable packet part so as kind of being the, being the, it seems like there are a lot of these chip these chips that kind of have that, flavor where you can, you can sort of match an arbitrary. Portions of the, of the packet. You know, getting it to the packet header and so forth. Are there, are there things that are sort of, specific to Flex Byte? There is as far as the, the programmable parser, or you know, things you mentioned that MRT was kind of inspired by, by Flex Byte, but are there differences between the parsers that are note worthy, or you think they're close enough? >> I think they're pretty close. There are other, there are other parsers that are very, very fixed. -. >> Mm-hm. >> And that's where the, the big difference comes, you know, so, yeah, they're, they're, they're pretty similar, in that they're sort of, kind of state machine based. You know, you can look at some of the bytes, you make some decision, and, and you, you roll forward in the, in the, In the header to figure out what your next function is. So, from that stand point, they're pretty similar. >> Oh, cool. >> I want to just close with maybe, I don't know if it's controversial but, but certainly coming back to the hardware software question a little bit [LAUGH]. >> You know, and maybe just You know, talking a little bit about middle of the road, right? So there's certainly, on one hand, there's servers and, and DPDK and, and X86 and on the other hand there's, there's you know, Flex Byte and switches and so forth. And somewhere in the middle, maybe, there's, there's programmable hardware like FPGAs and things like that. >> Mm-hm. >> I mean certain switch vendors. Are known to shift like cards with that PGA [UNKNOWN] for experimental purposes you know, to test things out before the, you know, in between development cycles. I'm wondering, do you see a role for, for prog, this kind of programmable hardware in the network at all or you know, is it just, all one, one side or the other? No, I definitely do. Especially at the, edge of the network. clos, close to the X86, if you had a FPGA sort of hanging off the processor or, or maybe, a FPGA hanging off a switch that was also, connected to a processor. You know, there's a lot of interesting things that you can do, at that, at that edge it, no, we, we run into FPGAs all the time. it's, it's an interesting place to, it's a, it's a great playground, and it gives you that, that trade-off between, it, it's a much better trade-off between flexibility and performance. So, I think there's absolutely a place for that, and to the point where, you know. You asked about what's a good platform for these compilers. You know, if your compiler, if your compiler had, sort of, the generic X86 forwarding pipeline and could take advantage of some FPGA that would also be a really interesting combination. >> Interesting. So you think, there is maybe a place forwarding production, not just a, you know, sort of in development circumstance or - >> Yeah, yeah absolutely. And the, there are definitely customers, in production that FPGAs, in, in you know, sort of in that, in that realm that I just described. So you know, you're, not as cost sensitive certainly as a big data center but you know, there's, when, when there's a certain performance. Metric that absolutely counts, let's say latency, >> Yeah. >> That PGA is, is, is a good, is a good tool. >> Cool. Well, thanks. This has been really exciting, really, really, interesting for me as well. So, thanks a lot for your time. >> Your welcome. >> I hope, the students in the, in the course also get a lot out of it too. We're going to be, covering your architecture in the course as well, so it'll be a lot of fun to get. I mean, it'll be, be very useful to have your perspective. So, it's great. Thanks a lot. >> Great. Thanks a lot. Thank you. >> Yeah. Thanks. [BLANK_AUDIO]
