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 > > > > 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? Thanks Marc p.s. Please configure your email client to reply using "In-Reply-To:" to allow clients and ML archives to use threading. > > > PS: While working for Vitesse Semiconductors (an Ethernet chip company) a > long time ago, I actually wrote the API for their line of Ethernet PHYs. So I > have hands on experience in this area. > > > > > > Med venlig hilsen / kind regards > > > > Morten Br?rup > > CTO > > > > > > > > SmartShare Systems A/S > > Tonsbakken 16-18 > > DK-2740 Skovlunde > > Denmark > > > > Office +45 70 20 00 93 > > Direct +45 89 93 50 22 > > Mobile +45 25 40 82 12 > > > > mb at smartsharesystems.com <mailto:mb at smartsharesystems.com> > > www.smartsharesystems.com <http://www.smartsharesystems.com/> > > >
