From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f178.google.com (mail-yw1-f178.google.com [209.85.128.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F0BA5315D5B for ; Tue, 16 Jun 2026 20:02:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781640127; cv=none; b=ZFEG6sKqECWpfAFE82PHRF34Rz0uYw1iLyO3uyxnQa9F8gqZcdNuR2r2VDUFgiETS1ieFTl7Re/CFZKsdcizhMZhnCC8sMAJVZzNq7InaO4sYGo0Gu2p58GpNJB9XBHlB1QOOeSFek3DuMDmKurhli2SgqoSDeR9a7ESM6ES7BA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781640127; c=relaxed/simple; bh=N+AwLbjOsB40eV73kvmFLqHwW8jHiuirwy8UCA2x9eY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=k1pnrM5cQNiWivyvV+/wiBBprfrSEtlrud9AXfTDXCCdjclx/cZJQu5BymORYBHpsVfnoHGXRanx6a6mDRULWYO4wla3CTEHW/dkkp/9rMcxXIGCGKzlL4yxAemAR1tl+t8AaNQuaqN9196EKCNCx5zidsM+PlkMZVl9HaHjcN4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=dCQsVieX; arc=none smtp.client-ip=209.85.128.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dCQsVieX" Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-7e86d46b02dso55846377b3.3 for ; Tue, 16 Jun 2026 13:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781640125; x=1782244925; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=pTBYdMeHq7VVHqws7ev2yyFawcjMuxnArkjcGEAZaXc=; b=dCQsVieXx/wfYhLEyG5m21Ey+GjkVLyaadVtMvJcrDo6pqmIQYDjdIhODVtSug4xwW Uvudayb6y+JyOmHM8HQO+3R1fd1v9EHthHddotehXmMR9R+YP/0mW93BxcE95gU+R78B aXY5+nyeDOoD0aM0+hgT0XIMLXQWTW5WMcgZWLjEwiSPdPzLfNp6yY3MYeDBtRfng0Tq KMr7BnNplXSUubM6BDiklhbR2RSlzHXfwbeSc8A5jl9xnYQxQ/F5B/oF7z2/wU3GlCBO KAM7UF5789mAFVfUdlmYG9amXe9s9A+l7mKYkEtKqXniIcE12qFRmN6R1I+EAmZMl2RA cJgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781640125; x=1782244925; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pTBYdMeHq7VVHqws7ev2yyFawcjMuxnArkjcGEAZaXc=; b=IvGULTfjeoUH9SMvERBNRi3eIyv9Rt0mw1nown9aqTUrxx8M6onrFGw7XjKfZ98Cqa Lc/z3sMb6B3LwHH/51YW8Pr2oJV6EOZm3A0Fu//m4+7d8PqYRKKMrhJ9EVfM2BCKNChS uiC+p5B4BuZUY1U1zkGyqqbEgm8lokmgvUAafTiDAQZSQHug+PYmS2srFU/EMRofroG3 YMvZ1K3cS+VoKWlXIoDF15Xg4OYnO9yb2KnxCcn2xIaeWAB9izdYS2nmyhN3fVkRRF1R Ffj9psD41jBqIuRPfrZXkbxupihSV71+QPWSd1FwMPOpJVaeqWcoZHgg9UH3545S6Cfr HT3g== X-Forwarded-Encrypted: i=1; AFNElJ8ZGpmDfL0CdaxkTZhdnyCFJpsCbOtCAvvgnap0mh4XioRQYs1Wp8u3XynvlA0czyudzp4B8Ic7la+m2mc=@vger.kernel.org X-Gm-Message-State: AOJu0YwtFvaALGrszHbS7jCm4brq0BdOGWqZwiQ06iw369mpKpFgfAc9 v0mFOWRxMntSjs3dZGi3RrWcYaHCW2oL7VSc16rJxprhMmXUGxd+TfRE X-Gm-Gg: Acq92OGL86fqtC1xu9zQdDcZNaqs4FIovJECBhwPPPRzc4pCKk9fRje0unOnMX8AS8/ SPg0Reb5F/IQgvbt6fDUp29WoTq46nmc9q7zl2dhCdHMukZB/U9qdOSCW3aBEeoz9bhYxH6ydF1 rcLVu23GJ7+RicfcdkFZ9Wo7dBn1lJXlSY7KKi3r6skoBXo0WiaAWmXZfnMw6aLV3koJAZk9zc3 YgnlHbPy6U+CXmsdXN3g7Uh/epHpXnZQUOSmAHoyoZqC3IAj/l7o9aqFi/qheGgRW/CidFhCKgN EUwvp7rMP+i8fCeTV7kTqa7MCDMZkZDSJ+CJ03SweDA/rWa+FqMmWnJlFG0eE6MEzPlCNTw9qy9 MRoCMVKgEiJdIvUTUDT7/OnEoVMLSvzbVdZaQ8X010saQFm7Cd9yHg0Gc7Kz6Bl3FrCsUm1jQsA iDL7KpkrGgq+hG1AqT5xK3jaeqBDmERyrsRIMEz4/RswwvSD86x1I8Gd14YbuWgCzQ94NlaS3cq sVBh/9sgjAT+Ryf X-Received: by 2002:a05:690c:6c0e:b0:7fd:b458:7522 with SMTP id 00721157ae682-7fe5e397695mr6300777b3.37.1781640124736; Tue, 16 Jun 2026 13:02:04 -0700 (PDT) Received: from dave-linux-desktop.. (c-68-53-106-116.hsd1.ky.comcast.net. [68.53.106.116]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7fcd0adc434sm24655707b3.22.2026.06.16.13.02.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2026 13:02:04 -0700 (PDT) From: "=?UTF-8?q?Dave=20=F0=9F=A7=94=E2=80=8D=20Butler?=" X-Google-Original-From: =?UTF-8?q?Dave=20=F0=9F=A7=94=E2=80=8D=20Butler?= To: intel-wired-lan@lists.osuosl.org, linux-kernel@vger.kernel.org, aleksander.lobakin@intel.com, anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com Cc: croepha@gmail.com, david.butler@appgate.com Subject: [PATCH net] iavf: cap advertised max_pkt_size at the single-buffer HW limit Date: Tue, 16 Jun 2026 20:01:52 +0000 Message-ID: <20260616200152.1421033-1-david.butler@appgate.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Dave Butler Since commit 5fa4caff59f2 ("iavf: switch to Page Pool") iavf_configure_queues() advertises max_pkt_size to the PF as: max_frame = LIBIE_MAX_RX_FRM_LEN(adapter->rx_rings->pp->p.offset); max_frame = min_not_zero(adapter->vf_res->max_mtu, max_frame); LIBIE_MAX_RX_FRM_LEN (16382) is the multi-descriptor scatter/gather frame ceiling, not a single-queue value, and it exceeds the E810 MAC frame size maximum of 9728. Per the E810 datasheet (613875-009 section 13.2.2.17.1) the Tx frame-size register PRTDCB_TDPUC.MAX_TXFRAME has a maximum of 0x2600 (9728); larger frames are discarded. The in-tree ice driver encodes the same value as ICE_AQ_SET_MAC_FRAME_SIZE_MAX (== LIBIE_MAX_RX_BUF_LEN == 9728), and the VF clamped max_frame to IAVF_MAX_RXBUFFER (9728) before this commit. When the PF advertises vf_res->max_mtu as 0, min_not_zero() leaves max_frame at 16382. The Linux ice PF advertises max_mtu = port MAC frame size (<= 9728), so a VF behind ice never sends more than that. The ESXi "icen" PF on E810 advertises max_mtu as 0, so the VF sends max_pkt_size = 16382, which icen rejects while programming the queue context for VIRTCHNL_OP_CONFIG_VSI_QUEUES (opcode 6): icen_ConfigureTxQueue: VSI 8: Failed to set LAN Tx queue context for absolute Tx queue 64, Error: ICE_ERR_PARAM indrv_SendMsgToVf: VF 0: Failed opcode 6, Error -5 iavf 0000:03:00.0: PF returned error -5 (IAVF_ERR_PARAM) to our request 6 iavf 0000:03:00.0 ethX: NETDEV WATCHDOG: transmit queue N timed out The VF's queues never come up; under SR-IOV passthrough the mis-programmed queue can also trigger a fatal IOMMU fault in the guest. Forcing only max_pkt_size back to 9728 (and leaving the Page Pool rx_buf_len/ databuffer_size untouched) makes the VF come up; databuffer_size is not involved. This was confirmed on two E810 NVM revisions (3.00 and 4.51) and two icen versions (1.14.2.0 and the latest 2.3.3.0): all reject the unpatched VF and accept the patched one, so the trigger is the icen PF behaviour, not the firmware or icen revision. Reported by several users on E810 + ESXi icen with v6.10+ guests: Link: https://community.intel.com/t5/Ethernet-Products/E810-C-iavf-driver-issue-on-Linux-6-12/m-p/1737490 Link: https://access.redhat.com/solutions/6973766 Link: https://knowledge.broadcom.com/external/article/404315/sriov-enabled-vms-network-adaptor-goes-d.html Cap max_frame at the single-buffer hardware limit, restoring the pre-Page-Pool behaviour while keeping the Page Pool rx_buf_len unchanged. Fixes: 5fa4caff59f2 ("iavf: switch to Page Pool") Signed-off-by: Dave Butler --- drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c index 4f2defd2331b..2632eeed776c 100644 --- a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c +++ b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c @@ -382,6 +382,14 @@ void iavf_configure_queues(struct iavf_adapter *adapter) max_frame = LIBIE_MAX_RX_FRM_LEN(adapter->rx_rings->pp->p.offset); max_frame = min_not_zero(adapter->vf_res->max_mtu, max_frame); + /* The PF programs max_pkt_size into the per-queue Rx context "rxmax". + * LIBIE_MAX_RX_FRM_LEN is the multi-descriptor (S/G) frame ceiling + * (16382), but that exceeds the E810 max MAC frame size (9728); some + * PFs reject the out-of-range value with VIRTCHNL_STATUS_ERR_PARAM. + * Cap it at the single-buffer HW limit (== the MAC frame max), + * restoring the pre-Page-Pool behaviour. + */ + max_frame = min(max_frame, LIBIE_MAX_RX_BUF_LEN); if (adapter->current_op != VIRTCHNL_OP_UNKNOWN) { /* bail because we already have a command pending */ base-commit: fbc6a80cb5d3fd4ac4b56e8c9d791dd17be890c4 -- 2.43.0