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

[Andrew Lunn <andrew@lunn.ch>]

> 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?

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.

	Andrew