RE: [PATCH v2 net-next 3/5] et: fec: add rx_frame_size to support configurable RX length

[Wei Fang]

> > > > > @@ -4563,6 +4563,7 @@ fec_probe(struct platform_device *pdev)
> > > > >  	pinctrl_pm_select_sleep_state(&pdev->dev);
> > > > >
> > > > >  	fep->pagepool_order = 0;
> > > > > +	fep->rx_frame_size = FEC_ENET_RX_FRSIZE;
> > > >
> > > > According to the RM, to allow one maximum size frame per buffer,
> > > > FEC_R_BUFF_SIZE must be set to FEC_R_CNTRL [MAX_FL] or larger.
> > > > FEC_ENET_RX_FRSIZE is greater than PKT_MAXBUF_SIZE, I'm not sure
> > > whether it
> > > > will cause some unknown issues.
> > >
> > > MAX_FL defines the maximum allowable frame length, while TRUNC_FL
> > > specifies the threshold beyond which frames are truncated. Based on
> > > this logic, the documentation appears to be incorrect-TRUNC_FL should
> > > never exceed MAX_FL, as doing so would make the truncation mechanism
> > > ineffective.
> > >
> > > This has been confirmed through testing data.
> > >
> >
> > One obvious issue I can see is that the Rx error statistic would be doubled the
> > actual number when the FEC receives jumbo frames.
> >
> > For example, the sender sends 1000 jumbo frames (8000 bytes) to the FEC
> port,
> > without this patch set, the Rx error statistic of FEC should be 1000, however,
> after
> > applying this patch set (rx_frame_size is 3520, max_buf_size is 1984), I can see
> > the Rx error statistic is 2000.
> 
> I don't think there is a case that rx_frame_size is 3520 while the max_buf_size is
> 1984.
> With the patch, the rx_frame_size should always less than the max_buf_size.
> Otherwise,
> the implementation might have a logic bug.
> 

Actually, I have tested this patch set, that is the problem I'm seeing. You can also
have a try, do not enable jumbo frame, just use the default configuration.