Re: ETHERCAP_* & ioctl()

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

(2012/11/02 8:07), David Young wrote:
> On Wed, Oct 31, 2012 at 07:24:51PM +0900, Masanobu SAITOH wrote:
>>  Hi, all.
>>
>>  I sent the followin mail more than two years ago.
>>
>>> http://mail-index.netbsd.org/tech-kern/2010/07/28/msg008613.html
>>
>>  As the starting point to solve this problem, I committed the change to
>> add SIOCGETHERCAP stuff.
>>
>>  Example:
>>> msk0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
>>>         ec_capabilities=5<VLAN_MTU,JUMBO_MTU>
>>>         ec_enabled=0
>>>         address: 00:50:43:00:4b:c5
>>>         media: Ethernet autoselect
>>>         status: no carrier
>>> wm0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>>>         
>>> capabilities=7ff80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx,TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6>
>>>         
>>> enabled=7ff80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx,TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6>
>>>         ec_capabilities=7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
>>>         ec_enabled=0
>>>         address: 00:1b:21:58:68:34
>>>         media: Ethernet autoselect (1000baseT 
>>> full-duplex,flowcontrol,rxpause,txpause)
>>>         status: active
>>>         inet 192.168.1.5 netmask 0xffffff00 broadcast 192.168.1.255
>>>         inet6 fe80::21b:21ff:fe58:6834%wm0 prefixlen 64 scopeid 0x2
>>>         inet6 2001:240:694:1:21b:21ff:fe58:6834 prefixlen 64
>>
>>
>>  What do you think about this output?
> 
> I think that these flags belong within a "service hatch" rather than "on
> the dashboard."  That is, shown via sysctl or ifconfig -v instead of in
> the normal output of ifconfig.
> 
> What are the use-cases for reading/changing these flags?  I don't see
> what an operator is supposed to do with this new information and with
> these new controls.

 For _VLAN_MTU flag, some people may don't want to get vlan-sized frame
which packet has no vlan tag though it's trivial. For _VLAN_HWTAGGING,
if a driver has a bug in the VLAN_HWTAGGGING, people think they want to
disable it without recompiling the kernel.

 But, as the output of ifconfig above shows, we have both ec_capablities
and ec_capenalbe and *ALMOST all* of NetBSD's source use ec_capabilities only.
The exception is as follows:

