30/03/2024 12:38, huangdengdui: > But, there are different solutions for the device to report the setting > lane capability, as following: > 1. Like the current patch, reporting device capabilities in speed and > lane coupling mode. However, if we use this solution, we will have > to couple the the lanes setting with speed setting. > > 2. Like the Damodharam's RFC patch [1], the device reports the maximum > number of supported lanes. Users can config a lane randomly, > which is completely separated from the speed. > > 3. Similar to the FEC capability reported by a device, the device reports the > relationship table of the number of lanes supported by the speed, > for example: > speed lanes_capa > 50G 1,2 > 100G 1,2,4 > 200G 2,4 > > Options 1 and 2 have been discussed a lot above. > > For solution 1, the speed and lanes are over-coupled, and the implementation > is too > complex. But I think it's easier to understand and easier for the device to > report > capabilities. In addition, the ethtool reporting capability also uses this > mode. > > For solution 2, as huisong said that user don't know what lanes should or can > be set > for a specified speed on one NIC. > > I think that when the device reports the capability, the lanes should be > associated > with the speed. In this way, users can know which lanes are supported by the > current > speed and verify the configuration validity. > > So I think solution 3 is better. What do you think?
I don't understand your proposals. Please could you show the function signature for each option?
