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 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 <dev@dpdk.org>; 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: <xms:i9ijX_ZUTjBVgeZLv0ornNGBk3_W9wVIZSVv894tQWKciUhjnkjkCA>
<xme:i9ijX-ZMbeBCFDY1VyhfJr8oR21LLkq0kH3pNqPbtVtvZFaNFH6_brfhiOx2FEkj9
6EGpAVoRidqwyuVsw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddtjedgvddtucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr
shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg
ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu
ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf
hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl
ohhnrdhnvght
X-ME-Proxy: <xmx:i9ijXx-6CBFteDkXTh060o_57qdcgt6kNYQzI28t4kSlY0Qp8jeEuQ>
<xmx:i9ijX1qFZtOvCnnANtWcClLpZYM3HnV6Kzw85oVtqIkCVk-25VinCw>
<xmx:i9ijX6pnsVX_Xp-MZei8ssaJN3XM70UFp9WDjBYIWjeVh7z5JWlYpA>
<xmx:j9ijX4bYlOt83wLhpHmkRST3AY4Z7PtDcDQu6X5623djk-bMC2RWvw>
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 <thomas@monjalon.net>
To: "Yang, SteveX" <stevex.yang@intel.com>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
Ferruh Yigit <ferruh.yigit@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, "Ananyev,
Konstantin" <konstantin.ananyev@intel.com>, "Xing,
Beilei" <beilei.xing@intel.com>, "Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
"Iremonger, Bernard" <bernard.iremonger@intel.com>, "Yang,
Qiming" <qiming.yang@intel.com>, "mdr@ashroe.eu" <mdr@ashroe.eu>,
"david.marchand@redhat.com" <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 <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>
+ 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 <andrew.rybchenko@oktetlabs.ru>
> > >> Sent: Thursday, November 5, 2020 4:54 PM
> > >> To: Thomas Monjalon <thomas@monjalon.net>; Yang, SteveX
> > >> <stevex.yang@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>
> > >> Cc: dev@dpdk.org; Ananyev, Konstantin <konstantin.ananyev@intel.com>;
> > >> Xing, Beilei <beilei.xing@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>;
> > >> Iremonger, Bernard <bernard.iremonger@intel.com>; Yang, Qiming
> > >> <qiming.yang@intel.com>; 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 <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?
> > >>>
> > >>> 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?