Merge branch 'nfp-bpf-stack-support-in-offload'
authorDavid S. Miller <davem@davemloft.net>
Tue, 24 Oct 2017 08:38:38 +0000 (17:38 +0900)
committerDavid S. Miller <davem@davemloft.net>
Tue, 24 Oct 2017 08:38:38 +0000 (17:38 +0900)
commitfa6e23e2b2a09995bd57db559b04f3dd3fda9f7a
treed022dc299e72425908879b4373be6fde515f471f
parenta5dd4982879b29c7cb8fa1ba2bca9e1eb8c14dc2
parent9f16c8abcd79fc31a74d3af64f085a009c9d4b5a
Merge branch 'nfp-bpf-stack-support-in-offload'

Jakub Kicinski says:

====================
nfp: bpf: stack support in offload

This series brings stack support for offload.

We use the LMEM (Local memory) register file as memory to store
the stack.  Since this is a register file we need to do appropriate
shifts on unaligned accesses.  Verifier's state tracking helps us
with that.

LMEM can't be accessed directly, so we add support for setting
pointer registers through which one can read/write LMEM.

This set does not support accessing the stack when the alignment
is not known.  This can be added later (most likely using the byte_align
instructions).  There is also a number of optimizations which have been
left out:
 - in more complex non aligned accesses, double shift and rotation
   can save us a cycle.  This, however, leads to code explosion
   since all access sizes have to be coded separately;
 - since setting LM pointers costs around 5 cycles, we should be
   tracking their values to make sure we don't move them when
   they're already set correctly for earlier access;
 - in case of 8 byte access aligned to 4 bytes and crossing
   32 byte boundary but not crossing a 64 byte boundary we don't
   have to increment the pointer, but this seems like a pretty
   rare case to justify the added complexity.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>