Re: [PATCH 0/6] common/sfc_efx/base: add Medford4 VF support

[Stephen Hemminger <stephen@networkplumber.org>]

On Tue, 11 Aug 2026 21:50:19 +0400
Ivan Malov <ivan.malov@arknetworks.am> 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.