On Tue, Sep 01, 2026 at 04:23:51PM +0800, Hangbin Liu wrote:
> On Tue, Sep 01, 2026 at 02:58:17PM +0800, Hangbin Liu wrote:
> > On Mon, Aug 31, 2026 at 03:08:18PM -0700, Jakub Kicinski wrote:
> > > On Mon, 31 Aug 2026 11:28:10 +0800 Hangbin Liu wrote:
> > > > Add ethtool get/set_link_ksettings callbacks to netdevsim so the
> > > > simulated
> > > > link speed and duplex can be queried and configured from userspace.
> > > >
> > > > Move NSIM_LINK_SPEED_MAX and NSIM_LINK_SPEED_UNIT from dev.c to
> > > > netdevsim.h
> > > > so they are available to both the devlink rate path and the new ethtool
> > > > code. The set callback rejects speeds exceeding NSIM_LINK_SPEED_MAX.
> > > >
> > > > The default link speed is set to SPEED_5000 with DUPLEX_FULL, matching
> > > > the
> > > > existing NSIM_LINK_SPEED_MAX definition.
> > >
> > > This breaks TDC which uses netdevsim for taprio testing.
> >
> > Sigh, I really didn't expect a speed feature could break the tc qdisc
> > testing... I will check the reason.
>
> OK, here is the reason. In taprio_set_picos_per_byte(), it init NIC speed to
> SPEED_10. If the NIC doesn't support get_link_ksettings, the final calculated
> picos_per_byte would be a extremely large number 800000. The later tc taprio
> testing `tc qdisc ... sched-entry S 02 300` will always failed in
> fill_sched_entry(), as min_duration is also a large number 48000.
>
> After we supports get_link_ksettings for netdevsim, the speed is 5000 and
> picos_per_byte will be init to 1600. The later min_duration checking in
> fill_sched_entry() is 300 vs 96. So the tc qdisc command always return 0.
>
> To fix the test, I think we should reduce the interval number. e.g.
Why not just set the initial speed to SPEED_10, so nothing changes?
Andrew
