Extending berkeley packet filter semantics for hardware offloads
Examples include registering a device driver with an operating system, including registering available hardware offloads. The operating system receives a call to a hardware offload, inserts a binary filter representing the hardware offload into a hardware component and causes the execution of the binary filter by the hardware component when the hardware offload is available, and executes the binary filter in software when the hardware offload is not available.
1. A method comprising:
registering a device driver with an operating system, including registering available hardware offloads to perform extended Berkeley packet filters (eBPFs), wherein available hardware offloads are indicated in a selected negative packet offset location and without introducing extensions to an eBPF framework;
receiving a call to execute a hardware offload of an eBPF selected from an eBPF software library, the call indicating one or more code fragments of the selected eBPF that, when executed, perform predetermined packet processing functions;
compiling a bytecode for the selected eBPF based on information from the eBPF software library;
inserting the selected eBPF into a hardware component and executing the selected eBPF by the hardware component when the hardware offload for the selected eBPF is available; and
executing the selected eBPF in software when the hardware offload is not available.
2. The method of claim 1 , wherein the call to execute the hardware offload comprises a call to a function of a kernel of the operation system.
3. The method of claim 1 , wherein the call to hardware offload comprises a call to execute the hardware offload by a new command of an eBPF framework.
4. The method of claim 1 , wherein the hardware component comprises a network I/O device.
5. The method of claim 1 , wherein executing the selected eBPF comprises processing data packets received from a network.
6. The method of claim 1 , wherein executing the selected eBPF in software comprises executing the the selected eBPF in kernel space of the operating system.
7. A tangible non-transitory machine-readable medium comprising a plurality of instructions, that when executed by the machine, cause the machine to:
register a device driver with an operating system, including registering available hardware offloads to perform extended Berkeley packet filters (eBPFs), wherein available hardware offloads are indicated in a selected negative packet offset location and without introducing extensions to an eBPF framework;
receive a call to execute a hardware offload an eBPF selected from an eBPF software library, the call indicating one or more code fragments of the selected eBPF that, when executed, perform predetermined packet processing functions;
compile a bytecode for the selected eBPF based on information from the eBPF software library;
cause the insertion of the selected eBPF into a hardware component and cause the execution of the selected eBPF by the hardware component when the hardware offload for the selected eBPF is available; and
execute the selected eBPF in software when the hardware offload is not available.
8. The tangible non-transitory machine-readable medium of claim 7 , wherein the call to execute the hardware offload comprises a call to a function of a kernel of the operation system.
9. The tangible non-transitory machine-readable medium of claim 7 , wherein the call to execute the hardware offload comprises a call to execute the hardware offload by a new command of an eBPF framework.
10. The tangible non-transitory machine-readable medium of claim 7 , wherein instructions to execute the selected eBPF comprise instructions to process data packets received from a network.
11. The tangible non-transitory machine-readable medium of claim 7 , wherein instructions to execute the selected eBPF in software comprise instructions to execute the selected eBPF in kernel space of the operating system.
12. A processing system comprising:
a network I/O device; and
a computing platform including an operating system to register a device driver to interface with the network I/O device, registration including registering available hardware offloads to perform extended Berkeley packet filters (eBPFS) by the network I/O device, wherein available hardware offloads are indicated in a selected negative packet offset location and without introducing extensions to an eBPF framework, to receive a call to execute a hardware offload an eBPF selected from an eBPF software library, the call indicating one or more code fragments of the selected eBPF that, when executed, perform predetermined packet processing functions, to compile a bytecode for the selected eBPF based on information from the eBPF software library; to cause the insertion of the selected eBPF into the network I/O device and to cause the execution of the selected eBPF by the network I/O device when the hardware offload is available, and to execute the selected eBPF in software on the computing platform when the hardware offload is not available.
13. The processing system of claim 12 , wherein the call to execute the hardware offload comprises a call to a function of a kernel of the operation system.
14. The processing system of claim 12 , wherein the call to execute the hardware offload comprises a call to a new command of an eBPF framework.
15. The processing system of claim 12 , wherein the selected eBPF processes data packets received from a network.
16. The processing system of claim 12 , wherein executing the selected eBPF in software comprises executing the selected eBPF in kernel space of the operating system.