hn: Refresh VF RSS configuration after link recoveryHEADmain

A VF can finish initialization or reset recovery after hn's handoff-time
RSS query returned ENXIO.  In that case hn suppresses synthetic receive
hash metadata, but previously left it disabled even after the VF could
answer the queries again.

Queue an RSS refresh on a VF link-up notification, using the existing VF
worker in both transparent and non-transparent modes.  Revalidate the
association, active VF path, administrative state, and carrier under
hn_lock before querying and reconfiguring synthetic RSS.  Coalesce the
requests with an atomic flag and retain a request while capability
forwarding temporarily excludes the worker.  Keep the existing query
validity checks and unsupported-query fallback unchanged.

This is a one-shot refresh, not a readiness poll.  Recovery without a
link-up notification, or a query that still fails during the refresh,
does not trigger another retry by itself.  A later link-up or normal
handoff can query again.  Consuming the request while the VF path is
inactive is intentional: the next handoff queries RSS unconditionally.

Continue to reprogram RSS after a successful query even when the cached
key and types match.  They are updated before host reconfiguration and
do not prove that the previous programming succeeded.

The event callback only records and schedules work; RSS queries and host
reconfiguration remain in sleepable context.  No packet-path changes or
new timer are needed.

With an E835 iavf VF, reproduced an ENABLE_QUEUES timeout and an ENXIO
RSS query in both transparent and non-transparent modes.  In each mode
hn restored mbuf_hash after VF recovery, without another interface
reconfiguration.

MFC after:	2 weeks
Sponsored by:	BBOX.io

0 files changed, 0 insertions, 0 deletions