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 CC1F4C43334 for ; Thu, 7 Jul 2022 17:29:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235945AbiGGR3c (ORCPT ); Thu, 7 Jul 2022 13:29:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39030 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236406AbiGGR3Z (ORCPT ); Thu, 7 Jul 2022 13:29:25 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 477D020F69 for ; Thu, 7 Jul 2022 10:29:24 -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 D34D361458 for ; Thu, 7 Jul 2022 17:29:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1AE7EC3411E; Thu, 7 Jul 2022 17:29:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657214963; bh=hzTgXHxgJoHgC9UZ4FzsvDgBZh9NWdHDv3k0xZGQbk8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=L3HNQ45qRnnI7rd2sQVLR3J5JL67Cn54LOSYKo2pToe+3jFLtYEeeiSix/CdhZAug OOY2lcJOh8JpXNuDAS5epYolLMFIuNYVW1J5yWO+fkCTC0IBqT8ftVWDE092xelrzV Fh1uOdI6Yi9r061TgTZhxQznC+/BvP8BxXygPQFZAi48Ozz5NNB1xRMJiohJR8ECaC Tz6Jk0zHqTaJ13pKiqA4wgSmwR0rHDkCi8bs2IinTTHbbWk6lHAnDV3ZNbWgPtIKDD Vn9Nq0dKzNSmtcxsNZD+7l7rQ6XXKaKpEMuLs2Nb/QNTqDDMr501ymgXt+c4ulbE2c 8SGA9xGloSMdA== Date: Thu, 7 Jul 2022 10:29:22 -0700 From: Saeed Mahameed To: Jakub Kicinski Cc: "David S. Miller" , Paolo Abeni , Eric Dumazet , Saeed Mahameed , netdev@vger.kernel.org, Tariq Toukan , Maxim Mikityanskiy Subject: Re: [net-next 10/15] net/tls: Perform immediate device ctx cleanup when possible Message-ID: <20220707172922.loqztmiwwij3ilgy@sx1> References: <20220706232421.41269-1-saeed@kernel.org> <20220706232421.41269-11-saeed@kernel.org> <20220706192107.0b6fe869@kernel.org> <20220707065114.4tdx6f2lxig6lsof@sx1> <20220707091442.01354da7@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20220707091442.01354da7@kernel.org> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 07 Jul 09:14, Jakub Kicinski wrote: >On Wed, 6 Jul 2022 23:51:14 -0700 Saeed Mahameed wrote: >> On 06 Jul 19:21, Jakub Kicinski wrote: >> >On Wed, 6 Jul 2022 16:24:16 -0700 Saeed Mahameed wrote: >> >> From: Tariq Toukan >> >> >> >> TLS context destructor can be run in atomic context. Cleanup operations >> >> for device-offloaded contexts could require access and interaction with >> >> the device callbacks, which might sleep. Hence, the cleanup of such >> >> contexts must be deferred and completed inside an async work. >> >> >> >> For all others, this is not necessary, as cleanup is atomic. Invoke >> >> cleanup immediately for them, avoiding queueuing redundant gc work. >> >> >> >> Signed-off-by: Tariq Toukan >> >> Reviewed-by: Maxim Mikityanskiy >> >> Signed-off-by: Saeed Mahameed >> > >> >Not sure if posting core patches as part of driver PRs is a good idea, >> >if I ack this now the tag will not propagate. >> >> I agree, how about the devlink lock removal ? same thing ? > >I didn't have the same reaction to the devlink part, perhaps because >of the clear driver dependency there and the fact we discussed that >work thoroughly before. > >Looking at it again it seems like the problem is that these are really >two independent series squashed together, no? Multiple driver features >mixed up in a series is fine but when changing the core let's stick to >clearer separation. > >The objective is to get reviewers engaged, and it's really easy to miss >the core changes among the driver ones in a large multi-purpose series. > I see, i will make the separation when I have core patches. >On the topic of PRs, does it matter to you if the core changes are >posted as a PR? I presume it's okay for those to come out as a normal >series with a proper subject and applied from the list? No i don't mind that at all, it just means that some patchsets will have to go different path than what i have for mlx5, not a big deal