1xdp-loader(8) XDP program loader xdp-loader(8)
2
3
4
6 XDP-loader is a simple loader for XDP programs with support for attach‐
7 ing multiple programs to the same interface. To achieve this it exposes
8 the same load and unload semantics exposed by the libxdp library. See
9 the libxdp(3) man page for details of how this works, and what kernel
10 features it relies on.
11
12
13 Running xdp-loader
14 The syntax for running xdp-loader is:
15
16 xdp-loader COMMAND [options]
17
18 Where COMMAND can be one of:
19 load - load an XDP program on an interface
20 unload - unload an XDP program from an interface
21 status - show current XDP program status
22 clean - clean up detached program links in XDP bpffs directory
23 help - show the list of available commands
24
25
26 Each command, and its options are explained below. Or use xdp-loader
27 COMMAND --help to see the options for each command.
28
29
31 The load command loads one or more XDP programs onto an interface.
32
33
34 The syntax for the load command is:
35
36
37 xdp-loader load [options] <ifname> <programs>
38
39
40 Where <ifname> is the name of the interface to load the programs onto,
41 and the <programs> is one or more file names containing XDP programs.
42 The programs will be loaded onto the interface in the order of their
43 preference, as specified by the program metadata (see libxdp(3)).
44
45
46 The supported options are:
47
48
49 -m, --mode <mode>
50 Specifies which mode to load the XDP program to be loaded in. The valid
51 values are 'native', which is the default in-driver XDP mode, 'skb',
52 which causes the so-called skb mode (also known as generic XDP) to be
53 used, 'hw' which causes the program to be offloaded to the hardware, or
54 'unspecified' which leaves it up to the kernel to pick a mode (which it
55 will do by picking native mode if the driver supports it, or generic
56 mode otherwise). Note that using 'unspecified' can make it difficult to
57 predict what mode a program will end up being loaded in. For this rea‐
58 son, the default is 'native'.
59
60
61 -p, --pin-path <path>
62 This specifies a root path under which to pin any maps that define the
63 'pinning' attribute in their definitions. This path must be located on
64 a bpffs file system. If not set, maps will not be pinned, even if they
65 specify pinning in their definitions. When pinning maps, if the pinned
66 location for a map already exist, the map pinned there will be reused
67 if it is compatible with the type of the map being loaded.
68
69
70 -s, --section <section>
71 Specify which ELF section to load the XDP program(s) from in each file.
72 The default is to use the first program in each file. If this option is
73 set, it applies to all programs being loaded.
74
75
76 -v, --verbose
77 Enable debug logging. Specify twice for even more verbosity.
78
79
80 -h, --help
81 Display a summary of the available options
82
83
85 The unload command is used for unloading programs from an interface.
86
87
88 The syntax for the unload command is:
89
90
91 xdp-loader unload [options] <ifname>
92
93
94 Where <ifname> is the name of the interface to load the programs onto.
95 Either the --all or --id options must be used to specify which pro‐
96 gram(s) to unload.
97
98
99 The supported options are:
100
101
102 -i, --id <id>
103 Unload a single program from the interface by ID. Use xdp-loader status
104 to obtain the ID of the program being unloaded. If this program is the
105 last program loaded on the interface, the dispatcher program will also
106 be removed, which makes the operation equivalent to specifying --all.
107
108
109 -a, --all
110 Unload all XDP programs on the interface, as well as the multi-program
111 dispatcher.
112
113
114 -v, --verbose
115 Enable debug logging. Specify twice for even more verbosity.
116
117
118 -h, --help
119 Display a summary of the available options
120
121
123 The status command displays a list of interfaces in the system, and the
124 XDP program(s) loaded on each interface. For each interface, a list of
125 programs are shown, with the run priority and "chain actions" for each
126 program. See the section on program metadata for the meaning of this
127 metadata.
128
129
130 -v, --verbose
131 Enable debug logging. Specify twice for even more verbosity.
132
133
134 -h, --help
135 Display a summary of the available options
136
137
139 The syntax for the clean command is:
140
141
142 xdp-loader clean [options] [ifname]
143
144
145 The clean command cleans up any detached program links in the XDP bpffs
146 directory. When a network interface disappears, any programs loaded in
147 software mode (e.g. skb, native) remain pinned in the bpffs directory,
148 but become detached from the interface. These need to be unlinked from
149 the filesystem. The clean command takes an optional interface parameter
150 to only unlink detached programs corresponding to the interface. By
151 default, all detached programs for all interfaces are unlinked.
152
153
154 The supported options are:
155
156
157 -v, --verbose
158 Enable debug logging. Specify twice for even more verbosity.
159
160
161 -h, --help
162 Display a summary of the available options
163
164
166 To load an XDP program on the eth0 interface simply do:
167
168 # xdp-loader load eth0 xdp_drop.o
169 # xdp-loader status
170
171 CURRENT XDP PROGRAM STATUS:
172
173 Interface Prio Program name Mode ID Tag Chain actions
174 -------------------------------------------------------------------------------------
175 lo <no XDP program>
176 eth0 xdp_dispatcher native 50 d51e469e988d81da
177 => 50 xdp_drop 55 57cd311f2e27366b XDP_PASS
178
179
180
181 Which shows that a dispatcher program was loaded on the interface, and
182 the xdp_drop program was installed as the first (and only) component
183 program after it. In this instance, the program does not specify any of
184 the metadata above, so the defaults (priority 50 and XDP_PASS as its
185 chain call action) was used.
186
187
188 To use the automatic map pinning, include the pinning attribute into
189 the map definition in the program, something like:
190
191 struct {
192 __uint(type, BPF_MAP_TYPE_ARRAY);
193 __uint(max_entries, 10);
194 __type(key, __u32);
195 __type(value, __u64);
196 __uint(pinning, LIBBPF_PIN_BY_NAME);
197 } my_map SEC(".maps");
198
199
200 And load it with the --pin-path attribute:
201
202 # xdp-loader load eth0 my_prog.o --pin-path /sys/fs/bpf/my-prog
203
204
205 This will pin the map at /sys/fs/bpf/my-prog/my_map. If this already
206 exists, the pinned map will be reused instead of creating a new one,
207 which allows different BPF programs to share the map.
208
209
211 libxdp(3) for details on the XDP loading semantics and kernel compati‐
212 bility requirements.
213
214
216 Please report any bugs on Github: https://github.com/xdp-project/xdp-
217 tools/issues
218
219
221 xdp-loader and this man page were written by Toke Høiland-Jørgensen.
222
223
224
225V1.2.3 FEBRUARY 17, 2022 xdp-loader(8)