On Thu, Nov 05, 2020 at 10:50:45AM +0000, Ferruh Yigit wrote:
> On 11/5/2020 10:48 AM, Thomas Monjalon wrote:
> > + 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.rybche...@oktetlabs.ru>
> > > > > > Sent: Thursday, November 5, 2020 4:54 PM
> > > > > > To: Thomas Monjalon <tho...@monjalon.net>; Yang, SteveX
> > > > > > <stevex.y...@intel.com>; Yigit, Ferruh <ferruh.yi...@intel.com>
> > > > > > Cc: dev@dpdk.org; Ananyev, Konstantin
> > > > > > <konstantin.anan...@intel.com>;
> > > > > > Xing, Beilei <beilei.x...@intel.com>; Lu, Wenzhuo
> > > > > > <wenzhuo...@intel.com>;
> > > > > > Iremonger, Bernard <bernard.iremon...@intel.com>; Yang, Qiming
> > > > > > <qiming.y...@intel.com>; m...@ashroe.eu; nhor...@tuxdriver.com;
> > > > > > david.march...@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.y...@intel.com>
> > > > > > > > > > > > >
> > > > > > > > > > > > > Reviewed-by: Ferruh Yigit <ferruh.yi...@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?
> >
> >
>
> (copy/pasting previous reply to this eamil)
>
> One option is revert, but than the issue this patch is trying to fix still
> remain.
>
> Other option is the extend the patch as Steve sent [1], the check there is
> more like workaround in application, so not nice to have them, but with
> extending the deprecation notice (other patch in this patchset) to fix PMDs
> too in next release, I would be OK to have these checks. What do you think?
+1 for this second option.
I think it is ok to have a workaround to fix an issue. Clarifying and
uniformizing the ethdev/drivers behavior in that area can come in a
second time.
> [1]
> https://patches.dpdk.org/patch/83717/
