From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: daniel@iogearbox.net, netdev@vger.kernel.org,
oss-drivers@netronome.com,
Jan Gossens <jan.gossens@rwth-aachen.de>
Subject: Re: [PATCH bpf-next 00/14] nfp: bpf: add updates, deletes, atomic ops, prandom and packet cache
Date: Wed, 28 Mar 2018 19:45:19 -0700 [thread overview]
Message-ID: <20180329024518.tfwzdohuf34n3hxp@ast-mbp> (raw)
In-Reply-To: <20180329004839.4506-1-jakub.kicinski@netronome.com>
On Wed, Mar 28, 2018 at 05:48:24PM -0700, Jakub Kicinski wrote:
> Hi!
>
> 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.
Looks exciting.
Applied to bpf-next, thank you Jakub.
prev parent reply other threads:[~2018-03-29 2:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-29 0:48 [PATCH bpf-next 00/14] nfp: bpf: add updates, deletes, atomic ops, prandom and packet cache Jakub Kicinski
2018-03-29 0:48 ` [PATCH bpf-next 01/14] nfp: bpf: read from packet data cache for PTR_TO_PACKET Jakub Kicinski
2018-03-29 0:48 ` [PATCH bpf-next 02/14] nfp: bpf: support unaligned read offset Jakub Kicinski
2018-03-29 0:48 ` [PATCH bpf-next 03/14] nfp: bpf: detect packet reads could be cached, enable the optimisation Jakub Kicinski
2018-03-29 0:48 ` [PATCH bpf-next 04/14] nfp: bpf: rename map_lookup_stack() to map_call_stack_common() Jakub Kicinski
2018-03-29 0:48 ` [PATCH bpf-next 05/14] nfp: bpf: add helper for validating stack pointers Jakub Kicinski
2018-03-29 0:48 ` [PATCH bpf-next 06/14] nfp: bpf: add helper for basic map call checks Jakub Kicinski
2018-03-29 0:48 ` [PATCH bpf-next 07/14] nfp: bpf: add map updates from the datapath Jakub Kicinski
2018-03-29 0:48 ` [PATCH bpf-next 08/14] nfp: bpf: add map deletes " Jakub Kicinski
2018-03-29 0:48 ` [PATCH bpf-next 09/14] bpf: add parenthesis around argument of BPF_LDST_BYTES() Jakub Kicinski
2018-03-29 0:48 ` [PATCH bpf-next 10/14] nfp: bpf: add basic support for atomic adds Jakub Kicinski
2018-03-29 0:48 ` [PATCH bpf-next 11/14] nfp: bpf: expose command delay slots Jakub Kicinski
2018-03-29 0:48 ` [PATCH bpf-next 12/14] nfp: bpf: add support for atomic add of unknown values Jakub Kicinski
2018-03-29 0:48 ` [PATCH bpf-next 13/14] nfp: bpf: add support for bpf_get_prandom_u32() Jakub Kicinski
2018-03-29 0:48 ` [PATCH bpf-next 14/14] nfp: bpf: improve wrong FW response warnings Jakub Kicinski
2018-03-29 2:45 ` Alexei Starovoitov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180329024518.tfwzdohuf34n3hxp@ast-mbp \
--to=alexei.starovoitov@gmail.com \
--cc=daniel@iogearbox.net \
--cc=jakub.kicinski@netronome.com \
--cc=jan.gossens@rwth-aachen.de \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@netronome.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.