On Tue, Aug 13, 2024 at 3:59 PM Ilya Maximets <i.maxim...@ovn.org> wrote: > > 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.
Full duplex has become the norm. I don't think new standards support half duplex. > 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). netdev-linux and netdev-bsd can be fixed, indeed. > 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. I am not convinced on the "unknown" part. The duplex info may not be applicable to virtual links, for which an "unknown" status would be strange. Currently, the absence of value (setting NULL) is already an indication. > 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. Separating speed and duplex concern is cleaner and should have been done that way in the first place. I posted a v2: https://mail.openvswitch.org/pipermail/ovs-dev/2025-July/424490.html -- David Marchand _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
