Re: half-/full-duplex ethernet and ifconfig

[Masanobu SAITOH <msaitoh%execsw.org@localhost>]

Hi, David.

(2012/11/14 8:56), David Young wrote:
> Today I noticed a funny thing about the ethernet media settings that I
> can see and choose through 'ifconfig wm0':
>
>          supported Ethernet media:
>                  media none
>                  media 10baseT
>                  media 10baseT mediaopt full-duplex
>                  media 100baseTX
>                  media 100baseTX mediaopt full-duplex
>                  media 1000baseT
>                  media 1000baseT mediaopt full-duplex
>                  media autoselect
>
> What's the difference between 'media 10baseT' and 'media 10baseT
> mediaopt full-duplex' ?
>
> I thought at first that if I did 'ifconfig wm0 media 10baseT' then it
> was up to my NIC and its link partner to negotiate the duplex setting.
> I.e., that if I don't specify a duplex setting, then the system assumes
> that I don't care.

 I think if mediaopt full-duplex isn't set, it act as half-duplex
and it really act as I expected.

>  I also expected that whichever duplex setting was
> negotiated, I could read it out again using 'ifconfig wm0'.  So if I set
> 'ifconfig wm0 media 10baseT', I should see either
>
>          media: Ethernet 10baseT (10baseT full-duplex)
>          status: active
>
> or
>
>          media: Ethernet 10baseT (10baseT half-duplex)
>          status: active
>
> since the kernel defines non-zero flags for both (IFM_HDX, IFM_FDX).
> Instead, I see this:
>
>          media: Ethernet 10baseT
>          status: active
>
> Grovelling a bit in the ifconfig(8) code, I see that that
> parentheses-less output means the "active" (negotiated) media and the
> "current" (selected) media setting are the same: they're both Ethernet
> 10baseT.
>
> Digging deeper, I find these lines in mii_phy_add_media():
>
>          if (sc->mii_capabilities & BMSR_10THDX) {
>                  ADD(IFM_MAKEWORD(IFM_ETHER, IFM_10_T, 0, sc->mii_inst),
>                      MII_MEDIA_10_T);
>                  PRINT("10baseT");
>          }
>          if (sc->mii_capabilities & BMSR_10TFDX) {
>                  ADD(IFM_MAKEWORD(IFM_ETHER, IFM_10_T, IFM_FDX, sc->mii_inst),
>                      MII_MEDIA_10_T_FDX);
>                  PRINT("10baseT-FDX");
>                  fdx = 1;
>          }

The BMSR register give us the "capability" of the PHY. The ANAR register
is set from mii_capabilities and argument of SIOCSIFMEDIA.

> This tells me that we're using 0, not IFM_HDX, to represent
> "half-duplex"---or do I have the wrong interpretation

 In my opinion, IFM_HDX should be removed. If the duplex has a state other
than full-duplex and half-duplex, it's ok to have bot IFM_FDX and IFM_HDX.
If the duplex setting has only two state (i.e. full and half), the best way
is to use only one flag to identify it.

> ---and there is no
> way to select a rate setting independent of a duplex setting.

 Currently, we have no API to specify an advertise setting for auto
negotiation particularly. I think it's useful on some cases.
 


> But hold on a minute, I see some PHY drivers are using both IFM_HDX
> IFM_FDX at least to tell what the negotiated media is:
>
> % grep IFM_HDX ../../dev/mii/*
> ../../dev/mii/atphy.c:          mii->mii_media_active |= IFM_HDX;
> ../../dev/mii/bmtphy.c:                 mii->mii_media_active |= IFM_HDX;
> ../../dev/mii/brgphy.c:                         mii->mii_media_active |= 
> IFM_HDX;
> ../../dev/mii/etphy.c:          mii->mii_media_active |= IFM_HDX;
> ../../dev/mii/rdcphy.c:         mii->mii_media_active |= IFM_HDX;
> ../../dev/mii/rgephy.c:                 mii->mii_media_active |= IFM_HDX;
> ../../dev/mii/rgephy.c:                 mii->mii_media_active |= IFM_HDX;
>
> I am having a hard time seeing the design intention here, can someone
> help me out?
>
> Dave


--
-----------------------------------------------
                SAITOH Masanobu (msaitoh%execsw.org@localhost
                                 msaitoh%netbsd.org@localhost)