Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp655355ybt; Fri, 19 Jun 2020 10:18:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw6w2+U9evW332mEw3+LCWFbsQPtNgkcYXz5U9PfvWDYdp30sd/a+w5q5bP4izokOIetTm5 X-Received: by 2002:a17:907:2058:: with SMTP id pg24mr4461448ejb.63.1592587108062; Fri, 19 Jun 2020 10:18:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592587108; cv=none; d=google.com; s=arc-20160816; b=vbdabe38uQfZpU3O7Nt6rZZCwYzhoUgDFL+cHzlZAi+RjuoBCu7QxIquKg0hM3dGe6 EA3tCnMHYd4YcZKEKWmeI0KJIdAwtJG0cP7DwFmTIYq90h0OhlbUiu9sn4a1qf32N7/f ZgJaUEmad1J91WsR3dyRAy2yTUyGQRgGOK3UwvI+SvUDP109bdPXk2OAQ4NQYX7ufCv1 vzLlNTUvNcv53L0npKKtusP2fJgftNZM1Ngy85ZRbXsBlHL55fDj+QD4Dq5B5mqpbCO4 EEl/uEPTMBqOeeFkPOs8y6lrnbUUXgncPqiVdMEoE0XKhhku0RkPordLeZk8hg8r9xkX TRyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=g6sl0V6oSF+ayLjJO92Gb6jDxQHsMRD4h3oSfs3nUus=; b=CdC4G6aWB8HgHcbe7V1KGtPDVBczvrIuvAMXsOoO0W5paaRIsD1R10OEDs9BUKKST0 2a6RtIyDaI7I1WZaIkzoZlYvcwvsBkoebzit9PEwlEjzMQmly8l06GAvdYdsoTB3chhv GwX9oeqqplJEg8f9jSpbez/OhwOL65U5+yMnYB9hlWLbrQSxe7YPgAum/WcDGC6iAtla entAM+xJj9trE4CpVXtHngTnQxVo2QTi+BsH5mU4WP4XNQi7nzdDqEtLKvueVr4nrHG4 XBrHuO4bZ7e17SE22cffxQM6kxn/C878GNR6wZG5kGr4pX1Hub7xSTU114JNRKWCVYEN 4beA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=FTMyTBMM; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dm20si4465498edb.457.2020.06.19.10.18.05; Fri, 19 Jun 2020 10:18:28 -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=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=FTMyTBMM; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732344AbgFSK0f (ORCPT + 99 others); Fri, 19 Jun 2020 06:26:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41658 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732283AbgFSK0e (ORCPT ); Fri, 19 Jun 2020 06:26:34 -0400 Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 54AC2C06174E for ; Fri, 19 Jun 2020 03:26:33 -0700 (PDT) Received: by mail-qt1-x842.google.com with SMTP id g18so6729493qtu.13 for ; Fri, 19 Jun 2020 03:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g6sl0V6oSF+ayLjJO92Gb6jDxQHsMRD4h3oSfs3nUus=; b=FTMyTBMM0WhdezxS9cKagR+7bmzV4MCbxW+PeNlxLWAYveMypleF5j5yWeEHqCKSnm Pql+E4txHJ/+BYxTlolI+gp6gz+Rr4pcpAJVEJV/OWJX7GknKspi92ixJwxzvo8XSOZm nBiK3GgbVeH6mM994YVAK7LfXOWApaDMGWl9zN1q5WgjCzSVHANhEWkOkaOeZd8VxvIg pVzxKNGTZ15ZjJTWhX6IhxBwRpqwiYLMzhzTCTaqdxsaBh3Xoe0PQez+US73lnbzga4Q 1LoxLLp/0JUMPdZp8uPek7N1kQcfPH345HVhNXBs3keIO/eOMrEXvkEkmcwBF113jYTK KjUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g6sl0V6oSF+ayLjJO92Gb6jDxQHsMRD4h3oSfs3nUus=; b=fNVN4xODYLJHgc53HCghfviPwxVk3UXlszCDdsVSD4W25bjgKcjzChfmNULj8mwr2u yDgZ4T+HnQcRmThNgyxzkadYQo2Pxh6YcuQaoEOGma5vd5oy0+fitpNub0kmeF1UYfXF oJuV4xZ0gHakYQtHLR9HFNp831+m8VRHaDi1GyBUOwguasf2rEoY3+Vt5kMMsZhDVv3M ZjK76SYnbmchXGznDQ7s/4OPENQFEco6D1CuasSkePW4jDLEHOUEY9kxf6L7OHZR8kHg YuS4MCm4H0XGL8kltaUkMwrrXTwSfG1mgjXPwDZr1CbkYwbIllMBrFdLOfe8mAItV+Vf iY0w== X-Gm-Message-State: AOAM5330Nd/ed1IoAkBEXhHcxi/F/m/YO//bc4UAh/RfZUJnPFo1v4vm QGiRFV7xIbE9qXxp6G9tMUZDd7ivxi2fZCKvqAw= X-Received: by 2002:ac8:6a08:: with SMTP id t8mr2571945qtr.271.1592562392543; Fri, 19 Jun 2020 03:26:32 -0700 (PDT) MIME-Version: 1.0 References: <20200608210058.37352-1-jarod@redhat.com> <20200610185910.48668-1-jarod@redhat.com> In-Reply-To: <20200610185910.48668-1-jarod@redhat.com> From: Jeff Kirsher Date: Fri, 19 Jun 2020 03:26:21 -0700 Message-ID: Subject: Re: [PATCH net-next v2 0/4] bonding: initial support for hardware crypto offload To: Jarod Wilson Cc: LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 10, 2020 at 1:18 PM Jarod Wilson wrote: > > This is an initial functional implementation for doing pass-through of > hardware encryption from bonding device to capable slaves, in active-backup > bond setups. This was developed and tested using ixgbe-driven Intel x520 > interfaces with libreswan and a transport mode connection, primarily using > netperf, with assorted connection failures forced during transmission. The > failover works quite well in my testing, and overall performance is right > on par with offload when running on a bare interface, no bond involved. > > 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, but the NIC driver changes are minimal and > straight-forward enough that I've included what I think ought to be > enough for mlx5 devices too. > > v2: reordered patches, switched (back) to using CONFIG_XFRM_OFFLOAD > to wrap the code additions and wrapped overlooked additions. > > Jarod Wilson (4): > xfrm: bail early on slave pass over skb > ixgbe_ipsec: become aware of when running as a bonding slave > mlx5: become aware of when running as a bonding slave > bonding: support hardware encryption offload to slaves > > drivers/net/bonding/bond_main.c | 127 +++++++++++++++++- > .../net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 39 ++++-- > .../mellanox/mlx5/core/en_accel/ipsec.c | 6 + > include/net/bonding.h | 3 + > include/net/xfrm.h | 1 + > net/xfrm/xfrm_device.c | 34 ++--- > 6 files changed, 183 insertions(+), 27 deletions(-) Was this ever sent to netdev (the more appropriate ML)? -- Cheers, Jeff