2015-06-18 17:06, Marc Sune: > On 18/06/15 16:43, Morten Br?rup wrote: > > Regarding the PHY speed ABI: > > > > 1. The Ethernet PHY ABI for speed, duplex, etc. should be common throughout > > the entire DPDK. It might be confusing if some structures/functions use a > > bitmask to indicate PHY speed/duplex/personality/etc. and other > > structures/functions use a combination of an unsigned integer, duplex flag, > > personality enumeration etc. (By personality enumeration, I am referring to > > PHYs with multiple electrical interfaces. E.g. a dual personality PHY might > > have both an RJ45 copper interface and an SFP module interface, whereof > > only one can be active at any time.) > > Thomas was sending a similar comment and I agreed to do a unified speed > bitmap for both capabilities and link negotiation/link info (v3, waiting > for 2.2 merge window): > > http://dpdk.org/ml/archives/dev/2015-June/019207.html
It would be better to try merging it in 2.1 while keeping an ABI backward compatibility. > > 2. The auto-negotiation standard allows the PHY to announce (to its link > > partner) any subset of its capabilities to its link partner. E.g. a > > standard 10/100/100 Ethernet PHY (which can handle both 10 and 100 Mbit/s > > in both half and full duplex and 1 Gbit/s full duplex) can be configured > > to announce 10 Mbit/s half duplex and 100 Mbit/s full duplex capabilities > > to its link partner. (Of course, more useful combinations are normally > > announced, but the purpose of the example is to show that any combination > > is possible.) > > > > The ABI for auto-negotiation should include options to select the list of > > capabilities to announce to the link partner. The Linux PHY ABI only > > allows forcing a selected speed and duplex (thereby disabling > > auto-negotiation) or enabling auto-negotiation (thereby announcing all > > possible speeds and duplex combinations the PHY is capable of). Don't make > > the same mistake in DPDK. > > I see what you mean, and you are probably right. In any case this is for > a separate patch, if we think it is a necessary feature to implement. > > Nevertheless, this makes me rethink about the proposal from Thomas about > unifying _100_HD/_100_FD to 100M, because you will need this > granularity, eventually. @Thomas: opinions? I think Morten's advice is good. Are we going to have half duplex links for PHY faster than 100M? If not, we can manage them with a hackish define 100M_HD and a 100M which implicitly means full duplex.
