-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathepisode-23.xml
200 lines (180 loc) · 9.48 KB
/
episode-23.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
<?xml version="1.0" encoding="utf-8"?>
<item xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd">
<title>The IO Visor Project</title>
<guests>Brenden Blanco from VMware</guests>
<description>
<p>
Brenden Blanco is one of the most prolific developers working on the <a
href="https://www.iovisor.org/">IO Visor Project</a>, a <a
href="https://www.linuxfoundation.org/projects">Linux Foundation
Collaborative Project</a>. Brenden was an employee at <a
href="http://www.plumgrid.com/">PLUMgrid</a>, the startup behind IO
Visor, until it was acquired by VMware.
</p>
<p>
The interview begins with a history of the layers that stacked up to form
IO Visor. The history begins with the publication of <a
href="https://www.usenix.org/legacy/publications/library/proceedings/sd93/mccanne.pdf">The
BSD Packet Filter: A New Architecture for User-Level Packet Capture</a>
at the 1993 Winter USENIX Conference, in January 1993. This paper
introduced BPF, short for Berkeley Packet Filter, for selecting packets
to be copied to userspace for analysis. BPF was a register-based,
RISC-like virtual machine (analogous to the Java virtual machine). In
Brenden's words:
</p>
<blockquote>
Two of the major points really seemed very wise to me. It must be
protocol-independent: the kernel should not have to be modified to add
more protocol support... It must be general: the instruction set should
be rich enough to handle unforeseen uses. They have a few more points
about efficiency and generality, but those two first ones have really
ended up creating kind of a platform that has stood the test of time.
</blockquote>
<p>
Safety was also critical:
</p>
<blockquote>
Any operating system developer has an inherent distrust of the userspace,
and the system calls that they're defining need to be secure against
attack, as well as ignorance or bad programming. The API they expose
lets a code be uploaded but the kernel has to protect itself against bad
code. It doesn't allow loops, so you can't create an infinite loop in
this virtual machine, and it doesn't allow access to memory that's out of
bounds... That produces something that's limited, but safe. You can't do
everything that a programmer would want, but you can do so efficiently.
</blockquote>
<p>
BPF came to Linux during the development of the 2.5 release series, <a
href="https://lwn.net/Articles/599755/">according to LWN</a>.
</p>
<p>
A second fork of the history comes from academic research on operating
system extensibility, which was a theme that grew to prominence during
the 1990s with extensible research operating systems such as <a
href="https://en.wikipedia.org/wiki/SPIN_(operating_system)">SPIN</a> and
the <a href="https://en.wikipedia.org/wiki/Exokernel">Exokernel</a>.
Many different approaches were proposed, including those based on safe
languages like Modula-3 and Java. In addition, Brenden draws an analogy
between BPF and the development of instruction set-based GPUs.
</p>
<p>
Brenden says that the movement to software-defined networking has not
been able to speed up operating system evolution. Part of the goal of IO
Visor is to help speed up this evolution, by allowing the networking
subsystem to evolve independent of the rest of the operating system. In
Brenden's words:
</p>
<blockquote>
Five years ago or so, when we started seeing a move toward
software-defined networking, the hope was that some of this paradigm
would change a little bit. But what I've seen in some of the solutions
is that some of this actually isn't the case. You have a movement of
network functionality from hardware to software but it's still locked
into kind of the operating system life cycle, which is maybe faster than
hardware but isn't in data centers where we've been trying to address
this, it's still slower than the applications change, so the use cases
still change faster than the infrastructure.
</blockquote>
<p>
Around 2010, Alexei Starovoitov started bringing together these two
branches by extending BPF to form eBPF, which added numerous features
such as extending registers to 32 to 64 bits, increasing the number of
registers from 2 to 10, additional instructions, and the ability to jump
forward and backward (with some restrictions) and most importantly, the
ability to call a restricted set of kernel helper functions and the
ability to work with data structures (``maps''). These changes made the
platform a better target for compiling high-level language code and
better able to interact with its environments. In addition, compilers
for eBPF started being integrated into the kernel, to make eBPF execution
faster on key architectures.
</p>
<p>
Brenden introduces the <a
href="https://www.iovisor.org/technology/bcc">BCC</a>, or BPF Compiler
Collection, one of the primary sub-projects within IO Visor. BCC
provides a set of tools for building software in high-level languages,
such as C and Python, into BPF program objects, loading those programs
into running kernels, and interacting with them once they are loaded.
BCC also includes a large suite of example programs.
</p>
<p>
BPF programs are loaded into a kernel by attaching them to ``hook
points.'' Typically, the programs attached to a hook point are invoked
when some particular event occurs. For example, in networking, a BPF
program might be invoked whenever a packet is received on a particular
device, or for performance monitoring a BPF program might be attached to
a ``kprobe'' point.
</p>
<p>
Brenden explains how to use BCC to load a BPF program into the kernel
using a 1-line Python program. A more sophisticated program can retain
handles and use them to interact with the program at runtime. Brenden
describes how restrictions on BPF are reflected in what a C programmer
can include in a program. Keeping the in-kernel safety verifier simple
and correct is paramount, which tends to reduce the maximum complexity of
programs that can be loaded. The verifier is a limiting factor that
continues to evolve to make BPF more useful over time.
</p>
<p>
Currently the Open vSwitch community is considering whether to replace
the use of the Open vSwitch kernel module by BPF. Brenden is in favor of
the idea and offers some of his thoughts. First, his experience at
PLUMgrid shows that BPF is flexible enough to support a wide variety of
network applications, including those that Open vSwitch implements.
Second, it's an enjoyable experience for a single developer to be able to
cover the entire infrastructure for an application.
</p>
<p>
In the future, Brenden is looking forward to BPF usage becoming
ubiquitous for Linux performance monitoring and other non-networking use
cases, such as storage acceleration and security. BPF is already, for
example, <a
href="http://blog.cr0.org/2012/09/introducing-chromes-next-generation.html">used
for sandboxing in Chrome</a>. He's also looking forward to BPF for
hardware offload; it can already be used for hardware offload on
Netronome NICs.
</p>
<p>
For more information on IO Visor, please visit <a
href="https://www.iovisor.org">iovisor.org</a>. To talk to Brenden and
other IO Visor developers, visit the #iovisor channel on the oftc.net IRC
network. Brenden's nick is bblanco. You can also tweet to Brenden at <a
href="https://twitter.com/BrendenBlanco">@BrendenBlanco</a>.
</p>
<p>
More about BPF:
</p>
<ul>
<li>
In <a href="#e11">episode 11</a>, John Fastabend from Intel talks about
BPF on network edge nodes.
</li>
<li>
In <a href="#e4">episode 4</a>, Thomas Graf from Cisco talks about
Cilium, which uses BPF to address the question of how to address policy
in a legacy-free container environment that scales to millions of
endpoints.
</li>
<li>
<a
href="http://packetpushers.net/podcast/podcasts/pq-show-60-io-visor-project-linux-networking/">Packet
Pushers PQ Show 60</a>, from 2015, interviewed Pere Monclus from
PLUMgrid about the IO Visor Project and Linux networking.
</li>
</ul>
<p class="attribution">
OVS Orbit is produced by <a href="mailto:[email protected]">Ben Pfaff</a>. The
intro music in this episode is <a
href="http://dig.ccmixter.org/files/AlexBeroza/43098">Drive</a>,
featuring cdk and DarrylJ, copyright 2013, 2016 by Alex. The bumper
music is <a href="http://dig.ccmixter.org/files/speck/42100">Yeah Ant</a>
featuring Wired Ant and Javolenus, copyright 2013 by Speck. The outro
music is <a href="http://dig.ccmixter.org/files/Kirkoid/43005">Space
Bazooka</a> featuring Doxen Zsigmond, copyright 2013 by Kirkoid. All
content is licensed under a Creative Commons <a
href="http://creativecommons.org/licenses/by/3.0/">Attribution 3.0
Unported (CC BY 3.0)</a> license.
</p>
</description>
<pubDate>Mon, 16 Jan 2017 17:56:21 GMT</pubDate>
</item>