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
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
[Github][CI] Add note about AI tools in good-first-issue text (#173109)
After https://github.com/llvm/llvm-project/pull/172515, we have a new
paragraph in LLVM policy about AI:
> The one exception we reserve is for GitHub issues labelled with the
“good first issue” label. These issues are selected by LLVM contributors
to help newcomers get familiar with the code base. Thus, it makes no
sense to fix them using AI tools. Using AI tools to fix issues labelled
as “good first issues” is forbidden.
We should add disclosure about it in the introduction note for
developers to see clearly.
---------
Co-authored-by: Reid Kleckner <rkleckner at nvidia.com>
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]
[AMDGPU] Stop coercing structs with FP and int fields to integer arrays (#185083)
Fixes #184150
This PR fixes the ABI lowering code for small aggregates (≤64 bits) on
AMDGPU targets to selectively coerce based on element types:
- Structs containing only sub-32-bit integers (char, short): Continue to
coerce to i16/i32/[2 x i32] for efficient register packing
- Structs containing floats or full-sized integers (i32, i64, float,
double): Preserve original types using ABIArgInfo::getDirect() without
coercion
Previously, ALL small aggregates were unconditionally coerced to integer
types. A struct like { float, int } would be lowered to [2 x i32],
losing the floating-point type information. This prevented attaching
FP-specific attributes like nofpclass to the float
component.
[35 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
[OpenACC] Require a complete type for vars-with-restrictions (#192680)
The bug report shows a case where an incomplete type was passed to a
var-list in a clause that has a restriction. Only the 'private',
'firstprivate', and 'reduction' clauses have such restrictions on what
they can reference, so only those will cause problems.
This patch adds a 'completeness' requirement for all 3 of those to make
sure we can properly enforce our restrictions.
Fixes: #192664
[lldb] Don't adopt in the ExecutionContext from auto-continue events (#191433)
When a breakpoint auto-continues, the event handler receives a "stopped
but restarted" event. During the transition where we step over the
breakpoint (before continuing), the public state hasn't yet been set to
running. This caused the `DefaultEventHandler` to call
`ExecutionContextRef` with `adopt_selected=true`, which would fetch
stale thread/frame state and needlessly (and incorrectly) interrupt the
target to compute the execution context (used by the statusline). This
PR fixes that by not doing that.
Fixes #190956
Co-authored-by: Jim Ingham <jingham at apple.com>
[PowerPC] Add builtins for Post Quantum Cryptography Acceleration (#184717)
This patch implements Post Quantum Cryptography (PQC) Acceleration
builtins for PowerPC's future ISA by ensuring that vector operations
(vec_add, vec_sub, vec_mul, vec_mulh) correctly map to VSX instructions
(xvadduwm, xvadduhm, xvsubuwm, xvsubuhm, xvmuluwm, xvmuluhm, xvmulhsw,
xvmulhsh, xvmulhuw, xvmulhuh) when targeting mcpu=future.
Implement new builtin for vec_mulh:
* vector short vec_mulh(vector signed short, vector signed short)
* vector unsigned short vec_mulh(vector unsigned short, vector unsigned
short)
Assisted by AI.
[Clang-Tidy] Fixed `cppcoreguidelines-init-variables` to handle ObjC for-in loops. (#191306)
The check used to report false positive in case of for-in loop in
Objective-C[++]:
```
for (NSString *value in values) {
...
}
```
With the report message:
```
...: warning: variable 'value' is not initialized [cppcoreguidelines-init-variables]
for (NSString *value in values) {
^
= NULL
```
This PR exclude the for-in loop from the the matcher in order to avoid
the false-positive.
Fixes #62106
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
