diff options
author | Alexei Starovoitov <ast@kernel.org> | 2018-03-28 19:36:15 -0700 |
---|---|---|
committer | Alexei Starovoitov <ast@kernel.org> | 2018-03-28 19:36:15 -0700 |
commit | 22527437e0a0c96ee3153e9d0382942b0fd4f9dd (patch) | |
tree | aea8a593aad68318f258a8c400a2471c95ddc74d /net/core | |
parent | f6ef56589374670b7c1939720dfa00212bd80a5b (diff) | |
parent | 7c095f5d9bf4cbadbd4adb0adb670a38e42cd793 (diff) | |
download | linux-22527437e0a0c96ee3153e9d0382942b0fd4f9dd.tar.bz2 |
Merge branch 'nfp-bpf-updates'
Jakub Kicinski says:
====================
This set adds support for update and delete calls from the datapath,
as well as XADD instructions (32 and 64 bit) and pseudo random numbers.
The XADD support depends on verifier enforcing alignment which Daniel
recently added. XADD uses NFP's atomic engine which requires values
to be in big endian, therefore we need to keep track of which parts of
the values are used as atomics and byte swap them accordingly. Pseudo
random numbers are generated using NFP's HW pseudo random number
generator.
Jiong tackles initial implementation of packet cache, which he describes
as follows:
Memory reads on NFP would first fetch data from memory to transfer-in
registers, then move them from transfer-in to general registers.
Given NFP is rich on transfer-in registers, they could serve as memory
cache.
This patch tries to identify a sequence of packet data read (BPF_LDX) that
are executed sequentially, then the total access range of the sequence is
calculated and attached to each read instruction, the first instruction
in this sequence is marked with an cache init flag so the execution of
it would bring in the whole range of packet data for the sequence.
All later packet reads in this sequence would fetch data from transfer-in
registers directly, no need to JIT NFP memory access.
Function call, non-packet-data memory read, packet write and memcpy will
invalidate the cache and start a new cache range.
Cache invalidation could be improved in the future, for example packet
write doesn't need to invalidate the cache if the the write destination
won't be read again.
====================
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Diffstat (limited to 'net/core')
0 files changed, 0 insertions, 0 deletions