(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 (msai...@execsw.org msai...@netbsd.org) * 英語 - 自動検出 * 英語 * 日本語 * 英語 * 日本語 <javascript:void(0);> <#>