ixv: Support E610 mailbox API 1.6HEADmain

E610 VFs no longer report the actual PF link state and speed through
VFLINKS.  They can consequently report the default 10 Gb/s speed even
when the physical link uses another rate.

Negotiate mailbox API 1.6 on E610 and request the PF link state with its
three-dword operation.  Retain VFLINKS as the fallback when an older PF
rejects API 1.6.  Permit API 1.6 in the inherited xcast and queue
discovery helpers so negotiating the newer revision does not disable
existing operations.

Use GET_QUEUES to replace E610's one-queue fallback with the grant from
the PF.  The common path continues to use one iflib queue set per data
MSI-X vector and caps the result at two queue pairs.

Preserve mailbox transport errors so the driver can distinguish an
explicit PF NACK from a transient timeout.  A NACK means clear-to-send
state was lost and requires a VF reset.  Preserve the last confirmed
link state across brief transport failures and publish link down after
three consecutive failures.

Poll E610 link state every two seconds, matching Intel's ixgbevf service
timer, and phase VFs across the intervening iflib timer ticks.  This
avoids a mailbox polling herd when many VFs share a PF.  Media-status
queries return the cached state instead of starting another synchronous
exchange.  An admin interrupt caused by a mailbox reply only checks for
an unsolicited PF reset, preventing a request/reply interrupt loop.

Hardware validation on an E610 10GBASE-T PF exercised 63 VFs.  Each VF
negotiated API 1.6, two queue pairs, and three MSI-X vectors.  Phased
polling kept 31 active VFs idle, and all 63 recovered after a PF
down/up cycle without watchdogs.

Adapt the API 1.6 link-state operation from DPDK shared ixgbe code.  The
timeout and NACK distinction follows Intel ixgbevf 5.3.25.

MFC after:	2 weeks
Sponsored by:	Dirk-Willem van Gulik from Web Weaving (E610 hardware)
Sponsored by:	BBOX.io

0 files changed, 0 insertions, 0 deletions