From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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 <thomas@monjalon.net>, SteveX Yang <stevex.yang@intel.com>
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 <ferruh.yigit@intel.com>
Message-ID: <c4d457e2-be4d-bc81-7359-529255e43f36@intel.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
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 <stevex.yang@intel.com>
>>>>>
>>>>> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
>>>>
>>>> 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?