Snabb: fast software networking made simple
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 94 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/45658 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FrOSCon 201919 / 94
7
10
12
14
15
16
17
20
22
23
26
27
28
29
30
31
32
33
36
37
38
39
41
44
45
48
52
53
55
56
57
58
60
61
62
64
66
67
74
76
77
78
79
81
83
84
93
00:00
Computer networkSoftwareFreewareOpen sourceMathematical optimizationInformation technology consultingHacker (term)Communications protocolSoftwareOpen sourceHacker (term)Communications protocolMultiplication signNumberProjective planeGoodness of fitSoftware development kitUniformer RaumXMLComputer animationLecture/Conference
00:57
Scalable Coherent InterfaceAsynchronous Transfer ModeProxy serverKernel (computing)SoftwareComputer networkComputer programServer (computing)Generic programmingCartesian coordinate systemAsynchronous Transfer ModeSoftwareSpacetimeProxy serverKernel (computing)Server (computing)Generic programmingFocus (optics)Musical ensembleLecture/ConferenceComputer animation
01:30
Server (computing)Open sourceBuildingSoftwareIterationCodeComputer programTranslation (relic)ForestOffice suiteOpen sourcePower (physics)Computer hardwareWritingSoftwareCartesian coordinate systemComputerFood energyWeb applicationLecture/ConferenceComputer animation
02:47
Web pageMemory managementBefehlsprozessorProcess capability indexPlane (geometry)Kernel (computing)Proxy serverDatenpfadSoftwareCycle (graph theory)Kernel (computing)SoftwareIterationSoftware engineeringProgramming languageSpacetimePublic domainProcess capability indexStack (abstract data type)Multiplication signComputer programMereologyCartesian coordinate systemProcess (computing)Hand fanLecture/ConferenceComputer animation
03:57
Kernel (computing)Read-only memoryMemory managementResource allocationBuffer solutionLoop (music)DatenpfadSoftwareWeb pageProcess capability indexoutputSemiconductor memoryKernel (computing)Lecture/ConferenceComputer animation
05:00
Kernel (computing)Read-only memoryMemory managementResource allocationBuffer solutionLoop (music)DatenpfadPointer (computer programming)Loop (music)Queue (abstract data type)Ring (mathematics)Semiconductor memoryGame theoryComputer animation
05:32
Context awarenessLoop (music)LogicProgramming languageSoftwareBit rateContext awarenessCartesian coordinate systemDevice driverLogicStreaming mediaProgramming languageLoop (music)Multiplication signCache (computing)Computer animation
06:08
Context awarenessLoop (music)LogicProgramming languageSoftwareParallel computingCore dumpFrequencyBefehlsprozessorWorkloadProcess capability indexBand matrixBefehlsprozessorCountingCore dumpMultiplication signComputer programLimit (category theory)Frequency2 (number)Process (computing)Computer animation
06:54
Sampling (music)Cursor (computers)Loop (music)BefehlsprozessorProcess (computing)CASE <Informatik>SoftwareServer (computing)Function (mathematics)Category of beingProof theoryDirection (geometry)Overhead (computing)Structural loadWeightComputer programSurvival analysisElectric generatorComputer animationLecture/Conference
08:02
Router (computing)Internet service providerComputer networkVideoconferencingCartesian coordinate systemProduct (business)Link (knot theory)FamilyTranslation (relic)ÜbertragungsfunktionAddress spaceGradientIn-System-ProgrammierungSoftwareMoving averageSoftware developerRoboticsCASE <Informatik>Computer animation
08:40
Server (computing)Computer networkScripting languageMathematical analysisSoftwareScripting languageInternet service providerInternetworkingDivergenceBitContent delivery networkServer (computing)Computer animation
09:19
EncryptionControl flowLink (knot theory)VideoconferencingBit rateIPSecGateway (telecommunications)Real-time operating systemMathematical analysisScripting languageInformation securityCase moddingCASE <Informatik>SoftwareLink (knot theory)Projective planeMessage passingSlide rulePOKEVery-high-bit-rate digital subscriber lineEncryptionLecture/ConferenceMeeting/InterviewComputer animation
10:34
Open sourceSoftwareComputer hardwareServer (computing)Traffic reportingOpen sourceServer (computing)Information technology consultingNumberDiagramMobile appDifferent (Kate Ryan album)MereologyWeightTheoryCartesian coordinate systemComputer animation
11:14
Link (knot theory)Mobile appoutputComputer programTerm (mathematics)Component-based software engineeringNumberProcess (computing)Cartesian coordinate systemDifferent (Kate Ryan album)Universe (mathematics)Direction (geometry)Line (geometry)
11:52
Mobile appoutputFunction (mathematics)Configuration spaceLocal ringMobile appFunction (mathematics)Interface (computing)SoftwarePRINCE2Firewall (computing)Musical ensembleInstance (computer science)Cartesian coordinate systemCodeDiagramLecture/ConferenceComputer animation
12:48
Mobile appoutputFunction (mathematics)Configuration spaceConfiguration spaceMusical ensembleINTEGRALSoftwareMobile appProcess capability indexDevice driverOrder (biology)Interface (computing)Parameter (computer programming)Network topologyInstance (computer science)Firewall (computing)Address spaceCode
14:07
Diaphragm (optics)PressureVolumeGroup actionMobile appGraph (mathematics)Taylor seriesStapeldateiIterationLoop (music)Process (computing)Computer programComputer animation
14:42
Mobile appInstance (computer science)Computer networkInstance (computer science)Parameter (computer programming)Mobile app1 (number)Configuration spaceCartesian coordinate systemSoftwareMusical ensembleComputer animation
15:29
Local ringMobile appRule of inferenceFirewall (computing)Function (mathematics)Link (knot theory)outputDigital filterDrop (liquid)Firewall (computing)CodeMobile appSymbol tableCartesian coordinate systemConfiguration spaceFunction (mathematics)outputMeta elementObject-oriented programmingInstance (computer science)Rule of inferenceSystem callSet (mathematics)Array data structureTable (information)Social classLecture/ConferenceComputer animation
16:31
Link (knot theory)outputLocal ringFunction (mathematics)Drop (liquid)Mobile appFunction (mathematics)outputLink (knot theory)TransmissionskoeffizientComputer animation
17:04
Local ringFunction (mathematics)Mobile appLink (knot theory)Computer networkLink (knot theory)Operator (mathematics)InternetworkingCartesian coordinate systemDevice driverStapeldateiMobile appFunction (mathematics)NumberOrder (biology)Right angleComputer animation
17:53
Mobile appLink (knot theory)Programming languageLink (knot theory)Mobile appCartesian coordinate systemCodeWritingComplete metric spaceComputer animation
18:30
CompilerJust-in-Time-CompilerLevel (video gaming)Server (computing)ComputerProjective planeDynamical systemProgramming languageLecture/ConferenceComputer animation
19:00
Element (mathematics)StrutStatisticsLink (knot theory)Link (knot theory)Pointer (computer programming)Programming languageData storage deviceChemical equationCursor (computers)Reading (process)Ring (mathematics)Buffer solutionAnnulus (mathematics)StatisticsStability theoryComputer wormLengthOrder (biology)Computer animation
19:56
Local ringFunction (mathematics)StrutTrailMusical ensembleSoftware testingTheoryProduct (business)EmailComputer wormMereologyInterface (computing)Semiconductor memoryCommunications protocolFunctional (mathematics)MultilaterationField (computer science)Set (mathematics)Type theoryPointer (computer programming)Attribute grammarLengthLecture/ConferenceComputer animation
21:55
StrutCasting (performing arts)Function (mathematics)Multiplication signPointer (computer programming)EmailExtension (kinesiology)SoftwareElectronic visual displaySinc functionType theoryOrder (biology)Computer animation
23:01
Communications protocolLocal ringFunction (mathematics)Raw image formatEvoluteLibrary (computing)Different (Kate Ryan album)Utility softwareSlide ruleCommunications protocolAbstractionLecture/Conference
24:03
Hash functionTable (information)Token ringCommunications protocolSocket-SchnittstelleTap (transformer)Device driverTopologyBridging (networking)Lattice (order)IPSecBit rateOpen sourceNetwork socketRaw image formatMobile appHacker (term)BefehlsprozessorLibrary (computing)Communications protocolExecution unitMatching (graph theory)Table (information)BuildingBootingProgramming languageHeegaard splittingNetwork socketMobile appPoint (geometry)Open sourceProper mapOrder (biology)Interface (computing)Inheritance (object-oriented programming)Projective planeComputer programBit rateNetwork topologyRepository (publishing)Software1 (number)Bridging (networking)Musical ensembleUltraviolet photoelectron spectroscopyComputer animationLecture/Conference
27:07
Hacker (term)SoftwareLine (geometry)InternetworkingInterface (computing)Device driverComputer configurationVirtualizationSoftware bugMusical ensemble1 (number)Traffic reportingDigital rights managementSoftware maintenanceLimit (category theory)Service (economics)WeightExpert systemCommunications protocolKernel (computing)Server (computing)Moment (mathematics)Level (video gaming)Cartesian coordinate systemData storage deviceImplementationComputer fileOSI modelPoint (geometry)Assembly languageDatabaseInheritance (object-oriented programming)Integrated development environmentMultiplication signSoftware testingArmFirmwareComputer architectureWritingComputer programInternet service providerLibrary (computing)Linear regressionModule (mathematics)Lecture/ConferenceMeeting/Interview
32:57
Hacker (term)SynchronizationQuicksortBitCartesian coordinate systemFile systemAbstractionDevice driverComputer fileInterface (computing)Bit rateDifferent (Kate Ryan album)Core dumpElectric generatorServer (computing)Absolute valueCASE <Informatik>SoftwareWritingSoftware testingLevel (video gaming)Motion captureReading (process)Mobile appLink (knot theory)Network socketOpen sourceGeneric programmingComputer hardwareBefehlsprozessorIterationGateway (telecommunications)2 (number)NumberOpen setPhysical systemFirmwareComplex (psychology)Latent heatTap (transformer)Connected spaceRaw image formatWorkloadOffice suiteFirewall (computing)WeightMathematical optimizationParticle systemWater vaporTablet computerUser interfaceMusical ensembleProduct (business)HypermediaNatural numberScripting languageComputer programLecture/Conference
38:47
Hacker (term)FreewareOpen sourceLecture/ConferenceXMLComputer animation
Transcript: English(auto-generated)
00:07
So, Snap, fast software networking made simple. So first of all, hi, I'm Max. I'm an open source hacker.
00:22
I've been working on Snap on and off since 2014. I'm not the only person working on Snap, it's an open source project with a good number of contributors, but I've been in there for a while and it's a project I really like. 2014, that's a long time actually.
00:42
Time flies. So I'm also consulting on software networking, user space, networking protocols or protocols in general, software optimization, et cetera, just to put it out that there's a possibility to hire me to do certain dirty work.
01:02
So what's Snap? Snap is a software toolkit for writing high performance networking applications in user space. It's also known as kernel bypass mode. Other examples, for example, include DPDK or Cisco's VPP. It runs on generic x86-64 Linux servers.
01:23
And Snap has a strong design focus on simplicity. So in Snapland we like to write software that is both fast and simple and we believe that simplicity translates to efficiency and that fast programs don't need to be complex. If you ever looked at the DPDK code base, you might believe otherwise.
01:42
We believe the opposite is true. So in this talk I want to cover a handful of questions. First of all, why Snap? Why would you want to do software networking at all? Second, how does Snap work? I'll give a very brief high-level overview of what makes it fast and how it comes about.
02:04
And third, what can you do with Snap? I'll give some examples to maybe whet your appetite and give you an idea of what's possible. And finally, I want to answer how do you write Snap applications and I'll give a short tutorial to get you started.
02:21
So why Snap? Imagine you want to deploy an RFC or a feature but no vendor is selling it yet. In the networking world this used to mean that you reached a dead end. Tough luck. Nowadays, however, you have the power of open source software and really, really powerful commodity hardware.
02:41
And if you implement your project in software, then the typical benefits apply. You have quicker, cheaper iteration cycles. You can hire any software engineer you want to hire. You can use any programming language you want to use.
03:00
Anyway, what's the software and user space stuff? So in some domains, relying on the kernel won't cut it. The kernel is, for example, for high performance networking and packet processing, it's simply not fast enough. And to a lot of people that comes as counterintuitive, because if you're an application programmer
03:23
you usually think of the kernel as the fastest part in your stack. When it comes to processing many small packets, in short times it's actually not very well optimized to do that at all. So one approach to work around that is to bypass the kernel on the data pass completely
03:40
and stay in user space the whole time instead. So we're going to ask the kernel to provide us with some resources, namely the PCI devices, some CPU cores, and some huge pages, some special memory, and we're going to take it from there ourselves.
04:01
And by the way, this technique doesn't only apply to networking, so if you're in the business of writing really fast software in general, this talk might be interesting to you, and it's not, I guess it's IO-centric, but it's not particularly networking-centric. So how does that fast data pass look like?
04:21
We tell the kernel to forget about the network device, the PCI resources that make up the network device are going to be managed by us directly. So we map the device registers into memory of our process, and we poke them to initialize the NIC, the network device.
04:40
We also allocate memory for packets on DMA huge pages for input and output with the device. So DMA memory is memory that PCI devices can read from and write to directly without going through the CPU, and so DMA stands for direct memory access.
05:05
And then once we set that stuff up, we enter a busy loop where we pull the device for new packets and write to the transmitted receive queues of the device. And these transmitted receive rings that are managed by the device, they are filled with
05:23
pointers to packets in our DMA memory that we allocated. So how does that give us fast applications? Well, your application logic can now sit in that busy loop. You don't need any context switches between the device driver and your application to
05:43
do your work. And this means that for modern CPUs, you have a big advantage where your caches will stay loaded with the things you're actually working on at that given time. So that's neat. Your application has full access to the packets. It can modify them in place and hands off mutated packets basically directly to the
06:05
device's transmit queue. And remember, it's just software, so you can write it in any language. You can write this program in Lua, Rust, C, Assembly, whatever. So what do I mean when I say fast?
06:22
I guess that's a good question. So ultimately we're limited by PCI bandwidth, obviously. And the limit that you're more likely going to hit is CPU frequency times core count. Times core count because chances are that your problem is parallelizable. And in practice you can expect throughputs of 10 to 50 gigabits per core on a modern
06:43
CPU or one to five million packets per second being processed per core, depending on your workload, of course. All right. So what can you do with Snap? I'll show some deliberately sampled examples to try to give you an idea.
07:03
And maybe once you've seen those, you can think of your own use case for Snap. So Packet Blaster is a low overhead load generator built using Snap. It's a really small program, somewhat like a proof of concept.
07:22
And it shows off what you can do when you can poke the network device directly. So it uses a trick to send packets at full speed without actually doing any I.O. with the device. And I guess Packet Buster falls into the category of homemade diagnostics tools. So if you need a custom network debugging tool, chances are you can write it yourself
07:45
with Snap pretty quickly. And yeah, that's not readable at all. But basically, I mean, you can probably make out that this is an Htop output thing. And the server's not loaded. And we're sending a lot of packets.
08:05
The lightweight 4 over 6 address family translator developed by Igalia is an example of a full blown network function built using Snap. This application is production grade. And it handles an ISP's IPv4 traffic for a whole country.
08:22
I added a link here to a RIPE talk where this is discussed more. But yeah, Snap is in production. And this is an IPv4 over IPv6 transitional technology. So just in case it wasn't clear.
08:44
Then there's also this big CDN provider, not going to name it, but it's big, that uses Snap to let network engineers query a terabit of the live traffic. So I want to show a picture of a server rack here with tons of 10G ports. But the pictures of many, many ports in a rack on the internet usually are of switches.
09:05
So in this sense, Snap's a little bit of a user software network in general is a bit of a divergence where you will have racks with many, many ports that are not indeed switches. Anyway, they have this rack of servers running Snap, and the engineers can write ad hoc
09:23
newer scripts that they then execute to grind through the traffic in real time. And this way, they evaluate designs and perform analysis of what they're doing and what's happening. I thought it was pretty cool.
09:41
And then there's my own project, Vita. I'll be cheeky and use this slide for some self-promotion. So Vita is an IPsec-based network layer security solution. I am deliberately not calling it a VPN here because that tends to give people the wrong idea. Vita is about encrypting your network pass at high speed in case you don't want to
10:01
trust the links. It's not actually on the link layer. It's in that sense an IPsec VPN. But it's really geared towards the use case of encrypting a lot of traffic quickly. So if you're interested in link layer security at 10G and above, I'd love to talk to you later. If you want to know more about this, poke me and or check out my talk from RIPE78, high
10:27
performance traffic encryption x86-64. So just to remind you, everything I mentioned here is open source and runs on commodity
10:40
servers. So you can contribute, fork, reuse and repurpose it. And there's actually a number of consultancies just waiting to help you out. So I guess we arrived at the tutorial. So this is the hard part for me at least.
11:01
So how do you write a Snap application? So I'll be using some material from Luke Gorrie's introductory blows to your name, the hand-drawn diagrams that I really, really like. So what you see here is a bunch of different apps. An app in Snapland is a term we use for components of your whole program or application.
11:20
It's not the whole thing. But basically, an app is a fixed-purpose component that you can reuse to build your larger designs. And an app can have any number of input and output links where the links are unidirectional. In this sense, they are different from an Ethernet cable, which is bi-directional.
11:40
Our links are unidirectional. So to emulate an Ethernet cable, you need two, basically. And an app will receive packets on its input links, process the packets in its own peculiar way, and then transmit them, or transmit some packets at least, on its output links. And an app could be an I.O. interface towards the network device, a switch, a firewall,
12:04
or anything really that receives and transmits packets. So to create your application, you combine instances of these apps into what we call
12:24
an app network. So you can see an example of this here on the diagram on the left, where you have two device interfaces connected by a firewall app. So traffic that comes into the one device will be filtered and sent out to the other device and vice versa.
12:42
And on the left, on the right, why is this flipped? On the right here, we have some code that shows you how to configure an app network using Snap. And it's not exactly the example shown on the right. This code just has one firewall app and one I.O. app.
13:01
But it shows you everything you need to know in order to do bigger designs. So let's go through this from the top. So at the very beginning, we create a new empty configuration using config new here. And then we add two apps to that configuration, two instances of apps.
13:20
The first is our I.O. device, which is some device driver. And it gets a PCI address as an initialization argument to tell it which device to actually use and drive. And the second one is a firewall app, which is, in this case, a pickup filter. We pass it an expression, a pickup filter expression, to basically tell it what to filter
13:40
and what to let through. And then we configure two links, one from the I.O. interface into the firewall app and one back from the firewall app into the I.O. interface. And finally, we can configure, apply our configuration, and run the engine, which will basically realize and execute this topology.
14:10
So I guess I should answer, what does executing the app graph mean, this app network? We have this breathing metaphor. We say we inhale a batch of packets into the graph.
14:21
We then execute each app to process these packets and exhale them out of the graph. And repeat this process basically until the program exits. And we call a single iteration of this loop a breath.
14:44
So at some point, you'll want to create your own apps. And I'll show you how to do that. So an app is organized into a bunch of callbacks. And I'll cover the three most important ones here. The new callback is used to initialize an app instance.
15:01
And it's called by engine.configure to create a new instance. It receives the configuration argument that we talked about. And yeah, that's how new apps get created, instances of apps. The push callback is executed during the breath to process packets and exhale them out of the application.
15:21
And the pull callback pulls packets into the network, into the app network. So this piece of code here defines an app called Firewall. And in its constructor, the new callback, it compiles a filter from the rules passed to it during configuration.
15:45
And this call to set meta table here, that's Louis' idiom of doing object-oriented, like doing, instantiating a class using prototype-based object orientation. It's not really important here, but yeah. And as mentioned, this will be executed by engine.configure
16:00
to create an instance of the app. So during a breath, the engine will try to call the app's push callback, where it will process the packets. So this is an example of a push method or push callback. Same thing, really. So example Firewall app has an input and an output link.
16:24
And these are created and set up and connected automatically as declared in the configuration. You don't have to do this all yourself. They will just show up in these input and output arrays here. So what it's going to do, it's read the next packet
16:42
from the input link while the input link is not empty. It will then try to apply the filter. And if it matches, we're going to transmit the packet P onto the output link. And if it doesn't match, we're going to drop the packet by freeing it. All there is to it.
17:08
Right. And if an app has a pull callback, it will be executed at the beginning of a breath in order to inhale packets into the application. So this is an example from a device driver. For Intel Nix, it only has an output link
17:24
because it's pulling in packets from the device and putting them on this output link for other apps to consume. And what it's basically doing here is just saying, for one to this constant, which is the number of the batch size, we want to inhale in each breath,
17:40
see if the device can receive a new packet, if it has a packet ready, if it has, transmit that packet from the device onto the output link. So you might have noticed that the examples of our Lua code. And in fact, Snap itself is written in Lua.
18:02
And the easiest way to write Snap applications is by writing Lua. And yes, what I've shown you here so far is high-performance code. So this all runs very fast, competitive in performance with C. And one thing I want to note, however, is that the packet that link ABI,
18:21
more on that soon, is stable. So nothing really prevents you from writing your apps in other languages and linking them with Snap. But isn't Lua supposed to be this high-level, dynamic, embedded scripting language? How can it be so fast?
18:40
We rely on the blazing fast replica compiler, which is a fork of LuaJIT, that is geared towards heavy-duty server applications such as Snap. And if you like the idea of a fast, dynamic systems language, I invite you to check out this project. I think it's really neat.
19:01
So I mentioned that there's a stable link in packet ABI. So I guess I should answer, what's the link? So a link is really just a circular ring buffer that stores pointers to packets. It consists of a ring of pointers, a read cursor, and a write cursor. And there are some stats counters omitted there,
19:20
but that's really all there is to it. And that's the stable ABI. You can access these structs from any language you really like, but in order to use the link, all you need to know is really this. So I guess the next question is, what's a packet? A packet is really just its length.
19:41
Followed by its payload in the byte array. So knowing this, how the link and the packet look like, we can figure out the remaining piece of the puzzle, which is, how do we modify packets or read them?
20:07
So since the packet's payload is really just a byte array, we can test if it's a TCP packet, for example, by looking at the correct byte at the correct offset, which happens to be the IP protocol field. So we might define an offset,
20:21
here the IP offset here, that points at the offset of the IP header, which happens to be the length of the Ethernet header, and we also might define an offset of the protocol field in the IP header, and we can add to the pointer that is pointing to the beginning of the packet data
20:40
the IP offset to get the beginning of the IP header, and we can index that with the protocol field offset compared to the TCP identifier, and if that's the same, we know it's a TCP packet. Simple as that.
21:02
Set to fast. It's okay. I'll come back to this later. So the foreign function interface of Reptogit also lets you declare C structs inline, and we might define our protocol headers this way. So here we have some example definitions of the Ethernet header
21:22
and an IPv6 header, and if you studied network protocols at any point in time, you might recognize these. And here I guess the key part is that we have this attribute packed, C declaration, or C attribute, which tells it to not do any, like, not have any padding,
21:41
not try to align these fields, interpret them as is. So these are like verbatim C structs, the memory layout, and here we have two pointers. We define pointer types to these structs. And so we might write the previous example
22:01
once we have defined these structs, only this time for IPv6. Also this way, where we, instead of working with the byte pointer directly, we cast the beginning of the packet to the Ethernet header type, and at the offset of the IP header,
22:20
we cast the remaining bytes to the IPv6 header type, and then we can look at the structs and see if the Ethernet type is IPv6, and this here, by the way, is a multi-byte value, so we have to convert it from network byte order to little n, since we're in x86. We can check if that's an IPv6 packet,
22:41
and then we can check, hey, is the IP an x header field, the TCP identifier, and then we know, ah, it's a TCP packet, fine. Oh, and by the way, this only shows how you would read bytes from the packet, but you might just as well assign different values there by their assignment. So this goes both ways.
23:12
So I want to show you this evolution of abstractions to give you an idea how basic it really is
23:21
to mess around with packets as raw data, but Snap comes with a library of protocol definitions and basically utilities to do this, and this slide shows how you would do the example from before with the built-in libraries. But under the hood, it's really just the same thing,
23:42
so you're absolutely free to write your own abstractions, come up with your own idioms. There's many different ways you can do this. There's really no magic underneath that. Anyways, the protocol library will take care of things like endianness and parsing the packets in the first place.
24:04
And we've got a lot of libraries, actually. We have libraries for many protocols, things like longest prefix match, checksums, the CPU's performance monitoring unit, token bucket algorithms, fast hash tables, logging, yang, and much more, really.
24:21
So chances are that whatever you need is already implemented and you can reuse it. We also provide a really comprehensive collection of apps that are ready to use. So, for example, things that are already implemented are basic topology apps like splitting and joining traffic,
24:40
layer two bridges, device drivers, apps for IP fix, apps for IP sec, ARP, neighbor discovery, ICMP, IP fragmentation, defragmentation, packet filtering, rate limiting, Linux socket interfaces, boot IO.
25:01
Did the battery just die on me? I think it did. Oh, it did not. Yeah, so there's really a lot of apps already present, and you can reuse them, reuse encouraged, and if you write your own app, you want to supply it back to Snap Upstream, we're happy to take it.
25:23
So I guess to get started, all we really have to do is clone a repository, build it, which takes under 10 seconds, and all the dependencies are included in the repository. So there's no build hell you're going to enter at that point. Copy an example program to a new name,
25:41
let's say my hack, start hacking, rebuild, and run your program. It's really that simple. So, what the hell?
26:03
Well, I guess it's readable. So I invite you to engage with us on GitHub. It's an open source project. You can join in and have fun with us. We have a Slack channel where you can ask questions. Super happy to help you out there.
26:21
There's also online documentation, and if that's out of date or something is missing there, then you can blame me for that. And so finally, at that point, I would like to thank you for your attention and open up for questions, which you can ask in any language where language is one of German or English. I will translate them back.
26:42
All right, thank you. You basically said that you need to reserve exclusively
27:03
a network interface for Snap in order to make it work properly. Is there a reliable way to do this virtualized? So, for example, if you want to use...
27:20
There's many ways to do this. There's many ways, actually. So we have a driver for vhost-user, which is basically a way to use Snap as the provider for QEMU virtualization. And we also have the reverse part, which is a virtio interface,
27:40
which is basically you run Snap in a VM and use the virtualized device from the host. In that case, you don't even need specific drivers. You also have the option to... So basically, if you want to reserve a NIC, you usually want to do that because you want to use it fully, and it's kind of like a question of high performance. While Snap is geared towards writing high performance applications,
28:04
there's nothing that says you have to write high performance applications. So you could also use receive and send packets over a Linux socket, and it might still be a very nice programming experience, depending on what you like. But there's also things like doing relatively high performance virtual network I.O.
28:25
And we also have incoming drivers right now for Intel AVF, which is the virtualized device spec from Intel that's becoming more prevalent. And we're working on an AFXDP interface. Okay, and this is basically full virtualization,
28:44
and what about pseudo-virtualization like LXC and so on? I guess the same things should apply. I'm not sure. I think AFXDP should come into play there. I'm actually not sure. And the second question I was thinking about was,
29:02
you said that this will run mostly on the x86-64 Linux servers. What about other Unix OSes and other architectures like ARM or some other network devices where you might be able to flash your own firmware
29:26
onto whatever runs on VRT or something? Yeah, so the reason why we only support x86 and Linux is basically maintenance. If we would support... So if you would port this to, let's say, ARM or FreeBSD,
29:45
then basically what we would have is a situation where we had to have test infrastructure for all these things. So we open the ports, but we would require the person who does the port to maintain it and to do the work, basically, because we're not gonna...
30:02
Yeah, we can't do it like... Take a FreeBSD port and then manage running FreeBSD test infrastructure for the rest of... It has to be like a joint effort, but generally we open. A lot of people ask about Snap-on-ARM. So the reason why we target x86 is because at this time it's like the dominant server hardware
30:25
and this really targets these high-performance server environments. So that's why we focus on that for now. Dominant by now. Yeah, I mean, it's not a huge amount of work porting it. The port itself wouldn't be a big deal, I think. We're relying on almost no interfaces from Linux kernel
30:43
and we're relying on very, very small portions and only some modules where we use some x86 assembly directly. The work is really the maintenance and maintaining that CI infrastructure because we have to test every change, we do performance regression testing
31:00
and we would have to duplicate this for every architecture and operating system, basically. That's a big chunk. Thank you very much. Hi. Is there any place to start a protocol implementation like Samba or NFS
31:22
or are there existing ideas of porting the server protocols for file sharing like Samba or NFS in Lua or are there any libraries which support them? So I guess Samba or NFS.
31:45
So if you wanted to write a really, really high-performance NFS server, you definitely could do that with Snap. So things that we thought about is like writing a really fast TCP proxy, for example, in Snap or something like that, that's certainly possible.
32:01
There's no Samba or NFS libraries in Snap upstream. You would have to write them yourselves. What is there, however, is the lower layer, network layer protocols like IPv6, IPv4, Ethernet, GRE, things like that. So the application layer is really something where we say, okay, you can definitely do that, we invite you to do that.
32:21
That's an awesome idea, we want to see that. Other ideas were like, hey, let's write a super high-performance database on Snap. Things like that, but we don't really have application-level protocols in Snap at that point. But it could be fun.
32:44
How many device drivers do you support at the moment, and what kind of? At the moment, we have a solar flare driver, we have a driver for the Intel 82599, the Niantic chips, we have a driver for Intel AVF, which hopefully will support a lot of devices
33:04
like the X710, and we have a driver for Mellanox Connect X series. So we could have more, we would like to write less drivers. Basically, our problem with device drivers is that network device vendors
33:22
like to write complex specifications and complex interfaces, and they want their own firmware operating system in between. Basically, we're working with other people to try to have them open up PRMs. So what I'm not going to do, we're not going to implement a device driver
33:42
for a device that doesn't have an open specification, because that's just fool's work. So if you give us an open specification, then I'm happy to write a device driver. So hi, it's me again. Is there any particular reason for choosing a special license
34:07
for coding Snap applications or HEX? If I, must I... No, Snap is Apache 2 licensed, and you can, basically that means that you can license your sub-project
34:23
in really anything you want, I think. So for example, I have Vita's license, AGPL v3, but Snap is licensed Apache 2, I think that makes it very flexible in that regard. Thanks a lot. What about the resource consumption for, for example,
34:43
a hack you did show us with firewall in-end output? What do you mean by that? What, what, if we talk about high-end servers which run Snap, what have I...
35:03
So the question is, what kind of performance, I guess, can you expect? It really depends on your application, if you can parallelize it. Like with one core you're not gonna go much over 5 million packets per second,
35:21
if it's really not doing much. So I guess one number that I could throw out there is this VPN gateway that I've written using Snap, that is able to process 3 million packets per second per core on a modern CPU. And that's doing IP sync, that's doing encryption.
35:40
Yeah, so generally a lot, it's not, it's not in the... So I guess we're one generation or, yeah, we're like one iteration behind the hardware networking world, where they have like 400G switches and whatnot. But you can definitely...
36:00
So my immediate or medium-term goal is to have a 100G line rate VPN, IP sync VPN, right using Snap, and I'm only waiting for AMD servers with more cores to do that. That's the situation. Thank you.
36:23
Is it possible to use anything different than interfaces as endpoint entities in Snap? So for instance, generic file descriptor or socket or file system abstraction layer itself to, for instance,
36:46
realize an efficient way to mirror the whole traffic going through an application directly to disk? So there's companies that do that and they build FPGAs,
37:00
because if you want to capture like a terrible bit of traffic, it's actually quite tricky to do so. You're definitely not going to use any Unix file system APIs. For Snap, not particularly. So I guess you would start by writing some sort of SSD device driver or something.
37:24
I mean, if you want to do it really fast, if you want to capture 100 megabits, then you can, it's possible that you have built in. So what we do have is pcap, pcap-dump, capture, and sync and source apps. So what we use a lot for testing and debugging is,
37:42
read this packet capture from this file and put it onto a link and reverse, like capture the packets on this link. They're not optimized at all, but if you want to do reasonable home network monitoring, they can easily do it. But if you want to go like high performance, then you have to work a little bit harder, I guess.
38:02
Yeah. And yeah, so just to mention the non-device interfaces, we have interfaces towards Linux, raw sockets, and tap devices. So if you want to operate on that level for testing or maybe use case is just that, working with the Linux networking stack, you can absolutely do that.
38:22
It's not going to be super fast. So you can basically write to RAM instead of to an interface? Yeah. Yeah, absolutely. That's it? That's all you got? Thank you.