From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 89986ECAAD2 for ; Fri, 26 Aug 2022 06:27:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244984AbiHZG1F (ORCPT ); Fri, 26 Aug 2022 02:27:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52676 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229556AbiHZG1D (ORCPT ); Fri, 26 Aug 2022 02:27:03 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D60B31EAC5 for ; Thu, 25 Aug 2022 23:27:02 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 701FF61B30 for ; Fri, 26 Aug 2022 06:27:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22083C433C1; Fri, 26 Aug 2022 06:27:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1661495221; bh=PEm6nkpgGyCzO6V+kEv609pInICphfpfckFNSGF655s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bEc/KqHOF0O+m0+ak1rAJsiyRj27ZXgkO+6k5ykA0r884Hy2Nd1Z8JzUJsKPpKG86 BItJ1yXoyCmgYcGzU98cqsB64mwpeCUUQoNrd9r8x09nx8XnMiciyYJ0rzZk2gM10H GsKyG1sj5IwpbyGbLHlbh4lrJjEFyJDfR1ZJ1SYkHYY763hVy6vLu9bP7zoXNMDSpr 4bfCYHERDDAvabQFNExbXC91vUUXEauntASKEtgZcTXlnxkKiSuh61FAEz5dF1Kvz9 xwh44EitE5Ca+hE9wSzT1U8+XVadRwvqVxYcfkp5+gVAP1QFEarVnjZmGtRHSS4tUf geAB5wSBOoI/A== Date: Fri, 26 Aug 2022 09:26:57 +0300 From: Leon Romanovsky To: Jakub Kicinski Cc: Steffen Klassert , "David S. Miller" , Eric Dumazet , Herbert Xu , netdev@vger.kernel.org, Paolo Abeni , Raed Salem , Saeed Mahameed Subject: Re: [PATCH xfrm-next v3 0/6] Extend XFRM core to allow full offload configuration Message-ID: References: <20220825143610.4f13f730@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220825143610.4f13f730@kernel.org> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Aug 25, 2022 at 02:36:10PM -0700, Jakub Kicinski wrote: > On Tue, 23 Aug 2022 16:31:57 +0300 Leon Romanovsky wrote: > > * I didn't hear any suggestion what term to use instead of > > "full offload", so left it as is. It is used in commit messages > > and documentation only and easy to rename. > > * Added performance data and background info to cover letter > > * Reused xfrm_output_resume() function to support multiple XFRM transformations > > * Add PMTU check in addition to driver .xdo_dev_offload_ok validation > > * Documentation is in progress, but not part of this series yet. > > Since the use case is somewhat in question, perhaps switch to RFC > postings until the drivers side incl. tc forwarding is implemented? Proposed driver implementation works fine with eswitch representors. All our flow steering magic is performed on local table entry and it ensures that representors receives/sends "clean" traffic. We are using the following configuration snippet to achieve that. --------------------------------------------------------------------- #!/bin/bash P0_OUTER_REMOTE_IP=192.168.50.2 P0_OUTER_LOCAL_IP=192.168.50.1 PF0=enp8s0f0 VF0_REP=enp8s0f0_0 set -v # Configure IP and turn VF_REP on ifconfig $PF0 $P0_OUTER_LOCAL_IP/24 up ifconfig $VF0_REP up # Clean all TC rules, start fresh tc qdisc del dev enp8s0f0 ingress >/dev/null 2>&1 tc qdisc del dev enp8s0f0_0 ingress >/dev/null 2>&1 # Make sure steering mode is dmfs(FW) and eswitch encap is none devlink dev param set pci/0000:08:00.0 name flow_steering_mode value dmfs cmode runtime devlink dev eswitch set pci/0000:08:00.0 mode legacy devlink dev eswitch set pci/0000:08:00.0 encap none devlink dev eswitch set pci/0000:08:00.0 mode switchdev sleep 2 tc qdisc add dev enp8s0f0 ingress tc qdisc add dev enp8s0f0_0 ingress # Add TC rules tc filter add dev $PF0 parent ffff: protocol 802.1q chain 0 flower vlan_id 10 vlan_ethtype 802.1q cvlan_id 5 action vlan pop action vlan pop action mirred egress redirect dev $VF0_REP tc filter add dev $VF0_REP parent ffff: protocol all chain 0 flower action vlan push protocol 802.1q id 5 action vlan push protocol 802.1q id 10 action mirred egress redirect dev $PF0 tc filter show dev $PF0 ingress ---------------------------------------------------------------------------------------------------- We also don't offload anything related to routing as we can't differentiate between local traffic. > Also the perf traces, I don't see them here. It is worth to separate it to standalone discussion with a title: "why crypto is not fast enough?". I don't think that mixed discussions about full offload which Steffen said that he is interested and research about crypto bottlenecks will be productive. These discussions are orthogonal. Thanks