From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id BA718A04B1; Thu, 5 Nov 2020 11:48:52 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0A1D4BC76; Thu, 5 Nov 2020 11:48:51 +0100 (CET) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id 273D9BBB4 for ; Thu, 5 Nov 2020 11:48:49 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 7FC8B5803EA; Thu, 5 Nov 2020 05:48:47 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 05 Nov 2020 05:48:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= JmhXKzef9OCRP3kVEkpM21KWi4OMaPj+PSfC4MjSI2o=; b=SDAMbgmq14oo0EG2 t9dEZK/i7dbtBZ+uXSREtDTvSd6ZxtDAbC7Vo/u+6K7rEyK6MZdNwz0r1kG4Jhf2 kWGLKYicn8b3X490nE6uGRBiwzg1rEIkMSkDAFhe62FHzwzutOfhWA15B+FS4zb2 MdC6mLctyGllAgr1QwSUEKWwxALVu0DfGNybp3PBsVaVORF12NPcgImzOJQOG0sS k3giMHZPfeHKH9L9nyAEr5PMl+PMxZ7JCnSkB88xbopN54jclTNpmn7+e044K6lc qVbq9qs1fEizxdjgodSCJldSn3LcnSPQNb8lLHCKOPBgBugV8DP2e9vmlDhFOwjr Hq4s6Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=JmhXKzef9OCRP3kVEkpM21KWi4OMaPj+PSfC4MjSI 2o=; b=S1310aQoAgGZZuRcT997VF4aunFto4j1f8EI/RK+x6AkRfR4DRqWbAdU2 VRbF92Q4pG0H0gzSNI/00oHcNt05gMGJ0zi5MQwJX2Ex3+PljA0SheoGSlMkeYgu hfYXsQT+XpEK842gqrl5EwNxJWN8H3QYBMJowWhwgdfsL4HRFTQCH9olMTljRVJG 7bDjw3cWHy5cYPWSOYnmYywmHTHlqW9z9qq5NiCFLRQ2/y20WEkU/3VwsmCJVtC5 pV/e6yL/G8PqX4F+yEsQTpSUbtaxOXl+HukC1CnHjxlwpotirMLozQJEdEboNw33 jaeJbU+5Z3bO1lyLNpgPxARuzGXAg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddtjedgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 284743060057; Thu, 5 Nov 2020 05:48:42 -0500 (EST) From: Thomas Monjalon To: "Yang, SteveX" , Andrew Rybchenko , Ferruh Yigit Cc: "dev@dpdk.org" , "Ananyev, Konstantin" , "Xing, Beilei" , "Lu, Wenzhuo" , "Iremonger, Bernard" , "Yang, Qiming" , "mdr@ashroe.eu" , "david.marchand@redhat.com" , jerinj@marvell.com, ajit.khaparde@broadcom.com, maxime.coquelin@redhat.com, matan@nvidia.com, viacheslavo@nvidia.com, hemant.agrawal@nxp.com, bruce.richardson@intel.com, stephen@networkplumber.org Date: Thu, 05 Nov 2020 11:48:40 +0100 Message-ID: <2109640.M41klPuLie@thomas> In-Reply-To: <2157818.THrHgzhN9o@thomas> References: <20201028030334.30300-1-stevex.yang@intel.com> <0c5f86c4-49e9-0cfe-fb98-5646712fbeb6@intel.com> <2157818.THrHgzhN9o@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v8 1/2] app/testpmd: fix max rx packet length for VLAN packets X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" + more maintainers Cc'ed We have a critical issue with testpmd in -rc2. It is blocking a lot of testing. Would be good to do a -rc3 today. Please see below. 05/11/2020 11:44, Thomas Monjalon: > 05/11/2020 11:37, Ferruh Yigit: > > On 11/5/2020 9:33 AM, Yang, SteveX wrote: > > > From: Andrew Rybchenko > > >> Sent: Thursday, November 5, 2020 4:54 PM > > >> To: Thomas Monjalon ; Yang, SteveX > > >> ; Yigit, Ferruh > > >> Cc: dev@dpdk.org; Ananyev, Konstantin ; > > >> Xing, Beilei ; Lu, Wenzhuo ; > > >> Iremonger, Bernard ; Yang, Qiming > > >> ; mdr@ashroe.eu; nhorman@tuxdriver.com; > > >> david.marchand@redhat.com > > >> Subject: Re: [dpdk-dev] [PATCH v8 1/2] app/testpmd: fix max rx packet > > >> length for VLAN packets > > >> > > >> On 11/4/20 11:39 PM, Thomas Monjalon wrote: > > >>> 04/11/2020 21:19, Ferruh Yigit: > > >>>> On 11/4/2020 5:55 PM, Thomas Monjalon wrote: > > >>>>> 04/11/2020 18:07, Ferruh Yigit: > > >>>>>> On 11/4/2020 4:51 PM, Thomas Monjalon wrote: > > >>>>>>> 03/11/2020 14:29, Ferruh Yigit: > > >>>>>>>> On 11/2/2020 11:48 AM, Ferruh Yigit wrote: > > >>>>>>>>> On 11/2/2020 8:52 AM, SteveX Yang wrote: > > >>>>>>>>>> When the max rx packet length is smaller than the sum of mtu > > >>>>>>>>>> size and ether overhead size, it should be enlarged, otherwise > > >>>>>>>>>> the VLAN packets will be dropped. > > >>>>>>>>>> > > >>>>>>>>>> Fixes: 35b2d13fd6fd ("net: add rte prefix to ether defines") > > >>>>>>>>>> > > >>>>>>>>>> Signed-off-by: SteveX Yang > > >>>>>>>>> > > >>>>>>>>> Reviewed-by: Ferruh Yigit > > >>>>>>>> > > >>>>>>>> Applied to dpdk-next-net/main, thanks. > > >>>>>>>> > > >>>>>>>> only 1/2 applied since discussion is going on for 2/2. > > >>>>>>> > > >>>>>>> I'm not sure this testpmd change is good. > > >>>>>>> > > >>>>>>> Reminder: testpmd is for testing the PMDs. > > >>>>>>> Don't we want to see VLAN packets dropped in the case described > > >> above? > > >>>>>>> > > >>>>>> > > >>>>>> The patch set 'max_rx_pkt_len' in a way to make MTU 1500 for all > > >>>>>> PMDs, otherwise testpmd set hard-coded 'RTE_ETHER_MAX_LEN' > > >> value, > > >>>>>> which makes MTU between 1492-1500 depending on PMD. > > >>>>>> > > >>>>>> It is application responsibility to provide correct 'max_rx_pkt_len'. > > >>>>>> I guess the original intention was to set MTU as 1500 but was not > > >>>>>> correct for all PMDs and this patch is fixing it. > > >>>>>> > > >>>>>> The same problem in the ethdev, (assuming 'RTE_ETHER_MAX_LEN' > > >> will > > >>>>>> give MTU 1500), the other patch in the set is to fix it later. > > >>>>> > > >>>>> OK but the testpmd patch is just hiding the issue, isn't it? > > >>>>> > > >>>> > > >>>> I don't think so, issue was application (testpmd) setting the > > >> 'max_rx_pkt_len' > > >>>> wrong. > > >>>> > > >>>> What is hidden? > > >>> > > >>> I was looking for adding a helper in ethdev API. > > >>> But I think I can agree with your way of thinking. > > >>> > > >> > > >> The patch breaks running testpmd on Virtio-Net because the driver > > >> populates dev_info.max_rx_pktlen but keeps dev_info.max_mtu equal to > > >> UINT16_MAX as it was filled in by ethdev. As the result: > > >> > > >> Ethdev port_id=0 max_rx_pkt_len 11229 > max valid value 9728 Fail to > > >> configure port 0 > > > > > > Similar issue occurred for other net PMD drivers which use default max_mtu (UINT16_MAX). > > > More strict checking condition will be added within new patch sooner. > > > > > > > :( > > > > For drivers not providing 'max_mtu' information explicitly, the default > > 'UINT16_MAX' is set in ethdev layer. > > This prevents calculating PMD specific 'overhead' and the logic in the patch is > > broken. > > > > Indeed this makes inconsistency in the driver too, for example for virtio, it > > claims 'max_rx_pktlen' as "VIRTIO_MAX_RX_PKTLEN (9728)" and 'max_mtu' as > > UINT16_MAX. From 'virtio_mtu_set()' we can see the real limit is > > 'VIRTIO_MAX_RX_PKTLEN'. > > > > When PMDs fixed, the logic in this patch can work but not sure if post -rc2 is > > good time to start fixing the PMDs. > > Do you suggest revert is the best choice here?