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 0D5C945BFE; Mon, 28 Oct 2024 16:51:56 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E4EA44113C; Mon, 28 Oct 2024 16:51:55 +0100 (CET) Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by mails.dpdk.org (Postfix) with ESMTP id 8D9F941133 for ; Mon, 28 Oct 2024 16:51:54 +0100 (CET) Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-20c70abba48so34276815ad.0 for ; Mon, 28 Oct 2024 08:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1730130714; x=1730735514; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=oxqmt6uPDxYr23YfFUpQRz7dtWt1wokKKqYIB98A9YI=; b=NcvtICJk6PIFtHH8Rg1gOx1FX9nDY5OAELVdUBQktNRfQa8b1cT9+dHfWnYxVgDoYm EjouX9FMETv9VlwiFxz06umemDesUHdv7N+J2hxL6ZnYK3qU/optsl3cilNgOQ8FRM/c mGlAELmeN7wuf+07W4AraFpeh4wue0PbQnsr6si03V69LcrLaBnQAtOLLvqv1dAcTULx gh07x9/QmVn0TetEs1BVVft2xmZUTySlWzcmzd5DLLp7VeTcZ4uZjeKFACiNVRGh9DJO kqyOrANWPPLjRf9pEWF21F7Xqrv2kdLGUDD4pwyTW2ukPhxmUxGEJ+vfFRVWzkVEmXx6 bLkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730130714; x=1730735514; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oxqmt6uPDxYr23YfFUpQRz7dtWt1wokKKqYIB98A9YI=; b=MDrVw1igDYFsD+KD1GfckOf92HSAORX3sIQWmnlcMV4YA2UOTIRpLSHESdvBWZdbKu WVM4rqNqSv9W3CZbbEGRLGm2oltxAFwUm3mKwRGi1CCas8H9y9FWZNQM0/emVEu+2Ke5 vs0+MUL4sE3zNDx9SetZMpakecb9gGXNceowYfnR+AbKIa+WOvCRDnQDf+mt+9z7bZkF TzlCiE6qn2QXEZWQwyNZTj2yRgUBb91W29YjhquzVuJeziEVxgOQGinhu5j1aGvrTJHu o+0Y+n5C/88pQw8P5IpUNfcSawVrey9FeAC9bje7ul4cJhgMxVld5UEp9IW/NO/VwiMF CCpQ== X-Gm-Message-State: AOJu0YwsnbuElbYWPU9tvop3YexueNd6c4DLFitDkgqozdmADmhI48it J8r/s5CMid9CN3OjtRDsrdJLjFHBMfdR6BC7UumcnOxwx5Gx+uxDp8DEvZ67AVM= X-Google-Smtp-Source: AGHT+IHvJGCRauk8JElkuSwR19Ji5gQHoQGfep8o9uLdIx5NTLtybn7pVoN3QVRjoPbuhQzI/sRtlA== X-Received: by 2002:a17:902:f64b:b0:20b:9c8c:e9f3 with SMTP id d9443c01a7336-210c68d433emr112365695ad.14.1730130713658; Mon, 28 Oct 2024 08:51:53 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-210bc044da4sm51806585ad.246.2024.10.28.08.51.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Oct 2024 08:51:53 -0700 (PDT) Date: Mon, 28 Oct 2024 08:51:51 -0700 From: Stephen Hemminger To: Viacheslav Ovsiienko Cc: , , , Subject: Re: [PATCH 1/1] doc: virtual function MTU settings has no meaning Message-ID: <20241028085151.2bc312da@hermes.local> In-Reply-To: <20241028144509.1612033-1-viacheslavo@nvidia.com> References: <20241028144509.1612033-1-viacheslavo@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Mon, 28 Oct 2024 16:45:09 +0200 Viacheslav Ovsiienko wrote: > There is the mlx5 NIC limitations - configuring MTU > for PCI Virtual Function has no meaning. The actual maximal > packet size in VF's receiving is limited by MTU configured > on the related PCI Physical Function, the DPDK datapath > running over VF should be prepared to handle packets > of this maximal size. > > Signed-off-by: Viacheslav Ovsiienko > --- > doc/guides/nics/mlx5.rst | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst > index 8d1a1311d4..c7dcb74da7 100644 > --- a/doc/guides/nics/mlx5.rst > +++ b/doc/guides/nics/mlx5.rst > @@ -191,6 +191,13 @@ Limitations > - IPv4/TCP with CVLAN filtering > - L4 steering rules for port RSS of UDP, TCP and IP > > +- PCI Virtual Function MTU: > + > + Configuring MTU for PCI Virtual Function has no meaning. > + The actual maximal packet size in VF's receiving is limited by MTU configured > + on the related PCI Physical Function, the DPDK datapath running over VF should be > + prepared to handle packets of this maximal size. > + This is true of many drivers not just MLX5. And it is generally true that Maximum Receive Unit (MRU) can be larger than Maximum Transmit Unit (MTU). I would rather see a more precise definition of MTU in DPDK show up in ethdev documentation than sprinkling bits in each vendor driver.