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 X-Spam-Level: X-Spam-Status: No, score=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AFA81C47082 for ; Mon, 7 Jun 2021 19:37:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8F15461185 for ; Mon, 7 Jun 2021 19:37:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231283AbhFGTj1 (ORCPT ); Mon, 7 Jun 2021 15:39:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:45272 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230311AbhFGTj0 (ORCPT ); Mon, 7 Jun 2021 15:39:26 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9401361002; Mon, 7 Jun 2021 19:37:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623094654; bh=8z0GAGomSF07idVWVZFmWXb5MzMYDYxVXjK/Xq55yi4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=VdGqqBrRynz5fBNMiP/8drz9R75o27py2fVr/AG3SD77U/Dpd60b0Z9PQXTbCvA+w XRfCWvN7D9Dk3yJ2aKgS/Ke/7FFMJPo4UoBudApAM7DqmfH1MYjqPXJQp62WRbyEpX K5OxWBBcTIV2IYaS/91VMwNyflNbnU7xXuARx/s0/zKgPL4eLk3vcTo55JChV6oWI0 NQRADMp2TFrqxCk8PovinSm+R+OoJ4z/iU1eLu7QWIYpB6E2VMNQTserA4FSDmgd6D Q8BbK/ds85Pw8VyxwoWhrvIe7ajBJrj2LTp+CeEtgisYqtCZG6UnN8e0JNfMD6XCBh CcrBAajtmOGEQ== Date: Mon, 7 Jun 2021 12:37:33 -0700 From: Jakub Kicinski To: Tariq Toukan Cc: Tariq Toukan , "David S. Miller" , netdev@vger.kernel.org, Moshe Shemesh , Boris Pismenny , Saeed Mahameed , Maxim Mikityanskiy Subject: Re: [RFC PATCH 0/6] BOND TLS flags fixes Message-ID: <20210607123733.16fb8317@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> In-Reply-To: References: <20210526095747.22446-1-tariqt@nvidia.com> <20210526174714.1328af13@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <8182c05b-03ab-1052-79b8-3cdf7ab467b5@gmail.com> <20210527105034.5e11ebef@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sun, 6 Jun 2021 17:02:49 +0300 Tariq Toukan wrote: > > Regarding UPPER_DISABLES: > > I propose using it here as an attempt to give the bond device some > > control over kTLS offloaded connections, to avoid cases where: > > (*) UPPER.ktls_device_offload==OFF > > (*) LOWER.ktls_device_offload==ON > > (*) Newly created connections are offloaded!! Simply ignoring and > > bypassing the UPPER device state (this is how .ndo_sk_get_lower_dev works). > > > > This is not my preferred solution though. > > I think we should reconsider introducing bond implementation for "struct > > tlsdev_ops" callbacks, which gives bond interface full control and > > awareness to new TLS connections. > > If you're fine with the direction, I can prepare a new series that adds > "struct tlsdev_ops" callbacks implementation for bond, instead of the > "UPPER_DISABLES solution" above. > > What do you think? I think a design which requires teaching middle layer drivers about individual hardware offloads for ULPs is poor, brittle and hard to reason about. But historically we seem to have acted in an ad-hoc fashion, so I won't hold it against you if you prefer to keep the whack-a-mole going.