Re: ifp->if_capabilities needs to grow
- In reply to: Hans Petter Selasky : "ifp->if_capabilities needs to grow"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 11 Oct 2021 17:48:54 UTC
Hans, On Mon, Oct 11, 2021 at 11:15:19AM +0200, Hans Petter Selasky wrote: H> As part of ongoing TLS RX work, it has become apparent that H> if_capabilities and if_capenable needs to grow to 64-bits at least. H> H> Right now those fields are 32-bits, and are fully utilized. H> H> The question is how this can be implemented so that a MFC to 13-stable H> is possible. H> H> The most simple solution is to substitute "int" by "uint64_t", but that H> will break the ABI. H> H> Another solution is to use an array of "int" variables. H> H> A third solution is to abandon the two fields when MFC-ing, and adding H> two new 64-bit fields in the end of the ifnet. H> H> Also the user-space API for ifconfig is subject to change. Is there any way to shrink the current list? 1) Is there any NIC that does IFCAP_RXCSUM but can't do IFCAP_TXCSUM? 2) Is there any NIC that IFCAP_TXTLS4 but can't do IFCAP_TXTLS6? 3) All three of IFCAP_WOL_* should belong to 'struct ieee80211com' not to 'struct ifnet'. 4) There are some features that can't be controlled with ifconfig, so don't need to be exported to userland, thus can move to a different field, e.g. "if_capabilities_internal". These include: IFCAP_NETMAP, IFCAP_HWSTATS. It should include IFCAP_MEXTPG but for some reason it is user-controlled. I believe this can be dropped since we already consider mextpgs a seasoned stable feature. I think this list can be made longer. So at least utilizing 4) will give you 3 bits that can be MFCed. -- Gleb Smirnoff