Re: net: question on Liquidio II link speed management code, i suspect it's a bit incomplete

Florian Heigl <[email protected]> =E6=96=BC 2026=E5=B9=B43=E6=9C=8831=
=E6=97=A5=E9=80=B1=E4=BA=8C =E4=B8=8B=E5=8D=885:36=E5=AF=AB=E9=81=93=EF=BC=
=9A
>
> I=E2=80=99m trying to wrap my head around the link speed setting mechanis=
m for the Cavium LiquidIO II / CN23XX NICs. I have a few of those for playi=
ng around and try to make them more accessible for others.
>
> I=E2=80=99m on Alpine Linux edge, running 6.18.19
>
> The card defaults to 25gbit, and when I try to set the link speed from et=
htool it doesn=E2=80=99t work.
> "Changing speed is not supported=E2=80=9C in dmesg and in ethtool it=E2=
=80=99ll say
>
> tschike:/tmp# ethtool -s eth0 speed 10000
> netlink error: link settings update failed
> netlink error: Not supported
>
> that was odd since I can find that that support IS in the kernel.
>
> https://lists.openwall.net/netdev/2018/05/08/21
>
>
>
> Today I was looking at this again, and specifically at how the flag no_sp=
eed_setting comes into existence.
> I found that happens in lio.core.c (drivers/net/cavium/liquidio):
>
> specifically here
>                         var =3D be32_to_cpu((__force __be32)resp->speed)
> if that sends back a ffff it=E2=80=99ll end up at the default link speed =
and deny setting it.
>
>
> https://gist.github.com/FlorianHeigl/de72c603b1579dd94dc9ecbeb290a36c?per=
malink_comment_id=3D6068358#gistcomment-6068358
>
> I got the strong suspicion that the code for that decision making is inco=
mplete.
> common scenarios:
> - if the card has link at 10g, it=E2=80=99ll send 10g, and you=E2=80=99ll=
 be able to switch link speed via ethtool
> - if the card has link at 25g, it=E2=80=99ll send 25g, and you=E2=80=99ll=
 be able to switch link speed via ethtool
> - if the card has a 10g cable and tries to talk 25g it will not have a li=
nk and no idea what to do.
>
> >i think it the driver then ends up with no negotiated speed state,
> and in that situation, with the current implementation you can never set =
the right speed<
> this would explain the actual behaviour I see, and it would explain it be=
tter than just looking for
> differences between the old SDK and fresher in-kernel code.
> the supported link modes in ethtool are also =E2=80=9Ewrong" (only shows =
25g, should show 10g, 25g)
>
>
>
> i=E2=80=99m just not sure how to prove it from the code. I can point at t=
hree relevant opcodes in liquidio_common.h
>
>
> #define OPCODE_NIC_UBOOT_CTL           0x17
> #define   SEAPI_CMD_SPEED_SET           0x2
> #define   SEAPI_CMD_SPEED_GET           0x3
>
> but IDK what really happens when it queries the that resp->speed thing (i=
=E2=80=99m not a dev, obviously)
>
> I=E2=80=99ll test with a different u-boot version but the kernel side is =
far above my head.
> some other dumb tests I can imagine are changing it to always select 10g =
or overriding the =E2=80=9Affff=E2=80=98 return.
> it just feels like piking at things blindly. I=E2=80=99d like to know if =
that even has a point.
> if someone tells me no that logic flaw you imagine doesn=E2=80=99t exist =
then I can avoid a lot of frustrating tests.
> I don=E2=80=99t have a 25g DAC or SFP that the card accepts, so I can=E2=
=80=99t even test by just connecting it to itself.
>
>
>
> tl;dr
> I think driver only allows the card to change the link speed when it=E2=
=80=99s not really important to be able to
> I think the supported link speeds are reported wrong
> if someone with a bigger brain or more practice could look at the logic a=
nd see if my suspicions hold up, or tell me a reasonable next step to take?
>
>
Hi  Florian

I recommend sending your inquiry to the relevant subsystem mailing
list as well. In this case, [email protected] would be the
appropriate place. Since not all maintainers follow linux-newbie,
targeting the specific subsystem is usually more effective. You can
refer to this thread for more details:
https://lore.kernel.org/all/[email protected]=
.our-ratio-313919.internal/

Hope this helps!


--=20
Regards,
Nick Huang