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
next prev parent 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).