#
74801e50 |
| 16-Jan-2018 |
Quentin Monnet <quentin.monnet@netronome.com> |
nfp: bpf: reject program on instructions unknown to the JIT compiler
If an eBPF instruction is unknown to the driver JIT compiler, we can reject the program at verification time.
Signed-off-by: Que
nfp: bpf: reject program on instructions unknown to the JIT compiler
If an eBPF instruction is unknown to the driver JIT compiler, we can reject the program at verification time.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
#
1bba4c41 |
| 11-Jan-2018 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: bpf: implement bpf map offload
Plug in to the stack's map offload callbacks for BPF map offload. Get next call needs some special handling on the FW side, since we can't send a NULL pointer to
nfp: bpf: implement bpf map offload
Plug in to the stack's map offload callbacks for BPF map offload. Get next call needs some special handling on the FW side, since we can't send a NULL pointer to the FW there is a get first entry FW command.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
#
77a3d311 |
| 11-Jan-2018 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: bpf: add verification and codegen for map lookups
Verify our current constraints on the location of the key are met and generate the code for calling map lookup on the datapath.
New relocation
nfp: bpf: add verification and codegen for map lookups
Verify our current constraints on the location of the key are met and generate the code for calling map lookup on the datapath.
New relocation types have to be added - for helpers and return addresses.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
#
9d080d5d |
| 11-Jan-2018 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: bpf: parse function call and map capabilities
Parse helper function and supported map FW TLV capabilities.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Mon
nfp: bpf: parse function call and map capabilities
Parse helper function and supported map FW TLV capabilities.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
#
ff3d43f7 |
| 11-Jan-2018 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: bpf: implement helpers for FW map ops
Implement calls for FW map communication.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netrono
nfp: bpf: implement helpers for FW map ops
Implement calls for FW map communication.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
#
d48ae231 |
| 11-Jan-2018 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: bpf: add basic control channel communication
For map support we will need to send and receive control messages. Add basic support for sending a message to FW, and waiting for a reply.
Control
nfp: bpf: add basic control channel communication
For map support we will need to send and receive control messages. Add basic support for sending a message to FW, and waiting for a reply.
Control messages are tagged with a 16 bit ID. Add a simple ID allocator and make sure we don't allow too many messages in flight, to avoid request <> reply mismatches.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
#
4da98eea |
| 11-Jan-2018 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: bpf: add map data structure
To be able to split code into reasonable chunks we need to add the map data structures already. Later patches will add code piece by piece.
Signed-off-by: Jakub Ki
nfp: bpf: add map data structure
To be able to split code into reasonable chunks we need to add the map data structures already. Later patches will add code piece by piece.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
#
af93d15a |
| 10-Jan-2018 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: hand over to BPF offload app at coarser granularity
Instead of having an app callback per message type hand off all offload-related handling to apps with one "rest of ndo_bpf" callback.
Signed
nfp: hand over to BPF offload app at coarser granularity
Instead of having an app callback per message type hand off all offload-related handling to apps with one "rest of ndo_bpf" callback.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
#
e84797fe |
| 10-Jan-2018 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: bpf: use a large constant in unresolved branches
To make absolute relocated branches (branches which will be completely rewritten with br_set_offset()) distinguishable in user space dumps from
nfp: bpf: use a large constant in unresolved branches
To make absolute relocated branches (branches which will be completely rewritten with br_set_offset()) distinguishable in user space dumps from normal jumps add a large offset to them.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
#
2314fe9e |
| 10-Jan-2018 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: bpf: relocate jump targets just before the load
Don't translate the program assuming it will be loaded at a given address. This will be required for sharing programs between ports of the same
nfp: bpf: relocate jump targets just before the load
Don't translate the program assuming it will be loaded at a given address. This will be required for sharing programs between ports of the same NIC, tail calls and subprograms. It will also make the jump targets easier to understand when dumping the program to user space.
Translate the program as if it was going to be loaded at address zero. When load happens add the load offset in and set addresses of special branches.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
#
1549921d |
| 10-Jan-2018 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: bpf: move jump resolution to jit.c
Jump target resolution should be in jit.c not offload.c. No functional changes.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Jio
nfp: bpf: move jump resolution to jit.c
Jump target resolution should be in jit.c not offload.c. No functional changes.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
#
cae1927c |
| 27-Dec-2017 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
bpf: offload: allow netdev to disappear while verifier is running
To allow verifier instruction callbacks without any extra locking NETDEV_UNREGISTER notification would wait on a waitqueue for verif
bpf: offload: allow netdev to disappear while verifier is running
To allow verifier instruction callbacks without any extra locking NETDEV_UNREGISTER notification would wait on a waitqueue for verifier to finish. This design decision was made when rtnl lock was providing all the locking. Use the read/write lock instead and remove the workqueue.
Verifier will now call into the offload code, so dev_ops are moved to offload structure. Since verifier calls are all under bpf_prog_is_dev_bound() we no longer need static inline implementations to please builds with CONFIG_NET=n.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
#
d3f89b98 |
| 19-Dec-2017 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: bpf: keep track of the offloaded program
After TC offloads were converted to callbacks we have no choice but keep track of the offloaded filter in the driver.
The check for nn->dp.bpf_offload_
nfp: bpf: keep track of the offloaded program
After TC offloads were converted to callbacks we have no choice but keep track of the offloaded filter in the driver.
The check for nn->dp.bpf_offload_xdp was a stop gap solution to make sure failed TC offload won't disable XDP, it's no longer necessary. nfp_net_bpf_offload() will return -EBUSY on TC vs XDP conflicts.
Fixes: 3f7889c4c79b ("net: sched: cls_bpf: call block callbacks for offload") Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
8231f844 |
| 14-Dec-2017 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: bpf: optimize the adjust_head calls in trivial cases
If the program is simple and has only one adjust head call with constant parameters, we can check that the call will always succeed at trans
nfp: bpf: optimize the adjust_head calls in trivial cases
If the program is simple and has only one adjust head call with constant parameters, we can check that the call will always succeed at translation time. We need to track the location of the call and make sure parameters are always the same. We also have to check the parameters against datapath constraints and ETH_HLEN.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
#
0d49eaf4 |
| 14-Dec-2017 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: bpf: add basic support for adjust head call
Support bpf_xdp_adjust_head(). We need to check whether the packet offset after adjustment is within datapath's limits. We also check if the frame i
nfp: bpf: add basic support for adjust head call
Support bpf_xdp_adjust_head(). We need to check whether the packet offset after adjustment is within datapath's limits. We also check if the frame is at least ETH_HLEN long (similar to the kernel implementation).
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
#
77a844ee |
| 14-Dec-2017 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: bpf: prepare for parsing BPF FW capabilities
BPF FW creates a run time symbol called bpf_capabilities which contains TLV-formatted capability information. Allocate app private structure to sto
nfp: bpf: prepare for parsing BPF FW capabilities
BPF FW creates a run time symbol called bpf_capabilities which contains TLV-formatted capability information. Allocate app private structure to store parsed capabilities and add a skeleton of parsing logic.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
#
9879a381 |
| 30-Nov-2017 |
Jiong Wang <jiong.wang@netronome.com> |
nfp: bpf: implement memory bulk copy for length within 32-bytes
For NFP, we want to re-group a sequence of load/store pairs lowered from memcpy/memmove into single memory bulk operation which then c
nfp: bpf: implement memory bulk copy for length within 32-bytes
For NFP, we want to re-group a sequence of load/store pairs lowered from memcpy/memmove into single memory bulk operation which then could be accelerated using NFP CPP bus.
This patch extends the existing load/store auxiliary information by adding two new fields:
struct bpf_insn *paired_st; s16 ldst_gather_len;
Both fields are supposed to be carried by the the load instruction at the head of the sequence. "paired_st" is the corresponding store instruction at the head and "ldst_gather_len" is the gathered length.
If "ldst_gather_len" is negative, then the sequence is doing memory load/store in descending order, otherwise it is in ascending order. We need this information to detect overlapped memory access.
This patch then optimize memory bulk copy when the copy length is within 32-bytes.
The strategy of read/write used is:
* Read. Use read32 (direct_ref), always.
* Write. - length <= 8-bytes write8 (direct_ref). - length <= 32-bytes and is 4-byte aligned write32 (direct_ref). - length <= 32-bytes but is not 4-byte aligned write8 (indirect_ref).
NOTE: the optimization should not change program semantics. The destination register of the last load instruction should contain the same value before and after this optimization.
Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
#
5e4d6d20 |
| 30-Nov-2017 |
Jiong Wang <jiong.wang@netronome.com> |
nfp: bpf: factor out is_mbpf_load & is_mbpf_store
It is usual that we need to check if one BPF insn is for loading/storeing data from/to memory.
Therefore, it makes sense to factor out related code
nfp: bpf: factor out is_mbpf_load & is_mbpf_store
It is usual that we need to check if one BPF insn is for loading/storeing data from/to memory.
Therefore, it makes sense to factor out related code to become common helper functions.
Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
#
a09d5c52 |
| 30-Nov-2017 |
Jiong Wang <jiong.wang@netronome.com> |
nfp: bpf: flag jump destination to guide insn combine optimizations
NFP eBPF offload JIT engine is doing some instruction combine based optimizations which however must not be safe if the combined s
nfp: bpf: flag jump destination to guide insn combine optimizations
NFP eBPF offload JIT engine is doing some instruction combine based optimizations which however must not be safe if the combined sequences are across basic block boarders.
Currently, there are post checks during fixing jump destinations. If the jump destination is found to be eBPF insn that has been combined into another one, then JIT engine will raise error and abort.
This is not optimal. The JIT engine ought to disable the optimization on such cross-bb-border sequences instead of abort.
As there is no control flow information in eBPF infrastructure that we can't do basic block based optimizations, this patch extends the existing jump destination record pass to also flag the jump destination, then in instruction combine passes we could skip the optimizations if insns in the sequence are jump targets.
Suggested-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
#
5b674140 |
| 30-Nov-2017 |
Jiong Wang <jiong.wang@netronome.com> |
nfp: bpf: record jump destination to simplify jump fixup
eBPF insns are internally organized as dual-list inside NFP offload JIT. Random access to an insn needs to be done by either forward or backw
nfp: bpf: record jump destination to simplify jump fixup
eBPF insns are internally organized as dual-list inside NFP offload JIT. Random access to an insn needs to be done by either forward or backward traversal along the list.
One place we need to do such traversal is at nfp_fixup_branches where one traversal is needed for each jump insn to find the destination. Such traversals could be avoided if jump destinations are collected through a single travesal in a pre-scan pass, and such information could also be useful in other places where jump destination info are needed.
This patch adds such jump destination collection in nfp_prog_prepare.
Suggested-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
#
854dc87d |
| 30-Nov-2017 |
Jiong Wang <jiong.wang@netronome.com> |
nfp: bpf: support backward jump
This patch adds support for backward jump on NFP.
- restrictions on backward jump in various functions have been removed. - nfp_fixup_branches now supports backw
nfp: bpf: support backward jump
This patch adds support for backward jump on NFP.
- restrictions on backward jump in various functions have been removed. - nfp_fixup_branches now supports backward jump.
There is one thing to note, currently an input eBPF JMP insn may generate several NFP insns, for example,
NFP imm move insn A \ NFP compare insn B --> 3 NFP insn jited from eBPF JMP insn M NFP branch insn C / --- NFP insn X --> 1 NFP insn jited from eBPF insn N --- ...
therefore, we are doing sanity check to make sure the last jited insn from an eBPF JMP is a NFP branch instruction.
Once backward jump is allowed, it is possible an eBPF JMP insn is at the end of the program. This is however causing trouble for the sanity check. Because the sanity check requires the end index of the NFP insns jited from one eBPF insn while only the start index is recorded before this patch that we can only get the end index by:
start_index_of_the_next_eBPF_insn - 1
or for the above example:
start_index_of_eBPF_insn_N (which is the index of NFP insn X) - 1
nfp_fixup_branches was using nfp_for_each_insn_walk2 to expose *next* insn to each iteration during the traversal so the last index could be calculated from which. Now, it needs some extra code to handle the last insn. Meanwhile, the use of walk2 is actually unnecessary, we could simply use generic single instruction walk to do this, the next insn could be easily calculated using list_next_entry.
So, this patch migrates the jump fixup traversal method to *list_for_each_entry*, this simplifies the code logic a little bit.
The other thing to note is a new state variable "last_bpf_off" is introduced to track the index of the last jited NFP insn. This is necessary because NFP is generating special purposes epilogue sequences, so the index of the last jited NFP insn is *not* always nfp_prog->prog_len - 1.
Suggested-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|
Revision tags: v4.13.16, v4.14 |
|
#
c6c580d7 |
| 03-Nov-2017 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: bpf: move to new BPF program offload infrastructure
Following steps are taken in the driver to offload an XDP program:
XDP_SETUP_PROG: * prepare: - allocate program state; - run verifie
nfp: bpf: move to new BPF program offload infrastructure
Following steps are taken in the driver to offload an XDP program:
XDP_SETUP_PROG: * prepare: - allocate program state; - run verifier (bpf_analyzer()); - run translation; * load: - stop old program if needed; - load program; - enable BPF if not enabled; * clean up: - free program image.
With new infrastructure the flow will look like this:
BPF_OFFLOAD_VERIFIER_PREP: - allocate program state; BPF_OFFLOAD_TRANSLATE: - run translation; XDP_SETUP_PROG: - stop old program if needed; - load program; - enable BPF if not enabled; BPF_OFFLOAD_DESTROY: - free program image.
Take advantage of the new infrastructure. Allocation of driver metadata has to be moved from jit.c to offload.c since it's now done at a different stage. Since there is no separate driver private data for verification step, move temporary nfp_meta pointer into nfp_prog. We will now use user space context offsets.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
9314c442 |
| 03-Nov-2017 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: bpf: move translation prepare to offload.c
struct nfp_prog is currently only used internally by the translator. This means there is a lot of parameter passing going on, between the translator a
nfp: bpf: move translation prepare to offload.c
struct nfp_prog is currently only used internally by the translator. This means there is a lot of parameter passing going on, between the translator and different stages of offload. Simplify things by allocating nfp_prog in offload.c already.
We will now use kmalloc() to allocate the program area and only DMA map it for the time of loading (instead of allocating DMA coherent memory upfront).
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
c1c88eae |
| 03-Nov-2017 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: bpf: move program prepare and free into offload.c
Most of offload/translation prepare logic will be moved to offload.c. To help git generate more reasonable diffs move nfp_prog_prepare() and n
nfp: bpf: move program prepare and free into offload.c
Most of offload/translation prepare logic will be moved to offload.c. To help git generate more reasonable diffs move nfp_prog_prepare() and nfp_prog_free() functions there as a first step.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
e4a91cd5 |
| 03-Nov-2017 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: bpf: require seamless reload for program replace
Firmware supports live replacement of programs for quite some time now. Remove the software-fallback related logic and depend on the FW for pro
nfp: bpf: require seamless reload for program replace
Firmware supports live replacement of programs for quite some time now. Remove the software-fallback related logic and depend on the FW for program replace. Seamless reload will become a requirement if maps are present, anyway.
Load and start stages have to be split now, since replace only needs a load, start has already been done on add.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|