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 E0F1BA04B1; Wed, 4 Nov 2020 21:19:55 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DCBDD2BDB; Wed, 4 Nov 2020 21:19:53 +0100 (CET) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 162872BD3 for ; Wed, 4 Nov 2020 21:19:51 +0100 (CET) IronPort-SDR: byTrL/V+1goYAAR0z7bZLJyKKtMq277NAZW02nx1Xz5+WL16x/8bZqGu4nfpZr1qs3ihx7rXoh F51rf86Jg+Eg== X-IronPort-AV: E=McAfee;i="6000,8403,9795"; a="187148542" X-IronPort-AV: E=Sophos;i="5.77,451,1596524400"; d="scan'208";a="187148542" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Nov 2020 12:19:46 -0800 IronPort-SDR: bsLNQo8PBsH2+Dw8B7VCQ8PNDeYOEVWtWdftNrYtx5OM/cZXbjThJS5kQ/rCVtf8VUPW0oC6EQ CfOerBa1PMWw== X-IronPort-AV: E=Sophos;i="5.77,451,1596524400"; d="scan'208";a="539054651" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.227.19]) ([10.213.227.19]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Nov 2020 12:19:42 -0800 To: Thomas Monjalon , SteveX Yang Cc: dev@dpdk.org, konstantin.ananyev@intel.com, beilei.xing@intel.com, wenzhuo.lu@intel.com, bernard.iremonger@intel.com, qiming.yang@intel.com, mdr@ashroe.eu, nhorman@tuxdriver.com, david.marchand@redhat.com, andrew.rybchenko@oktetlabs.ru References: <20201028030334.30300-1-stevex.yang@intel.com> <2392354.O08QGPWUWg@thomas> <13d2c6ad-c14b-b471-5920-ec3c552b7a61@intel.com> <2034736.YrmxQ9UtPI@thomas> From: Ferruh Yigit Message-ID: Date: Wed, 4 Nov 2020 20:19:38 +0000 MIME-Version: 1.0 In-Reply-To: <2034736.YrmxQ9UtPI@thomas> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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" 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?