On Tue, 11 Aug 2026 21:50:19 +0400
Ivan Malov <[email protected]> wrote:
> This series enables DPDK to use the sfc driver
> on a Medford4 VF alongside the PF.
>
> The first patch wires EVB switch operations into the Medford4
> libefx implementation, allowing the PF to manage VFs.
>
> Starting with MCFW 1.4.0.8, VFs may use the netport MCDI for basic port
> configuration, though several operations remain restricted. The
> remaining four patches address each restriction: dummy fixed
> port properties, suppressed event subscription, denied FCS
> and flow control, and ENOTSUP for periodic MAC stats DMA.
>
> This series depends on the VADAPTER statistics series.
>
> Ivan Malov (6):
> common/sfc_efx/base: let Medford4 PF manage VFs
> common/sfc_efx/base: indicate dummy netport properties on VF
> common/sfc_efx/base: skip netport event subscriptions on VFs
> common/sfc_efx/base: deny tuning FCS and flow control to VFs
> common/sfc_efx/base: deny periodic MAC stats delivery to VFs
> doc: announce VF support of AMD Solarflare X45xx family NICs
>
> doc/guides/rel_notes/release_26_11.rst | 4 ++
> drivers/common/sfc_efx/base/efx_evb.c | 6 ++
> drivers/common/sfc_efx/base/efx_np.c | 91 ++++++++++++++++++++++----
> 3 files changed, 89 insertions(+), 12 deletions(-)
>
Some AI feedback, no real errors
Series: [PATCH 0/6] SFC Medford4 VF support (Ivan Malov)
Reviewed against DPDK main @ c1a46b9; all 6 patches apply with git am.
Full-series build (gcc 13, -Dwerror=true) is clean.
Patch 2/6: common/sfc_efx/base: indicate dummy netport properties on VF
Warning: The dummy capability mask makes the VF report a 1 Gbps port.
efx_np_get_fixed_port_props() returns only EFX_PHY_CAP_1000FDX as the
supported link speed. That value flows to epp->ep_phy_cap_mask, then to
sfc_port_attach() via efx_phy_adv_cap_get(EFX_PHY_CAP_PERM), and finally
to dev_info.speed_capa in sfc_dev_infos_get(). A VF on an X4522/X4542
will therefore advertise RTE_ETH_LINK_SPEED_1G and nothing else.
The consequence is not cosmetic. sfc_check_conf() computes
sa->port.phy_adv_cap = sfc_phy_cap_from_link_speeds(conf->link_speeds)
& sa->port.phy_adv_cap_mask;
and fails configure with EINVAL if the result is empty. An application
that requests a specific speed (RTE_ETH_LINK_SPEED_25G, for example)
rather than autoneg cannot configure the VF at all, and one that reads
speed_capa to pick a speed will pick 1G.
efx_np_link_state() is called a few lines later in efx_np_attach() and
does work on a VF; ls.enls_adv_cap_mask holds the real advertised
abilities. Suggest deriving the VF capability mask from that instead of
hardcoding 1000FDX, e.g. fold ls.enls_adv_cap_mask into
epp->ep_phy_cap_mask for VFs after the efx_np_link_state() call.
Info: sup_cap_rawp and loopback_cap_maskp are left untouched on the VF
path. This is not a use-of-uninitialised bug -- efx_nic_create() uses
EFSYS_KMEM_ALLOC, which is rte_zmalloc, so epp->ep_np_cap_data_raw and
ep_np_loopback_cap_mask are zero. Worth a note in the commit message
that zero is the intended value, since efx_np_assign_lane_counts() and
efx_np_assign_loopback_props() both consume them.
Info: The dummy mask sets EFX_PHY_CAP_AN, and efx_np_attach() sets the
same bit again from ls.enls_an_supported at line 1026. Harmless, but
one of the two is redundant.
Patch 6/6: doc: announce VF support of AMD Solarflare X45xx family NICs
Warning: Commit message claims work that is not in this series.
"The Solarflare PMD has been updated to support VADAPTER statistics and
to let the user attach to the X4 VFs". There is no VADAPTER statistics
change in this series, and grep finds no vadaptor/VADAPTER reference in
drivers/net/sfc or in the release notes hunk. Either drop that clause or
add the corresponding release notes entry.
Warning: doc/guides/nics/sfc_efx.rst is not updated.
The feature list has "SR-IOV PF" but not VF. The features matrix
(doc/guides/nics/features/sfc.ini) already has SR-IOV = Y, so only the
prose list is stale. Since the series makes VF attach work on Medford4,
the driver guide should say so.
