RE: [PATCH V2 net-next] net: fec: add CBS offload support

[Wei Fang]

> -----Original Message-----
> From: Andrew Lunn <andrew@xxxxxxx>
> Sent: 2023年2月18日 9:16
> To: Wei Fang <wei.fang@xxxxxxx>
> Cc: Alexander Lobakin <alexandr.lobakin@xxxxxxxxx>; Shenwei Wang
> <shenwei.wang@xxxxxxx>; Clark Wang <xiaoning.wang@xxxxxxx>;
> davem@xxxxxxxxxxxxx; edumazet@xxxxxxxxxx; kuba@xxxxxxxxxx;
> pabeni@xxxxxxxxxx; simon.horman@xxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx;
> dl-linux-imx <linux-imx@xxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH V2 net-next] net: fec: add CBS offload support
> 
> > I have tested the pure software CBS today. And below are the test steps and
> results.
> > Link speed 100Mbps.
> > Queue 0: Non-CBS queue, 100Mbps traffic.
> > Queue 1: CBS queue, 7Mbps bandwidth and 8Mbps traffic.
> > Queue 2: CBS queue, 5Mbps bandwidth and 6Mbps traffic.
> > Results: queue 0 egress rate is 86Mbps, queue 1 egress rate is 6Mbps,
> > and queue 2 egress rate is 4Mbps.
> > Then change the link speed to 10Mbps, queue 0 egress rate is 4Mbps,
> > queue 1 egress rate is 4Mbps, and queue 2 egress rate is 3Mbps.
> >
> > Beside the test results, I also checked the CBS codes. Unlike hardware
> > implementation, the pure software method is more flexible, it has four
> > parameters: idleslope, sendslope, locredit and hicredit. And it can detect the
> change of link speed and do some adjust.
> > However, for hardware we only use the idleslope parameter. It's hard
> > for us to make the hardware behave as the pure software when the link
> speed changes.
> > So for the question: Should the hardware just give up and go back to
> > default behaviour, or should it continue to do some CBS?
> 
> If you give up on hardware CBS, does the software version take over?
> 
No, because the cbs offload flag is enabled in CBS driver, unless configure cbs offload
disable with tc command.

> The idea of hardware offload is that the user should not care, nor really notice.
> You want the software and hardware behaviour to be similar.
> 
> > I think that we can refer to the behaviors of stmmac and enetc
> > drivers, just keep the bandwidth ratio constant when the link rate
> > changes. In addition, the link speed change is a corner case, there is no need
> to spend any more effort to discuss this matter.
> 
> It is a corner case, but it is an important one. You need it to do something
> sensible. Giving up all together is not sensible. Falling back to software CBS
> would be sensible, or supporting something similar to the software CBS.
> 
Unfortunately, FEC IP itself not follows the standard 802.1Qav spec completely.
We only can program DMAnCFG[IDLE_SLOPE] field to calculate bandwidth fraction.
And IDLE_SLOPE is restricted to certain values. It's far away from CBS QDisc implemented
in Linux TC framework. It is more difficult to guarantee similar software behavior when
the link speed changes.
If the method of keeping the bandwidth ratio unchanged is not sensible, I can only give up
CBS offload and use pure software CBS. :(