Re: [EXTERNAL] [PATCH net-next 0/5] hv_netvsc: make XDP propagation act more like bonding

On Tue, Oct 06, 2026 at 01:59:05PM -0700, Kameron Carr wrote:

On 10/2/2026 12:38 PM, Haiyang Zhang wrote:

quoted

Thank you for making this patch set, looks good to me.
I will find a teammate to test it.

- Haiyang

I ran LISA functional tests (T4) in Azure, including XDP related tests
[1], on the patch set based on v7.3-rc6.

I did not see any regressions in my testing, but my testing did not
cover:

  * Hibernation scenarios
  * Kdump tests (not super relevant but worth a note)
  * Performance (XDP or otherwise)
  * Scenarios trying to repro issues found in the patches

Hi Kameron, Jakub,

I tested all five patches applied together on net-next base
8b4e7209c842, with additional targeted lifecycle/error-path
coverage on Azure MANA and mlx5 VFs.

Passing coverage includes:

* VF removal/rejoin: without reattaching the parent program, three
  cycles preserved its program ID. Exact-five synthetic XDP drops
  passed while the VF was absent, and propagation plus exact-five
  live VF XDP drops passed after each rejoin.

* Initial attachment refusal: a program intended for netvsc survived
  five VF-induced attachment failures, then attached and propagated
  successfully after restoring the VF MTU. It was reclaimed after
  detach and pin removal.

* Concurrent replacement/hotplug: while cycling VF availability,
  68 parent-program replacements between PASS and DROP succeeded
  without command errors (38 with the VF present, 30 absent).
  Final PASS/DROP packet checks and program reclamation passed.

* Deferred namespace rejoin: the parent retained the same XDP program;
  the worker moved the VF into its namespace, rejoined it and restored
  propagation, with packet-processing checks.

* Synthetic-device removal: the old program was reclaimed, the
  surviving VF accepted an independent program, and rebinding netvsc
  restored association and connectivity.

* Actual Azure hibernation/resume on mlx5 passed with the VF present
  and with it absent. The parent program and counter-map state survived
  without reattachment; post-resume packet checks passed, including
  propagation to the returning VF in the VF-present case.

* Incompatible arriving VF on mlx5: a VF-only MTU of 9000 caused
  propagation refusal. Netvsc kept the VF unjoined and its existing
  XDP program active on the synthetic path. Restoring the VF MTU and
  re-registering it allowed join, propagation and VF packet processing;
  final reclamation and cleanup passed.

* Join-failure rollback on mlx5: a bridge-induced -EBUSY after
  successful propagation detached XDP from the unjoined VF while
  preserving the parent's program and synthetic-path processing.
  Removing the conflict allowed rejoin, propagation and VF packet
  processing.

I am continuing investigation of synthetic fallback with an
independently programmed MANA VF and rejected-replacement restoration.

Regards,
Vennela

Tested-by: Erni Sri Satya Vennela <redacted>