From patchwork Tue Oct 4 04:44:34 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Matthew Ruffell X-Patchwork-Id: 1685758 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=hbHRkiar; dkim-atps=neutral Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4MhQ9b0czcz23jR for ; Tue, 4 Oct 2022 15:45:05 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ofZnT-0005VC-Ck; Tue, 04 Oct 2022 04:44:47 +0000 Received: from smtp-relay-internal-1.internal ([10.131.114.114] helo=smtp-relay-internal-1.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1ofZnS-0005V0-6V for kernel-team@lists.ubuntu.com; Tue, 04 Oct 2022 04:44:46 +0000 Received: from mail-pf1-f197.google.com (mail-pf1-f197.google.com [209.85.210.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id B3AE53F367 for ; Tue, 4 Oct 2022 04:44:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1664858685; bh=ZMLDzJ8qE7+/zuk8xrrAzGDkXjW5vAxpA8bWuvOozMs=; h=From:To:Subject:Date:Message-Id:MIME-Version:Content-Type; b=hbHRkiarvmgd/0hcnE2NlukODAKMth1F1uOryLoKBif6Z9eAF/r7FP+WphKuls5W0 Ji+0jXsK+AZnDAbAYm7oI+vir+M5NpM+sAb4gSzYM4cKH/hCIt8L1jNOtIjEQqcQiA nC8SfcR94FxJQ74x0UsY+mnv9/+jH1V7wTj1EmA7X3DHlm5IZcTyEgD+RDqfq5J3Sy 4tmkoWo8rdeFeuitkdQeDp1mfzgwYyvLWf7SotI83UMaTz1R9sD0Wpj9r3AQaqYRLz PdYrM4S15Cxk+chsivQnT5tA3ZSXmuTBeQ/ugTfWsAoqtTOZjoHA7LxEzTckDlmcBe 8ZZ6jLjAL6ymQ== Received: by mail-pf1-f197.google.com with SMTP id t7-20020a62ea07000000b005619a832f68so1967982pfh.11 for ; Mon, 03 Oct 2022 21:44:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date; bh=ZMLDzJ8qE7+/zuk8xrrAzGDkXjW5vAxpA8bWuvOozMs=; b=YBpMJWBewDwmw0Oxh9ggtu/Xf1YkA6dUQE27i7BEBR4cYtfZUQDbtI3nIoldwzbegj Emy0NTfnEyLiu6flV6Kw0VicXmVrmaJraJ/j800/xzttD519JDnDKMOKNP1NczA14LwK O1Y76Uecai/X84g1+WvzW6eIJomK3YqIh2cNlAahonamhtZzmR5vkv1U3y7HZPY8DmL6 lW32+6Vchvn06dQPuuFHh8czLS52MGohN4aYRrzx0wAX0BnOjd2yWqJ3iKHrp2QduyfM Hsl/bcJxAFkvcWAxQ2mzbz17QuYM9ydTRet+CV6TlvcNsYbnzGH2uw/5xe6azILlOgyK 8dnw== X-Gm-Message-State: ACrzQf0Fz91K+OkWJ7UZdXJX7QPh296OpCt8l/nXC6Gv24R5kg52q95T CBrl2YkEoCGbDAMdiQR4ZNHRpAPUXnX8iitBYgPJ+4GX/P/rLWMXyS3bu6nv0eR70Dtj7vygcfV 0ECMx2IaWL7+eu6OeJ7XLKM1b3H+geICo8nOZsE6feQ== X-Received: by 2002:a17:90b:4d8a:b0:205:a847:d8ba with SMTP id oj10-20020a17090b4d8a00b00205a847d8bamr15791598pjb.93.1664858684183; Mon, 03 Oct 2022 21:44:44 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4MUpaMn3yG9/rCyvOEVls+kmGiKlLdWvc9Cv3gYG1nvupUWARXYucjP852YNAOU1frtZcGcA== X-Received: by 2002:a17:90b:4d8a:b0:205:a847:d8ba with SMTP id oj10-20020a17090b4d8a00b00205a847d8bamr15791574pjb.93.1664858683698; Mon, 03 Oct 2022 21:44:43 -0700 (PDT) Received: from desktop.. (125-239-70-54-fibre.sparkbb.co.nz. [125.239.70.54]) by smtp.gmail.com with ESMTPSA id a2-20020aa78e82000000b00561642b6903sm3341433pfr.120.2022.10.03.21.44.41 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Oct 2022 21:44:43 -0700 (PDT) From: Matthew Ruffell To: kernel-team@lists.ubuntu.com Subject: [SRU][F][J][K][PATCH 0/2] iavf: SR-IOV VFs error with no traffic flow when MTU greater than 1500 Date: Tue, 4 Oct 2022 17:44:34 +1300 Message-Id: <20221004044436.15046-1-matthew.ruffell@canonical.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" BugLink: https://bugs.launchpad.net/bugs/1983656 [Impact] Virtual Machines with SR-IOV VFs from an Intel E810-XXV [8086:159b] get no traffic flow and produce error messages in both the host and guest during network configuration. Environment: Ubuntu OpenStack Focal-Ussuri with OVN Host Kernel: v5.15.0-41-generic 20.04 Focal-HWE Guest Kernels: v5.4.x Focal, v5.15.0-41-generic Jammy Host Error Messages: ice 0000:98:00.1: VF 7 failed opcode 6, retval: -5 Guest Error Messages: iavf 0000:00:05.0: PF returned error -5 (IAVF_ERR_PARAM) to our request 6 In the context of these errors "6" refers to the value of VIRTCHNL_OP_CONFIG_VSI_QUEUES It was found in these cases that the VM is able to successfully transmit packets but never receives any and the RX packet drop counters for the VF in "ip link" on the host increase equal to the RX packet count. There is a prior commit e6ba5273d4ede03d075d7a116b8edad1f6115f4d claiming to resolve this error in some cases. It is already included in 5.15.0-41-generic and did not resolve the issue. The following conditions are required to trigger the bug: - A port VLAN must be assigned by the host - The MTU must be set >1500 by the guest There is no workaround, Intel E810 SR-IOV VFs with MTU >1500 cannot be used without these patches. [Fix] iavf currently sets the maximum packet size to IAVF_MAX_RXBUFFER, but on the previous ice driver, it was decremented by VLAN_HLEN to make some space to fit the VLAN header. This doesn't happen on iavf, and we end up trying to use a packet size larger than IAVF_MAX_RXBUFFER, causing the IAVF_ERR_PARAM error. The fix is to change the maximum packet size from IAVF_MAX_RXBUFFER to max_mtu received from the PF via GET_VF_RESOURCES msg. Also pick up a necessary commit for i40e to announce the correct maximum packet size by GET_VF_RESOURCES msg. This has been fixed by the following commits: commit 399c98c4dc50b7eb7e9f24da7ffdda6f025676ef Author: Michal Jaron Date: Tue Sep 13 15:38:35 2022 +0200 Subject: iavf: Fix set max MTU size with port VLAN and jumbo frames Link: https://github.com/torvalds/linux/commit/399c98c4dc50b7eb7e9f24da7ffdda6f025676ef commit 372539def2824c43b6afe2403045b140f65c5acc Author: Michal Jaron Date: Tue Sep 13 15:38:36 2022 +0200 Subject: i40e: Fix VF set max MTU size Link: https://github.com/torvalds/linux/commit/372539def2824c43b6afe2403045b140f65c5acc A test kernel is available in the following ppa: https://launchpad.net/~arif-ali/+archive/ubuntu/sf00343742 If you install the test kernel to a compute host and VM, when you attach a VF and set the MTU to 9000, it succeeds, and traffic can flow. [Test Plan] Create a Focal VM and assign an Intel E810 (ice) SR-IOV VF with a port vlan: Openstack works, as does creating a VM directly with uvtool/libvirt. $ uvt-kvm create focal-test release=focal Using the document to understand SRIOV basics in the link below https://www.intel.com/content/www/us/en/developer/articles/technical/configure-sr-iov-network-virtual-functions-in-linux-kvm.html The following command show all the bus info for all the network devices $ lshw -c network -businfo Choose one, as shown below pci@0000:17:01.4 ens2f0v4 network Ethernet Adaptive Virtual Function We can then add the following into the XML definition via “virsh edit focal-test”
Then we stop and start the VM via "virsh shutdown focal-test" and then "virsh start focal-test". We can then login to the VM using the command below $ uvt-kvm ssh focal-test Once you have logged in, run the following ip parameters $ sudo ip a a 192.168.1.7/24 dev enp7s0 $ sudo ip link set up dev enp7s0 $ sudo ip link set mtu 9000 dev enp7s0 Now check dmesg, and we will find the error [ 61.529605] iavf 0000:07:00.0: PF returned error -5 (IAVF_ERR_PARAM) to our request 6 Setting the IP and bringing the link up [ 36.228877] iavf 0000:07:00.0 enp7s0: NIC Link is Up Speed is 25 Gbps Full Duplex [ 36.228887] IPv6: ADDRCONF(NETDEV_CHANGE): enp7s0: link becomes ready [ 45.740100] crng init done [ 45.740102] random: 7 urandom warning(s) missed due to ratelimiting Then setting the MTU [ 61.433706] iavf 0000:07:00.0: Received 16 queues, but can only have a max of 4 [ 61.433707] iavf 0000:07:00.0: Fixing by reducing queues to 4 [ 61.529605] iavf 0000:07:00.0: PF returned error -5 (IAVF_ERR_PARAM) to our request 6 [ 61.552890] iavf 0000:07:00.0 enp7s0: NIC Link is Up Speed is 25 Gbps Full Duplex There is a test kernel available in the following ppa: https://launchpad.net/~arif-ali/+archive/ubuntu/sf00343742 If you install the test kernel, setting the MTU to 9000 works as expected and traffic can flow. [Where problems could occur] We are changing how maximum MTU is calculated and applied to VFs in the iavf and i40e drivers. Currently, any MTU over 1500 does not work at all when a port VLAN is enabled, but if someone has somehow got their setup to work, they may see a difference in MTU with these patches applied. The iavf and i40e drivers are a popular driver, and if a regression were to occur, initialisation and bringup of these network devices and VFs might fail. Most users currently using MTUs of 1500 are unlikely to see any difference or be at risk of regression. [Other Info] Both patches were developed by intel, and have been accepted into v6.0-rc7 and are already released into upstream stable v5.4.215, v5.15.71 and v5.19.12. These patches are well tested by the community and considered safe. Michal Jaron (2): iavf: Fix set max MTU size with port VLAN and jumbo frames i40e: Fix VF set max MTU size .../ethernet/intel/i40e/i40e_virtchnl_pf.c | 20 +++++++++++++++++++ .../net/ethernet/intel/iavf/iavf_virtchnl.c | 7 +++++-- 2 files changed, 25 insertions(+), 2 deletions(-) Acked-by: Tim Gardner Acked-by: Stefan Bader