Re: ifp->if_capabilities needs to grow

From: Gleb Smirnoff <glebius_at_freebsd.org>
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