> % grep -r ec_capenable .
> ./arch/mips/atheros/dev/if_ae.c:                    
> ((sc->sc_ethercom.ec_capenable & ETHERCAP_VLAN_MTU) == 0 ||
> ./arch/emips/ebus/if_le_ebus.c:     len > ((sc->sc_ethercom.ec_capenable & 
> ETHERCAP_VLAN_MTU) ?
> ./arch/sgimips/mace/if_mec.c:           if ((sc->sc_ethercom.ec_capenable & 
> ETHERCAP_VLAN_MTU) != 0)
> ./dev/ic/elinkxl.c:                                         
> ((sc->sc_ethercom.ec_capenable &
> ./dev/ic/gem.c:     ((sc->sc_ethercom.ec_capenable & ETHERCAP_VLAN_MTU) ?
> ./dev/ic/gem.c: if (sc->sc_ethercom.ec_capenable & ETHERCAP_VLAN_MTU)
> ./dev/ic/gem.c:                 if (sc->sc_ethercom.ec_capenable & 
> ETHERCAP_VLAN_MTU) {
> ./dev/ic/hme.c:     (sc->sc_ethercom.ec_capenable & ETHERCAP_VLAN_MTU) ?
> ./dev/ic/hme.c: sc->sc_ec_capenable = sc->sc_ethercom.ec_capenable;
> ./dev/ic/hme.c:     (sc->sc_ethercom.ec_capenable & ETHERCAP_VLAN_MTU) ?
> ./dev/ic/hme.c:     len > ((sc->sc_ethercom.ec_capenable & ETHERCAP_VLAN_MTU) 
> ?
> ./dev/ic/hme.c:         if (sc->sc_ec_capenable != 
> sc->sc_ethercom.ec_capenable)
> ./dev/ic/hmevar.h:      int                     sc_ec_capenable;
> ./dev/ic/i82557.c:              if ((ec->ec_capenable & ETHERCAP_VLAN_MTU) != 
> 0 &&
> ./dev/ic/i82557.c:      if (sc->sc_ethercom.ec_capenable & ETHERCAP_VLAN_MTU) 
> {
> ./dev/ic/lance.c:           len > ((sc->sc_ethercom.ec_capenable & 
> ETHERCAP_VLAN_MTU) ?
> ./dev/ic/rtl8169.c:     if ((sc->ethercom.ec_capenable & 
> ETHERCAP_VLAN_HWTAGGING) != 0)
> ./dev/ic/tulip.c:               if ((sc->sc_ethercom.ec_capenable & 
> ETHERCAP_VLAN_MTU) != 0)
> ./dev/pci/if_sip.c:             /* ec_capenable */
> ./dev/pci/if_sip.c:             int             ec_capenable;
> ./dev/pci/if_sip.c:     sc->sc_prev.ec_capenable = 
> sc->sc_ethercom.ec_capenable;
> ./dev/pci/if_sip.c:#define COMPARE_EC(sc) (((sc)->sc_prev.ec_capenable        
>           \
> ./dev/pci/if_sip.c:                      == (sc)->sc_ethercom.ec_capenable)   
>           \
> ./dev/pci/if_sip.c:         (sc->sc_ethercom.ec_capenable & 
> ETHERCAP_VLAN_MTU))
> ./dev/pci/if_sip.c:     sc->sc_prev.ec_capenable = 
> sc->sc_ethercom.ec_capenable;
> ./dev/pci/if_ste.c:     if (sc->sc_ethercom.ec_capenable & ETHERCAP_VLAN_MTU)
> ./dev/pci/if_ste.c:     if (sc->sc_ethercom.ec_capenable & ETHERCAP_VLAN_MTU)
> ./dev/pci/if_stge.c:        ((sc->sc_ethercom.ec_capenable & 
> ETHERCAP_VLAN_MTU) ?
> ./dev/pci/if_ti.c:          (sc->ethercom.ec_capenable & ETHERCAP_VLAN_MTU))
> ./dev/pci/if_ti.c:      if (sc->ethercom.ec_capenable & ETHERCAP_VLAN_MTU)
> ./dev/pci/if_alc.c:     if (sc->sc_ec.ec_capenable & ETHERCAP_VLAN_HWTAGGING)
> ./dev/pci/if_age.c:     if (sc->sc_ec.ec_capenable & ETHERCAP_VLAN_HWTAGGING)
> ./dev/pci/if_ale.c:     if (sc->sc_ec.ec_capenable & ETHERCAP_VLAN_HWTAGGING)
> ./dev/pci/ixgbe/ixgbe.c:        ec->ec_capenable = ec->ec_capabilities;
> ./dev/pci/ixgbe/ixgbe.c:            (ec->ec_capenable & 
> ETHERCAP_VLAN_HWTAGGING) != 0 &&
> ./dev/pci/ixgbe/ixgbe.c:        if (ec->ec_capenable & 
> ETHERCAP_VLAN_HWFILTER) {
> ./dev/sbus/be.c:        if (sc->sc_ethercom.ec_capenable & ETHERCAP_VLAN_MTU)
> ./net/agr/if_agr.c:             ec_port->ec_capenable |= ETHERCAP_VLAN_MTU;
> ./net/agr/if_agr.c:                                     ec_port->ec_capenable 
> &=
> ./net/agr/if_agr.c:             ec_port->ec_capenable &= ~ETHERCAP_VLAN_MTU;
> ./net/agr/if_agrether.c:                ec_port->ec_capenable |= 
> ETHERCAP_VLAN_MTU;
> ./net/agr/if_agrether.c:                                        
> ec_port->ec_capenable &=
> ./net/agr/if_agrether.c:                ec_port->ec_capenable &= 
> ~ETHERCAP_VLAN_MTU;
> ./net/if_ethersubr.c:           eccr->eccr_capenable = ec->ec_capenable;
> ./net/if_ether.h:       int     ec_capenable;                   /* tells 
> hardware which
> ./net/if_vlan.c:                        ec->ec_capenable |= ETHERCAP_VLAN_MTU;
> ./net/if_vlan.c:                                                
> ec->ec_capenable &=
> ./net/if_vlan.c:                        ec->ec_capenable |= 
> ETHERCAP_VLAN_HWTAGGING;
> ./net/if_vlan.c:                        ec->ec_capenable &= 
> ~ETHERCAP_VLAN_MTU;

Perhaps three (or more) types of people exist.

 A) Both ec_capabilities and ec_capenable exist but we use ec_capabilities only.
    The meaning of ec_capabilities is both the capabilities and the setting.

 B) Only ec_capabililties exist.

 C) Both ec_capabilities and ec_capenable exist and these are consistently used 
like other
    capability stuff.

I suspect the majority is A.


> I am curious whether these flags good for anything except diagnosing and
> working around driver bugs?

Currently, there is nothing other than diagnosing. There is no way to stop using
those functions because we have no SIOC*S*ETHERCAP.

> I ask because I don't think the operator
> can ordinarily make a better selection of hardware-capability flags than
> the OS can, except insofar as the OS has bugs and forces the user to
> work around them.  BTW, I think that it is the same for the checksum
> offload / TSO flags as for the ethernet capability flags, but I guess
> that we're kind of stuck with the checksum/TSO flags by now.
> 
> Dave

One of candidate to control ethernet function is (auto) MDI/MDIX, Some PHY have
bugs around the function. If a link partner has the bug, it's a good way to 
control
it with ifconfig.


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

  * 英語 - 自動検出
  * 英語
  * 日本語

  * 英語
  * 日本語

 <javascript:void(0);> <#>