iflib: accurately count bytes/segments for TSO
When using software based ifnet counters, iflib has not factored
TSO into account when reporting the segments and bytes sent.
So it will underreport NIC bandwidth by a small percent,
and will undercount sent segments by a large factor.
Fix this by calculating the number of added segments the NIC
will send, and add header size multiplied by that number
to arrive at a correct accounting of segments and bytes sent.
This makes these software counters directly comparable to
hardware counters.
Doing this requires moving the calculation into iflib_encap() where
we have already parsed the packet and know the header size, MSS, etc.
Differential Revision: https://reviews.freebsd.org/D56338
Sponsored by: Netflix
iflib: ignore reclaim coalescing when low on tx descriptors
If we are low on TX descriptors, bypass iflib_txq_can_reclaim()
and force a reclaim. This is intended to reduce the number of
output drops under heavy load when using simple transmit.
Differential Revision: https://reviews.freebsd.org/D56339
Sponsored by: Netflix
ixgbe: improve MDIO performance by reducing semaphore/IPC delays
Each MDIO transfer takes 8ms, and all of that is spent in a set
of DELAY() calls, which is consuming a LOT of CPU.
* Change the timeout in ixgbe_hic_unlocked() - doing IPC to the
on-chip firmware - to a 1uS delay and bump timeout appropriately.
This seems to finish in a couple of microseconds on my local
test devices.
* Change the 2ms sleep in ixgbe_release_swfw_sync_X540() to 2ms
for EEPROM/flash, and 10uS otherwise. 10uS seems to work fine
on my local testing, but the config EEPROM doesn't read right
without this extra delay.
The first change shouldn't change the driver behaviour, but the
latter change is more intrusive and needs some wider testing.
(My guess here is that there SHOULD have been some completion
check somewhere in the EEPROM/flash IO path, and these sleeps
[8 lines not shown]
ixgbe: add MDIO bus support
This works enough to let me see the marvell switch on the MDIO bus.
It uses clause 22, which ixgbe's existing MDIO code doesn't currently
support, so it's implemented in a new source file.
Since mdio(4) is now required, add it where appropriate to GENERIC kernels.
Reviewed by: kbowling
Differential Revision: https://reviews.freebsd.org/D50128
boot1.chrp: Improve comment for the SLOF hack
Since this original comment was written, the actual issue in SLOF
was diagnosed and documented in commit 424089a0fc, which fixed it
for loader(8). Update the comment in boot1 to be more informative
to future readers.
MFC after: 3 days
Reviewed by: jhibbits, adrian
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D56470
filesystems/amazon-efs-utils: New port
Amazon EFS mount helper and watchdog utilities. Provides mount_efs(8) to mount
EFS filesystems over NFSv4.1, optionally via a local stunnel-like proxy
(efs-proxy) that terminates TLS 1.2 and handles IAM authentication using SigV4.
A watchdog daemon, started by mount_efs, monitors the proxy and restarts it if
it dies.
FreeBSD-specific adaptations:
- Binary installed as mount_efs, not mount.efs
- Uses /sbin/mount_nfs with nfsv4,minorversion=1,oneopenown,retrycnt=1
- Watchdog enumerates /var/run/efs state files cross-checked with
"mount -t nfs" (FreeBSD has no /proc/mounts and mount(8)/nfsstat(8)
do not expose the client TCP port)
- aarch64 build fix: the libc crate does not expose max_align_t for
aarch64-unknown-freebsd; substitute align_of::<u128>() in s2n-tl
Sponsored by: Netflix
loader.efi: Defer efi_translate(e_entry) until after bi_load
bi_load itself loads various things into the staging area which can
cause it to grow, which may result in the staging area moving, including
the kernel. Therefore the address we get for the kernel entry point
prior to bi_load may not be correct afterwards when we actually call it,
and so we must defer the translation.
On arm and riscv (but not arm64, which predates both of them in
loader.efi and did not gain a copy of arm's added printf when arm
support was added) we also printf this entry point to the console, which
we can no longer do since bi_load calls ExitBootServices, so remove this
printf that, in practice, seems to not be so useful, given nobody ever
felt the need to add it to arm64. If anyone really feels this is an
important printf to have then bi_load will need to be split so we can
call printf after all the loading and potential reallocation of the
staging area, but before ExitBootServices is called.
We may also want to make this code more uniform and shared between the
[10 lines not shown]