1xdp-loader(8)                 XDP program loader                 xdp-loader(8)
2
3
4

XDP-loader - an XDP program loader

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

The LOAD command

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

The UNLOAD command

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

The STATUS command

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

The CLEAN command

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

Examples

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

SEE ALSO

211       libxdp(3)  for details on the XDP loading semantics and kernel compati‐
212       bility requirements.
213
214

BUGS

216       Please report any bugs on  Github:  https://github.com/xdp-project/xdp-
217       tools/issues
218
219

AUTHOR

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)
Impressum