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 2DB5AA04B1; Thu, 5 Nov 2020 11:44:28 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A5B8ABC76; Thu, 5 Nov 2020 11:44:25 +0100 (CET) Received: from wnew4-smtp.messagingengine.com (wnew4-smtp.messagingengine.com [64.147.123.18]) by dpdk.org (Postfix) with ESMTP id 048D8BBB4 for ; Thu, 5 Nov 2020 11:44:22 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.west.internal (Postfix) with ESMTP id 0AF4DA82; Thu, 5 Nov 2020 05:44:19 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 05 Nov 2020 05:44:20 -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= QYo3jxo/M54y0XAgv34eVPyj8N8F+foOOH+9CAiAZM4=; b=BcowdWErNQ1ZfOCU Ftl5zpHfwXbkMpX+pFlPOPFDDOIN5SX20YDGeOr+YNsDAgXk53FLG+2oB2VFe1FJ Y4hMGQqlAApaSzpWruWuydfTvKfDhyvRaPnAme4lAVQfSsKAO5kle25bJEWVeiqX kRRw7I5tQGHPUILJ1E6QbsMhgbjk11dF3UTTEM9UxRZ1lcPVt24ip3S4Vq+xahw+ 9Spe+Y5rrk05RvpJWI5X+6RSTCxsWsvGJlDYcNxpovAoqqCzhRZjAIarJR21LUBW cKjxIsnHrkbgniN49rk/JGTnd4NTzBDghC0jf4Zbs1kMq8S5y8b2rDeq9D0cmN15 Ac7acw== 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=QYo3jxo/M54y0XAgv34eVPyj8N8F+foOOH+9CAiAZ M4=; b=N5roZOhqBP3eAtrj953/uCbaUIvqZgv85EZ+QPFHDRKp0cV34zgbmV/BS 1MAhNfLl5DRz5tRqBoCcy6oihkXBOMr39ENlz5KGM5WV6uNNmgLIE/tHYF8T1oGC 9MqC0GMg/EAyGuKPIgN+uAFoXe5IBk4hesjxZs3H7k/1ssvKGlkTe96JZiYbLmL0 CxtrwBTWgYbmd7eUOiGzaSLe3nrCS8wZaee8fkkOgk+37jfWplzIdeseJeKnQ45n PShf8WCiHrnwOaihZ5R21M4m2DT15raWnaxP9LN6TANTPz/HkyePorgDisSFkBhy bKLZn2RtYy+Cm6kofKWvyKdG9dQMA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddtjedgudelucetufdoteggodetrfdotf 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 730DF32801D7; Thu, 5 Nov 2020 05:44:17 -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" , "nhorman@tuxdriver.com" , "david.marchand@redhat.com" Date: Thu, 05 Nov 2020 11:44:16 +0100 Message-ID: <2157818.THrHgzhN9o@thomas> In-Reply-To: <0c5f86c4-49e9-0cfe-fb98-5646712fbeb6@intel.com> References: <20201028030334.30300-1-stevex.yang@intel.com> <0c5f86c4-49e9-0cfe-fb98-5646712fbeb6@intel.com> 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" 05/11/2020 11:37, Ferruh Yigit: > On 11/5/2020 9:33 AM, Yang, SteveX wrote: > > > > > >> -----Original Message----- > >> 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?