Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1231987ybj; Tue, 5 May 2020 16:01:06 -0700 (PDT) X-Google-Smtp-Source: APiQypIt2lFYHCrp7L46dJ0s7N0+GXHhz5QcEFLC+Tbm+dNCeUIOJyWUxniPPve3o0RLdGEyMpOV X-Received: by 2002:a17:906:6c93:: with SMTP id s19mr4743267ejr.135.1588719666227; Tue, 05 May 2020 16:01:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588719666; cv=none; d=google.com; s=arc-20160816; b=JdNvf1d/daCJLqyIJPSBrq9TTyhihUi4Mq0QB+jMvfx8Q4ewkN0akKvkZul2uhuIQa f9v2/kPYHRVwu0c9SUtXp8I5uxeEQQxSDgtcu6SrH36uxKNJqlHAz63RlqhlV9KkJaX9 4N1bByWbxzdL9cMLy5f5vMz328o1sOsnCT+TICjm9bJApJYXrUnaXeboEuq1/geIkSwu SWxtkRhkrDG69TYHaR40zQv2+y2pAQGlgnmKVbEbo1SWPXdiUv43apRclaOcW2nwrw+e rbzGkQO9YuTwVPyQO3y+vC/sTk7Nw0jhVnux7Ad0KxY5INYjZYhXG+LINz4czaNoJbLG ZK1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=vLmdw3LXI4CtXnPp/sh022YqaVJWK6SleAWQvTfde7A=; b=vDCDPa0nTQUz9TAEOsvGYiN9/y3mNS+y8g5dKwKVDnBoP95mgkzlgLvkloS/AjZ2xT 8RvWqTdDWHRIJl0qFR44wEzdRZ/Ieblj6ugsdJU8CV/4+/DvDjZHBLDfhC2uxkG6sUsT Ly1ghTHtLTugDHF8YSyug9BdYEPA7kLt5GOpVZWP7blV4DfCSBjVvNIMC5nlIIpZGxj7 beDCDkEQEiyRI66HD6ktromNO2p1ELvIU7HRWKah2W2pSsve9SqPBPWlOM2CF4xRU7wm 5683XFj/xtN4yc2Pi/zIEWS3enwMpo8fdeNQVJ9/dDEzTX3EShURBN9UOvqshY+/Wgli dYtg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cd4X4SN5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id op2si54891ejb.395.2020.05.05.16.00.40; Tue, 05 May 2020 16:01:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cd4X4SN5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728717AbgEEW7T (ORCPT + 99 others); Tue, 5 May 2020 18:59:19 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:55392 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728642AbgEEW7S (ORCPT ); Tue, 5 May 2020 18:59:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588719557; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vLmdw3LXI4CtXnPp/sh022YqaVJWK6SleAWQvTfde7A=; b=cd4X4SN5dHyVm5oNWjaMemhL4cGDVXFHjoYJt6vBhtefk5hkaF+LBGZmNu5yVFrEcvVxiW jUYYcaE09QIe1zugH8jl1MGRFUIMdHze6llNtue80G7m1mj8C8umCLtgWQaiENnd5ddBAJ nSBMmUkpvSw5IGRLsgpouHS9p1+LJpg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-20-B6M9_wFJNq6Ytglhin6_Vg-1; Tue, 05 May 2020 18:59:15 -0400 X-MC-Unique: B6M9_wFJNq6Ytglhin6_Vg-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 389A1835B8B; Tue, 5 May 2020 22:59:13 +0000 (UTC) Received: from hp-dl360pgen8-07.khw2.lab.eng.bos.redhat.com (hp-dl360pgen8-07.khw2.lab.eng.bos.redhat.com [10.16.210.135]) by smtp.corp.redhat.com (Postfix) with ESMTP id 592885D9C5; Tue, 5 May 2020 22:59:11 +0000 (UTC) From: Jarod Wilson To: linux-kernel@vger.kernel.org Cc: Jarod Wilson , Jay Vosburgh , Veaceslav Falico , Andy Gospodarek , "David S. Miller" , Jeff Kirsher , Jakub Kicinski , Steffen Klassert , Herbert Xu , netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org Subject: [RFC PATCH net-next v2 0/3] bonding: support hardware crypto offload Date: Tue, 5 May 2020 18:58:35 -0400 Message-Id: <20200505225838.59505-1-jarod@redhat.com> In-Reply-To: <20200504145943.8841-1-jarod@redhat.com> References: <20200504145943.8841-1-jarod@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is an initial "proof of concept" functional implementation for doing pass-through of hardware encryption from bonding device to capable slaves= . This was tested using an ixgbe-driven Intel x520 NIC with libreswan and a transport mode connection, on top of an active-backup bond, using netperf and downing an interface during. Failover takes a moment, but does work, and overall performance is right on par with offload when running on a bare interface. Caveats: this is ONLY enabled for active-backup, because I'm not sure how one would manage multiple offload handles for different devices all running at the same time in the same xfrm, and it relies on some minor changes to both the xfrm code and slave device driver code to get things to behave, and I don't have immediate access to any other hardware that could function similarly to update driver code accordingly. I'm hoping folks with more of an idea about xfrm have some thoughts on ways to make this cleaner, and possibly support more bonding modes, but I'm reasonably happy I've made it this far. :) v2: fix build with CONFIG_XFRM_OFFLOAD disabled and rebase on latest net-next tree bonding changes CC: Jay Vosburgh CC: Veaceslav Falico CC: Andy Gospodarek CC: "David S. Miller" CC: Jeff Kirsher CC: Jakub Kicinski CC: Steffen Klassert CC: Herbert Xu CC: netdev@vger.kernel.org CC: intel-wired-lan@lists.osuosl.org Jarod Wilson (3): xfrm: bail early on slave pass over skb ixgbe_ipsec: become aware of when running as a bonding slave bonding: support hardware encryption offload to slaves drivers/net/bonding/bond_main.c | 111 +++++++++++++++++- .../net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 39 ++++-- include/net/bonding.h | 3 + include/net/xfrm.h | 1 + net/xfrm/xfrm_device.c | 34 +++--- 5 files changed, 160 insertions(+), 28 deletions(-) --=20 2.20.1