Yes, as the manpage for the bus_release_resource(9) family of functions says: "The bus methods are free to change the RIDs that they are given as a parameter. You must not depend on the value you gave it earlier." On way do deal with that is to cache the returned RID in e. g. the softc. As is, em(4) does that for adapter->ioport via adapter->io_rid, but not for the adapter->flash and adapter->memory resources. The summary doesn't state this correctly, sorry, I'll address that when committing.

Close; obsoleted by r342634.

Close; obsoleted by r340543; thanks for the original patch!

It probably makes sense and is safe to bump DMA_BLOCK_SIZE and DMA_BOUNDARY. However, in order to not waste considerable amounts of the static buffer, they should be based on MAXPHYS (which defaults to 128 KiB) as FreeBSD simply won't do transfers larger than that. The 512 KiB maximum SDMA buffer boundary also needs to be taken into account with these, though, as MAXPHYS is configurable.
That said, I'm not sure bumping DMA_BLOCK_SIZE and DMA_BOUNDARY is worth the trouble; the SDHCI controllers of the SDMA-only era are known to be very quirky, which is why sdhci(4) e. g. implements its own variant of bounce buffering in order to deal with their problematic DMA engines. So I'd rather focus on implementing support for ADMA up to 64-bit ADMA3 and be done with the limitations of SDMA on newer gear and the fallout such a bump may cause with older.

Looks good to me. FYI, I get:

FYI, the few integrated ISA devices found in some sun4u and sun4v machines in fact can do 32-bit DMA so VM_FREELIST_ISADMA can go for sparc64 without a replacement, too.

Well, I'd prefer to also have feedback from at least shurd@ regarding bnxt(4) as I have no idea what the DMA/TSO constraints of the MACs it drives actually are (the links to the corresponding datasheets on broadcom.com are broken, unfortunately). It's rather unlikely that those DMA engines are really limited to 64 KB, i. e. BNXT_TSO_SIZE most likely only applies to TSO itself only, but you never know (I did check with the Intel datasheets for the other drivers, FWIW).

Extend to ixl(4)/ixlv(4) after their conversion to iflib(9) in r335338. Akin e1000,
after that conversion these drivers did redundant setup of interface capabilities in
ixl{v,}_setup_interface() and had defunct (but due to r203548 also obsolete) code
to disable IFCAP_VLAN_HWFILTER by default.

Okay, then let's try to handle this the right way. Changes since the
previous version of the patch:

• Add an isc_capabilities to struct if_softc_ctx so iflib(9) can also handle interface capabilities that shouldn't be enabled by default; use that to handle default-off capabilities of e1000 and move their handling from em_setup_interface() to em_if_attach_pre() accordingly.
• Add isc_tso_max{seg,}size DMA engine constraints for the TSO DMA tag to struct if_shared_ctx and let iflib_txsd_alloc() automatically adjust the maxsize of that tag in case IFCAP_VLAN_MTU is supported.
• Move the if_setifheaderlen(9) call for adjusting the maximum Ethernet header length from {ixgbe,ixv,em}_setup_interface() to iflib(9) so adjustment is automatically done in case IFCAP_VLAN_MTU is supported. As a consequence, this adjustment now is also done in case of bnxt(4) which missed it previously.
• Remove code to disable IFCAP_VLAN_HWFILTER by default for ixgbe(4) (already not done for ixgbev(4)) as VLAN events are now passed through by lagg(4) since r203548.
• Don't bother to fiddle with IFCAP_HWSTATS in ixgbe(4)/ixgbev(4) as iflib(9) adds that capability unconditionally.
• Bump __FreeBSD_version for the above changes as modules using iflib(9) need to be recompiled.

Same diff, more context

The problem with letting iflib(9) automatically register a TSO DMA tag with a maxsize of isc_tx_tso_size_max + sizeof(struct ether_vlan_header) if the front-end driver declares IFCAP_VLAN_MTU as being supported is that besides a MAC having a restriction on the maximum TSO size, its DMA engine might have a restriction on the maximum transfer size as well (in fact, that's what the maxsize DMA tag parameter is all about). Suppose a MAC supports a maximum TSO size of 64 KB and its DMA engine has a 64 KB limit on transfers as well, one wouldn't be able to support a maximum TSO size of IP_MAXPACKET when doing software VLAN tagging. Actually, that's why I've added you as a reviewer because I don't have a datasheet for the bnxt(4)-driven MACs.