On 8/9/24 15:28, David Marchand wrote: > As OVS does not know of the 25G speed, matching on a list of known speed > for deducing full duplex capability is broken. > Invert the test and assume full duplex is the default.
Hi, David. Thanks for the patch. But I'm not sure about the approach. This may solve the issue for a particular card you have, but may introduce the opposite issue for some other card. There are few things we can do: 1. Report 'full', 'half', 'unknown', where 'unknown' is reported for NETDEV_F_OTHER (netdev-linux may need a fix to report it). The function is currently used only for sFlow and the link status in the database. sFlow supports the "unknown" value. Database schema may be extended to accept "unknown" as a value. 2. Go further and actually request the duplex configuration from the netdev layer for NETDEV_F_OTHER. We had the same issue with the speed reporting and ended up with a netdev-provider API to request the numerical value where it is possible, i.e. not reported via OpenFlow. So, we can either add a second API callback for duplex or add another "output" argument to the speed API, since the speed and the duplex are usually part of the same device info anyway. What do you think? Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
