Re: [dpdk-dev] [PATCH v2 1/2] Added ETH_SPEED_CAP bitmap in rte_eth_dev_info

[Marc Sune <marc.sune@bisdn.de>]

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@smartsharesystems.com <mailto:mb@smartsharesystems.com>
>
> www.smartsharesystems.com <http://www.smartsharesystems.com/>
>
>   
>