From patchwork Tue Feb 6 03:37:54 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Brady X-Patchwork-Id: 1895494 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=osuosl.org header.i=@osuosl.org header.a=rsa-sha256 header.s=default header.b=Gl9A0Pwr; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=osuosl.org (client-ip=2605:bc80:3010::137; helo=smtp4.osuosl.org; envelope-from=intel-wired-lan-bounces@osuosl.org; receiver=patchwork.ozlabs.org) Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4TTTfc05DDz23gT for ; Tue, 6 Feb 2024 14:45:27 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 7D5F3418AA; Tue, 6 Feb 2024 03:45:25 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7D5F3418AA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1707191125; bh=9LbJYUSgMOba8icxYuj/3AcwKfoj5lN3qDaNU2bZYvM=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc:From; b=Gl9A0PwrWUHzqqpNsQBSCMBtMJbZhTeMuaAYCxRjSDQC603ztBpt6LVA3cKK5GAFC h7GMmsHVfivN+LUfVVemmH8BGNPwbeyF2G84jvz/j/aYKNMglj3F0SFgRt4nisfFLC B3RrrToBHNbDHVf30lWZcJdozc2cDuY3FyV3HsMROQKWf2iAQD+bJUekakTJKl9A6s mfQj5JimgJG63+0Zi8E02xL/2+0rvKwMk9RqqXDp6iaiAB75qSc9iUaAmdOg+OQD/C TX5hWMd1zXa7hzAy/a+NJS7UUAA5j43kFAIq2UmqAYhTjxxv301nyNYLqKpeSK1gep PLtJ16vWx/hkw== X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mh6AKnW3jk1V; Tue, 6 Feb 2024 03:45:24 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by smtp4.osuosl.org (Postfix) with ESMTP id 8E84E418AF; Tue, 6 Feb 2024 03:45:24 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8E84E418AF X-Original-To: intel-wired-lan@lists.osuosl.org Delivered-To: intel-wired-lan@lists.osuosl.org Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by ash.osuosl.org (Postfix) with ESMTP id 7A9FD1BF215 for ; Tue, 6 Feb 2024 03:45:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 5EE3560F3D for ; Tue, 6 Feb 2024 03:45:22 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5EE3560F3D X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTHCP6wwCbyS for ; Tue, 6 Feb 2024 03:45:21 +0000 (UTC) X-Greylist: delayed 428 seconds by postgrey-1.37 at util1.osuosl.org; Tue, 06 Feb 2024 03:45:21 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6358160AF0 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) by smtp3.osuosl.org (Postfix) with ESMTPS id 6358160AF0 for ; Tue, 6 Feb 2024 03:45:21 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6600,9927,10975"; a="824747" X-IronPort-AV: E=Sophos;i="6.05,246,1701158400"; d="scan'208";a="824747" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Feb 2024 19:38:14 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.05,246,1701158400"; d="scan'208";a="5653855" Received: from dev1-atbrady.jf.intel.com ([10.166.241.35]) by orviesa004.jf.intel.com with ESMTP; 05 Feb 2024 19:38:13 -0800 From: Alan Brady To: intel-wired-lan@lists.osuosl.org Date: Mon, 5 Feb 2024 19:37:54 -0800 Message-Id: <20240206033804.1198416-1-alan.brady@intel.com> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1707191121; x=1738727121; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=SivssqEd2AifeIrqAszgd/JFRTzLlRswVDVW8rQyOZw=; b=iQ0NzCA7Ov68pBkl09zT3bYAVZYDS8BJS2kxOkYo+Y3YViIWDA8JNn3b 4CidJoNO49Lj94rAsMkg0LBN/r7V8MFO0N3mh6cqhBD1Q6gi5ZfDnZfdJ lnwQFL/joTb7MqawNcpgLK9IZCazwKfCHGN7H8Wj6vxxPTgLHCgrS4EJ1 bMWXtd/NHr9ajDRubhwfSX/vRGdY2f4rDxi8DFLuxUQM923znozDya42s Rqc8jMCUvLMD2KpgAqo+ymR88wqlSD3n4t/hNH3yQ3wEvkF3GTDXjlYUT hHCPqLP0quo62wBGx5GWXu2XVZIpG8Rl8sMoP3/vBf+FpLXZ+tJqYSsNm w==; X-Mailman-Original-Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=iQ0NzCA7 Subject: [Intel-wired-lan] [PATCH v4 00/10 iwl-next] idpf: refactor virtchnl messages X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: willemdebruijn.kernel@gmail.com, netdev@vger.kernel.org, aleksander.lobakin@intel.com, Alan Brady , przemyslaw.kitszel@intel.com, igor.bagnucki@intel.com Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" The motivation for this series has two primary goals. We want to enable support of multiple simultaneous messages and make the channel more robust. The way it works right now, the driver can only send and receive a single message at a time and if something goes really wrong, it can lead to data corruption and strange bugs. This works by conceptualizing a send and receive as a "virtchnl transaction" (idpf_vc_xn) and introducing a "transaction manager" (idpf_vc_xn_manager). The vcxn_mngr will init a ring of transactions from which the driver will pop from a bitmap of free transactions to track in-flight messages. Instead of needing to handle a complicated send/recv for every a message, the driver now just needs to fill out a xn_params struct and hand it over to idpf_vc_xn_exec which will take care of all the messy bits. Once a message is sent and receives a reply, we leverage the completion API to signal the received buffer is ready to be used (assuming success, or an error code otherwise). At a low-level, this implements the "sw cookie" field of the virtchnl message descriptor to enable this. We have 16 bits we can put whatever we want and the recipient is required to apply the same cookie to the reply for that message. We use the first 8 bits as an index into the array of transactions to enable fast lookups and we use the second 8 bits as a salt to make sure each cookie is unique for that message. As transactions are received in arbitrary order, it's possible to reuse a transaction index and the salt guards against index conflicts to make certain the lookup is correct. As a primitive example, say index 1 is used with salt 1. The message times out without receiving a reply so index 1 is renewed to be ready for a new transaction, we report the timeout, and send the message again. Since index 1 is free to be used again now, index 1 is again sent but now salt is 2. This time we do get a reply, however it could be that the reply is _actually_ for the previous send index 1 with salt 1. Without the salt we would have no way of knowing for sure if it's the correct reply, but with we will know for certain. Through this conversion we also get several other benefits. We can now more appropriately handle asynchronously sent messages by providing space for a callback to be defined. This notably allows us to handle MAC filter failures better; previously we could potentially have stale, failed filters in our list, which shouldn't really have a major impact but is obviously not correct. I also managed to remove fairly significant more lines than I added which is a win in my book. Additionally, this converts some variables to use auto-variables where appropriate. This makes the alloc paths much cleaner and less prone to memory leaks. We also fix a few virtchnl related bugs while we're here. Alan Brady (10): idpf: implement virtchnl transaction manager idpf: refactor vport virtchnl messages idpf: refactor queue related virtchnl messages idpf: refactor remaining virtchnl messages idpf: add async_handler for MAC filter messages idpf: refactor idpf_recv_mb_msg idpf: cleanup virtchnl cruft idpf: prevent deinit uninitialized virtchnl core idpf: fix minor controlq issues idpf: remove dealloc vector msg err in idpf_intr_rel drivers/net/ethernet/intel/idpf/idpf.h | 194 +- .../net/ethernet/intel/idpf/idpf_controlq.c | 7 +- .../ethernet/intel/idpf/idpf_controlq_api.h | 5 + drivers/net/ethernet/intel/idpf/idpf_lib.c | 38 +- drivers/net/ethernet/intel/idpf/idpf_main.c | 3 +- drivers/net/ethernet/intel/idpf/idpf_vf_dev.c | 2 +- .../net/ethernet/intel/idpf/idpf_virtchnl.c | 2175 ++++++++--------- 7 files changed, 1096 insertions(+), 1328 deletions(-) Tested-by: Alexander Lobakin Tested-by: Alexander Lobakin