From patchwork Mon Oct 23 18:58:05 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Kicinski X-Patchwork-Id: 829570 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="BaJbC8Go"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3yLQfD6bStz9sPt for ; Tue, 24 Oct 2017 05:58:28 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751799AbdJWS60 (ORCPT ); Mon, 23 Oct 2017 14:58:26 -0400 Received: from mail-pg0-f41.google.com ([74.125.83.41]:46212 "EHLO mail-pg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751673AbdJWS6Z (ORCPT ); Mon, 23 Oct 2017 14:58:25 -0400 Received: by mail-pg0-f41.google.com with SMTP id k7so12490515pga.3 for ; Mon, 23 Oct 2017 11:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=JSdWFIiokn9vZDVwUeG7jyAt9TZJesA/AzD0wx1oxF4=; b=BaJbC8GoOpjwKJ3lZZXAOqHu8G17UMgBh9phHb86nw4XC3ICEEZhMAEMFHwG73cQDC 3okdXedrjao0tbew4utT8nfdurP+qSrAt2Smk0HEEhrE0CONt8e4WSwzaiLORFS4kiFL 8hC/3g3EAhGqfz4FPXfKWpdrAwH1oMyLjY4qcGEpacbWa2Uq6VA9mLFA9dQtVHP/vQp5 YpxK4tqBeqioVb5rivRwYHyZTVvQUdh3/tw7H6puVcodsO9PDgWJeTfR3MMsZm/g8zsl x3mrIR2eYW4e/qqoeybw+PbcYZxcu16ibRnqFLaeS7EW1asaf1fh3WFyxwabp3Y8S/ej Sbjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=JSdWFIiokn9vZDVwUeG7jyAt9TZJesA/AzD0wx1oxF4=; b=jRiYYmUHzyFHQGBU+2plt6IyHFlZvqRUN9pLvG2lV+VIlZwuzgGq5d9ICke+fNtXxN t5y2OIXGoUKAO3twFlNtPGE4XAQejQekG+sChO5sf8CrDJJgyFLulnD3l9S7Avus+STn H1qXymkzWVljA0bgZy3qXwILbKsr4NrE9d8LVL4i44HCvcFQmQw1rzvRsbdXVSDK+WrO gAQzOe8eor2Fun+o5Da32ZLf9DasHCVhGz+SpM95LcOdkBsZHZRHlUkkwO7OXYQi24Y7 SJXg37zlZA5VXLDOfhLi6SiJKSWQB8NnBlnAHOuwrQtUBwauPm882XtOeKGEAZw+OBEc Oi6g== X-Gm-Message-State: AMCzsaUm/QfMv8EnMcHXZ+tBq1hjSswdWxFozsCwtZsTgrzopdlx4INI We8zNoEkZVtaGkcPsqExBKY6nv3m X-Google-Smtp-Source: ABhQp+TpNz56G5WpUlgLoEX+a8taplC2V4/5MecgqqiMs2m1iKBaPY6DRQucp2Ruk1wIHzXL+t1d6g== X-Received: by 10.99.51.205 with SMTP id z196mr10013339pgz.374.1508785104782; Mon, 23 Oct 2017 11:58:24 -0700 (PDT) Received: from jkicinski-Precision-T1700.netronome.com ([75.53.12.129]) by smtp.gmail.com with ESMTPSA id x11sm11599255pgq.29.2017.10.23.11.58.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 Oct 2017 11:58:24 -0700 (PDT) From: Jakub Kicinski To: netdev@vger.kernel.org Cc: oss-drivers@netronome.com, Jakub Kicinski Subject: [PATCH net-next 0/9] nfp: bpf: stack support in offload Date: Mon, 23 Oct 2017 11:58:05 -0700 Message-Id: <20171023185814.4797-1-jakub.kicinski@netronome.com> X-Mailer: git-send-email 2.14.1 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi! 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. Jakub Kicinski (9): nfp: bpf: add helper for emitting nops nfp: bpf: refactor nfp_bpf_check_ptr() nfp: bpf: add stack write support nfp: bpf: add stack read support nfp: bpf: optimize the RMW for stack accesses nfp: bpf: allow stack accesses via modified stack registers nfp: bpf: support accessing the stack beyond 64 bytes nfp: bpf: support stack accesses via non-constant pointers nfp: bpf: optimize mov64 a little drivers/net/ethernet/netronome/nfp/bpf/jit.c | 357 +++++++++++++++++++++- drivers/net/ethernet/netronome/nfp/bpf/main.h | 8 + drivers/net/ethernet/netronome/nfp/bpf/offload.c | 8 + drivers/net/ethernet/netronome/nfp/bpf/verifier.c | 64 +++- drivers/net/ethernet/netronome/nfp/nfp_asm.h | 5 + 5 files changed, 420 insertions(+), 22 deletions(-)