]> git.baikalelectronics.ru Git - kernel.git/commit
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)
commitce5c161c2fa8beea0fbcf636869ec2078d2c6966
treed022dc299e72425908879b4373be6fde515f471f
parent5dd34b7fc1fa3407a1a2d320eed16d6fdbc824e0
parent733d8df6c4ae6cb56e67cd92f1915326cbe4863e
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>