Thank you for the clarification and history. I've updated this to remove any dependency on IFF_DRV_* and make this new private state authoritative. This lays groundwork for DMA fencing I am working on; I can chain a broader sweeping of IFF_DRV_* in iflib and its drivers if this is looking like the right direction.

No comment on the formatting which I am not an expert, but the xref is a valid improvement.

FWIW when we did LB we were really worried about breaking software, and in hindsight we maybe should have just aligned REUSEPORT across a major FreeBSD version with Linux to minimize third party software adaptation. Think hard before adding yet another non-portable sockopt; the LB_CPU_CURRENT behavior sounds desirable unless there is some corner you see. So I agree with Gleb.

Fix E610 VFLINKS

Only set IFVF_F_VLAN_LIMIT when configured

Use BNXT_SRIOV_LOCK around MAC ops

Update to committed netlink API, address review feedback

Update to committed netlink API

Update to committed netlink API

Update against committed netlink API, propagate firmware query failures, tolerate absent CVLAN support, synchronize teardown.

Update against committed netlink interface, reorder after ice bug fixes and features in series

VF status reporting prereq

Add VF status prereq

In D59239#1363827, @cem wrote:

How useful a source of entropy is this? Initial seeding is really the only hard and important part of Fortuna or other system CSPRNGs. The periodic additional mixing is nice, but no one's threat model depends on it. (I'm not opposed, though.)

@kevans I've spent the interim thinking about this occasionally and I think the design is sound with consideration of the existing TPM2.0 harvester and we uncovered some framework decisions that deserve some new thought.

ifdi_power_prepare or whatever lands will also be used in a followup commit to disarm the ixgbe firmware recovery task when the device is suspended.

@ziaee yes this is overcome by b6cd053e6da9 no remaining changes are needed from this.

Add an attach-only refresh latch instead of overloading. Reset recovery still skips redundant PHY programming without republishing link. Reset preparation clears any obsolete attach refresh.

Some background on this change is perhaps worth sharing.. I was originally chasing the up/down/up dance on boot, seeing if I could improve boot speed by carefully driving initial ifnet status through a state machine. But the majority of the time is spent in PHY code so doing something careful in iflib only shaved off xx-xxx milliseconds. Therefore the initial investigation is more of a driver state machine problem, and ice(4) has a good example of doing link state well. This ends up closing a few gaps anyway so here is just the lifecycle relevant part, and it lends naturally to the PM state machine that is a child of this review.

@sumit.saxena_broadcom.com I'm going to help this along since it just needs some trivial changes to lang, I will retain you as the author

Committed as a550e8280b98

I think this is a strict accounting improvement. e1000 manufactures some descriptors in a couple situations to work around hw errata, although I'm not sure that direct RS wb would've faulted.

Switch back to removal. I don't think this is merely a WITNESS ordering issue now, 2f8f892ca344 may cause a timing sensitive deadlock with the existing registration lock and @netchild is hitting it.

In D59294#1360665, @glebius wrote:

Did the original version of this review removed use of IFNET_WLOCK completely? If I understand phabricator correct, that would be URL https://reviews.freebsd.org/D59294?id=185524 I also would prefer this.

@glebius this does not resolve the WITNESS panic between e0e12405285b6 and 2f8f892ca344

Limit this change to the fe00ca2f8871 regression

https://reviews.freebsd.org/D59294

@glebius I am stress testing a fix for the fail point registration, I will tag you when I post it.

Agreed, abandoning this approach

address feedback

address ice(4)

address feedback

iflib(4) change

In D59204#1359477, @netchild wrote:

My build is still running on the old hardware where I can test this.
Quick check, if I get it right:

• this solves the issue where demand is false on the next period.
• this does not solve an issue where ~1 packet per period is send while more than one is in the queue (no idea if this is behavior we can see in the real world): growth every period → demand true every period → armed reaches 4 → still resets.

This is unsafe as is, and needs a broader pass so you can close it.

Still relevant. No.

In D59239#1359142, @kevans wrote:

FWIW- I think the change is largely fine, but the main thought I had when looking at it initially is that it might be worth having its own RANDOM_PURE_TPM12 just in case one wanted to disable just entropy from older chips in their own generic images. We only have something like 4 bits left for new sources at the moment, though, so that kind of needs more deliberation. OTOH, Fortuna's design (as I understand it) means that it doesn't really matter if this single source is lower quality as long as it's not completely broken.

address license format and man page

Thanks for adding csprng. One thing that bears a bit of scrutiny here and the existing tpm20 collector is the registered quality level. https://trustedcomputinggroup.org/resource/sha-1-uses-in-tpm-v1-2/ claims the SHA-1 mixing function does not materially degrade the output and I can link some papers that claim they tend to outperform PRNGs. In a tpm20, you generally have a high(er) quality random source and mixing function, but it could also be a vTPM proxying CPU rdrand or the like.

Apply uio finding from @kevans to tpm20

It's a good catch, The TPM wait paths can return errnos, which the write converts into a succcessful short write once uio_resid has chaged. I restored the original residual when a post-copy TPM op fails, and preserve the short count only after sc_end() succeeds.

Add locality acquire assertion. Release side would be trickier since it is used in abort and cleanup.

OpenBSD carries the same BIT change.