netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Edward Cree <ecree.xilinx@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: ecree@xilinx.com, davem@davemloft.net, pabeni@redhat.com,
	linux-net-drivers@amd.com, netdev@vger.kernel.org
Subject: Re: [PATCH net-next v2 12/14] sfc: set EF100 VF MAC address through representor
Date: Thu, 28 Jul 2022 19:12:34 +0100	[thread overview]
Message-ID: <8bfec647-1516-c738-5977-059448e35619@gmail.com> (raw)
In-Reply-To: <20220728092008.2117846e@kernel.org>

On 28/07/2022 17:20, Jakub Kicinski wrote:
> It's set thru
> 
>  devlink port function set DEV/PORT_INDEX hw_addr ADDR
> 
> "port functions" is a weird object representing something 
> in Mellanox FW. Hopefully it makes more sense to you than
> it does to me.
Hmm that does look weird, looks like it acts on a PCI device
 (DEV is a PCI address) and then I'm not sure what PORT_INDEX
 is meant to mean (the man page doesn't describe it at all).
 Possibly it doesn't have semantics as such and is just a
 synthetic index into a list of ports…
I can't say it makes sense to me either :shrug:

We did take a look at what nfp does, as well; they use the
 old .ndo_set_vf_mac(), but they appear to support it both on
 the PF and on the VF reprs — meaning that (AFAICT) it allows
 to set the MAC address of VF 0 through the repr for VF 1.
(There is no check that I can see in nfp_app_set_vf_mac()
 that the value of `int vf` matches the caller.)

Our (SN1000) approach to the problem of configuring 'remote'
 functions (VFs in VMs, PFs on the embedded SoC) is to use
 representors for them all (VF reps as added in this & prev
 series, PF reps coming in the future.  Similarly, if we
 were ever to add Subfunctions, each SF would have a
 corresponding SF representor that would work in much the
 same way as VF reps).  At which point you should always be
 able to configure an object through its associated rep,
 and there should never be a need for an 'index' parameter
 (be that 'VF index' or 'port index').
While .ndo_set_mac_address() might be the Wrong Thing (if
 we want to be able to set VF and VF-rep addresses
 independently to different things), the Right Thing ought
 to have the same signature (i.e. just taking a netdev and
 a hwaddr).  Devlink seems to me like a needless
 complication here.

Anyway, since the proper direction is unclear, I'll respin
 the series without patches 10-13 in the hope of getting
 the rest of it in before the merge window.

-ed

  reply	other threads:[~2022-07-28 18:12 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-27 17:45 [PATCH net-next v2 00/14] sfc: VF representors for EF100 - RX side ecree
2022-07-27 17:45 ` [PATCH net-next v2 01/14] sfc: plumb ef100 representor stats ecree
2022-07-27 17:45 ` [PATCH net-next v2 02/14] sfc: ef100 representor RX NAPI poll ecree
2022-07-27 17:45 ` [PATCH net-next v2 03/14] sfc: ef100 representor RX top half ecree
2022-07-27 17:45 ` [PATCH net-next v2 04/14] sfc: determine wire m-port at EF100 PF probe time ecree
2022-07-27 17:45 ` [PATCH net-next v2 05/14] sfc: check ef100 RX packets are from the wire ecree
2022-07-27 17:45 ` [PATCH net-next v2 06/14] sfc: receive packets from EF100 VFs into representors ecree
2022-07-27 17:45 ` [PATCH net-next v2 07/14] sfc: insert default MAE rules to connect VFs to representors ecree
2022-07-27 17:45 ` [PATCH net-next v2 08/14] sfc: move table locking into filter_table_{probe,remove} methods ecree
2022-07-27 17:45 ` [PATCH net-next v2 09/14] sfc: use a dynamic m-port for representor RX and set it promisc ecree
2022-07-27 17:46 ` [PATCH net-next v2 10/14] sfc: look up VF's client ID when creating representor ecree
2022-07-27 17:46 ` [PATCH net-next v2 11/14] sfc: fetch existing assigned MAC address from FW when creating VF rep ecree
2022-07-27 17:46 ` [PATCH net-next v2 12/14] sfc: set EF100 VF MAC address through representor ecree
2022-07-28  3:10   ` Jakub Kicinski
2022-07-28 15:47     ` Edward Cree
2022-07-28 16:20       ` Jakub Kicinski
2022-07-28 18:12         ` Edward Cree [this message]
2022-07-28 18:32           ` Jakub Kicinski
2022-07-28 18:54             ` Edward Cree
2022-07-28 19:27               ` Jakub Kicinski
2022-07-28 20:23                 ` Edward Cree
2022-07-29  1:45                   ` Jakub Kicinski
2022-07-29 15:17                     ` Edward Cree
2022-07-27 17:46 ` [PATCH net-next v2 13/14] sfc: get provisioned MAC address on EF100 VF probe ecree
2022-07-27 17:46 ` [PATCH net-next v2 14/14] sfc: implement ethtool get/set RX ring size for EF100 reps ecree

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8bfec647-1516-c738-5977-059448e35619@gmail.com \
    --to=ecree.xilinx@gmail.com \
    --cc=davem@davemloft.net \
    --cc=ecree@xilinx.com \
    --cc=kuba@kernel.org \
    --cc=linux-net-drivers@amd.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).