From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C6A3143CA0; Wed, 13 Mar 2024 16:43:39 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B71C742DD5; Wed, 13 Mar 2024 16:43:39 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) by mails.dpdk.org (Postfix) with ESMTP id 60C8240298 for ; Wed, 13 Mar 2024 16:43:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1710344618; x=1741880618; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=iPVSxeoURSQVZcYcSGy+usU+5gsGk1Vr5gWWlt/HZHM=; b=NpKXUR37IDMSXM+pGiMX5jiG4FRys8r+poG5dMBxhJuA2IR1Z1bLZRwd /gUxzB2GCvJNi6Qqgg3uaMrU0K/JiFIX/ba9Yngxdlq3R6LhTWyP5+3fO JCq8a8D9jxOuLH3RSn7QwZbxU+ZGL2SLmPienOKaZcGewG6JH63KHbbzf JJ34DjDFeQGGpYfS8O4aAkJbWAupE0RVdAYXwOM0+AjQ7gR71hHb30bJn H0FbyvP7JqSp/o808wszjP030jktBBd94B3iQj9jXY0E5vCG2WmEibwYD SP8rbOcVMFu7nxu7Lj0p1CeQthXGdAXzYWS11AhzpGPDmHKBiAWjoQT5w Q==; X-IronPort-AV: E=McAfee;i="6600,9927,11011"; a="8062152" X-IronPort-AV: E=Sophos;i="6.07,122,1708416000"; d="scan'208";a="8062152" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Mar 2024 08:43:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,122,1708416000"; d="scan'208";a="11861755" Received: from silpixa00401119.ir.intel.com ([10.55.129.167]) by fmviesa007.fm.intel.com with ESMTP; 13 Mar 2024 08:43:37 -0700 From: Anatoly Burakov To: dev@dpdk.org, Yuying Zhang Cc: john.mcnamara@intel.com, bruce.richardson@intel.com Subject: [PATCH v1 1/1] iavf: document limitation on MTU Date: Wed, 13 Mar 2024 15:43:35 +0000 Message-ID: X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org When configuring a port, the configured MTU will not include VLAN tag size, but the physical function driver will add it automatically if the port has VLAN filtering configured, which may result in seemingly valid MTU to be rejected by the PF. Document the limitation. Signed-off-by: Anatoly Burakov --- doc/guides/nics/intel_vf.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/doc/guides/nics/intel_vf.rst b/doc/guides/nics/intel_vf.rst index ce2bd88cbe..78fd25bad4 100644 --- a/doc/guides/nics/intel_vf.rst +++ b/doc/guides/nics/intel_vf.rst @@ -730,3 +730,13 @@ and has this issue. Set the parameter `--force-max-simd-bitwidth` as 64/128/256 to avoid selecting AVX-512 Tx path. + +ice: VLAN tag length not included in MTU +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +When configuring MTU for a VF, MTU must not include VLAN tag length. In +practice, when kernel driver configures VLAN filtering for a VF, the VLAN +header tag length will be automatically added to MTU when configuring queues. +As a consequence, when attempting to configure a VF port with MTU that, together +with a VLAN tag header, exceeds maximum supported MTU, port configuration will +fail if kernel driver has configured VLAN filtering on that VF. -- 2.43.0