| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 23 Jan 2023 11:18:03 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: "Lucero Palau, Alejandro" <alejandro.lucero-palau@....com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-net-drivers (AMD-Xilinx)" <linux-net-drivers@....com>,
"davem@...emloft.net" <davem@...emloft.net>,
"kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"habetsm@...il.com" <habetsm@...il.com>,
"ecree.xilinx@...il.com" <ecree.xilinx@...il.com>
Subject: Re: [PATCH net-next 6/7] sfc: add support for
port_function_hw_addr_get devlink in ef100
Mon, Jan 23, 2023 at 10:45:47AM CET, alejandro.lucero-palau@....com wrote:
>
>On 1/23/23 08:38, Jiri Pirko wrote:
>> Sun, Jan 22, 2023 at 05:36:14PM CET, alejandro.lucero-palau@....com wrote:
>>> On 1/20/23 12:48, Lucero Palau, Alejandro wrote:
>>>> On 1/20/23 11:08, Jiri Pirko wrote:
>>>>> Thu, Jan 19, 2023 at 04:09:27PM CET, alejandro.lucero-palau@....com wrote:
>>>>>> On 1/19/23 12:37, Jiri Pirko wrote:
>>>>>>> Thu, Jan 19, 2023 at 12:31:39PM CET, alejandro.lucero-palau@....com wrote:
>>>>>>>> From: Alejandro Lucero <alejandro.lucero-palau@....com>
>>>>>>>>
>>>>>>>> Using the builtin client handle id infrastructure, this patch adds
>>>>>>>> support for obtaining the mac address linked to mports in ef100. This
>>>>>>>> implies to execute an MCDI command for getting the data from the
>>>>>>>> firmware for each devlink port.
>>>>>>>>
>>>>>>>> Signed-off-by: Alejandro Lucero <alejandro.lucero-palau@....com>
>>>>>>>> ---
>>>>>>>> drivers/net/ethernet/sfc/ef100_nic.c | 27 ++++++++++++++++
>>>>>>>> drivers/net/ethernet/sfc/ef100_nic.h | 1 +
>>>>>>>> drivers/net/ethernet/sfc/ef100_rep.c | 8 +++++
>>>>>>>> drivers/net/ethernet/sfc/ef100_rep.h | 1 +
>>>>>>>> drivers/net/ethernet/sfc/efx_devlink.c | 44 ++++++++++++++++++++++++++
>>>>>>>> 5 files changed, 81 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/drivers/net/ethernet/sfc/ef100_nic.c b/drivers/net/ethernet/sfc/ef100_nic.c
>>>>>>>> index f4e913593f2b..4400ce622228 100644
>>>>>>>> --- a/drivers/net/ethernet/sfc/ef100_nic.c
>>>>>>>> +++ b/drivers/net/ethernet/sfc/ef100_nic.c
>>>>>>>> @@ -1121,6 +1121,33 @@ static int ef100_probe_main(struct efx_nic *efx)
>>>>>>>> return rc;
>>>>>>>> }
>>>>>>>>
>>>>>>>> +/* MCDI commands are related to the same device issuing them. This function
>>>>>>>> + * allows to do an MCDI command on behalf of another device, mainly PFs setting
>>>>>>>> + * things for VFs.
>>>>>>>> + */
>>>>>>>> +int efx_ef100_lookup_client_id(struct efx_nic *efx, efx_qword_t pciefn, u32 *id)
>>>>>>>> +{
>>>>>>>> + MCDI_DECLARE_BUF(outbuf, MC_CMD_GET_CLIENT_HANDLE_OUT_LEN);
>>>>>>>> + MCDI_DECLARE_BUF(inbuf, MC_CMD_GET_CLIENT_HANDLE_IN_LEN);
>>>>>>>> + u64 pciefn_flat = le64_to_cpu(pciefn.u64[0]);
>>>>>>>> + size_t outlen;
>>>>>>>> + int rc;
>>>>>>>> +
>>>>>>>> + MCDI_SET_DWORD(inbuf, GET_CLIENT_HANDLE_IN_TYPE,
>>>>>>>> + MC_CMD_GET_CLIENT_HANDLE_IN_TYPE_FUNC);
>>>>>>>> + MCDI_SET_QWORD(inbuf, GET_CLIENT_HANDLE_IN_FUNC,
>>>>>>>> + pciefn_flat);
>>>>>>>> +
>>>>>>>> + rc = efx_mcdi_rpc(efx, MC_CMD_GET_CLIENT_HANDLE, inbuf, sizeof(inbuf),
>>>>>>>> + outbuf, sizeof(outbuf), &outlen);
>>>>>>>> + if (rc)
>>>>>>>> + return rc;
>>>>>>>> + if (outlen < sizeof(outbuf))
>>>>>>>> + return -EIO;
>>>>>>>> + *id = MCDI_DWORD(outbuf, GET_CLIENT_HANDLE_OUT_HANDLE);
>>>>>>>> + return 0;
>>>>>>>> +}
>>>>>>>> +
>>>>>>>> int ef100_probe_netdev_pf(struct efx_nic *efx)
>>>>>>>> {
>>>>>>>> struct ef100_nic_data *nic_data = efx->nic_data;
>>>>>>>> diff --git a/drivers/net/ethernet/sfc/ef100_nic.h b/drivers/net/ethernet/sfc/ef100_nic.h
>>>>>>>> index e59044072333..f1ed481c1260 100644
>>>>>>>> --- a/drivers/net/ethernet/sfc/ef100_nic.h
>>>>>>>> +++ b/drivers/net/ethernet/sfc/ef100_nic.h
>>>>>>>> @@ -94,4 +94,5 @@ int ef100_filter_table_probe(struct efx_nic *efx);
>>>>>>>>
>>>>>>>> int ef100_get_mac_address(struct efx_nic *efx, u8 *mac_address,
>>>>>>>> int client_handle, bool empty_ok);
>>>>>>>> +int efx_ef100_lookup_client_id(struct efx_nic *efx, efx_qword_t pciefn, u32 *id);
>>>>>>>> #endif /* EFX_EF100_NIC_H */
>>>>>>>> diff --git a/drivers/net/ethernet/sfc/ef100_rep.c b/drivers/net/ethernet/sfc/ef100_rep.c
>>>>>>>> index ff0c8da61919..974c9ff901a0 100644
>>>>>>>> --- a/drivers/net/ethernet/sfc/ef100_rep.c
>>>>>>>> +++ b/drivers/net/ethernet/sfc/ef100_rep.c
>>>>>>>> @@ -362,6 +362,14 @@ bool ef100_mport_on_local_intf(struct efx_nic *efx,
>>>>>>>> mport_desc->interface_idx == nic_data->local_mae_intf;
>>>>>>>> }
>>>>>>>>
>>>>>>>> +bool ef100_mport_is_vf(struct mae_mport_desc *mport_desc)
>>>>>>>> +{
>>>>>>>> + bool pcie_func;
>>>>>>>> +
>>>>>>>> + pcie_func = ef100_mport_is_pcie_vnic(mport_desc);
>>>>>>>> + return pcie_func && (mport_desc->vf_idx != MAE_MPORT_DESC_VF_IDX_NULL);
>>>>>>>> +}
>>>>>>>> +
>>>>>>>> void efx_ef100_init_reps(struct efx_nic *efx)
>>>>>>>> {
>>>>>>>> struct ef100_nic_data *nic_data = efx->nic_data;
>>>>>>>> diff --git a/drivers/net/ethernet/sfc/ef100_rep.h b/drivers/net/ethernet/sfc/ef100_rep.h
>>>>>>>> index 9cca41614982..74853ccbc937 100644
>>>>>>>> --- a/drivers/net/ethernet/sfc/ef100_rep.h
>>>>>>>> +++ b/drivers/net/ethernet/sfc/ef100_rep.h
>>>>>>>> @@ -75,4 +75,5 @@ void efx_ef100_fini_reps(struct efx_nic *efx);
>>>>>>>> struct mae_mport_desc;
>>>>>>>> bool ef100_mport_on_local_intf(struct efx_nic *efx,
>>>>>>>> struct mae_mport_desc *mport_desc);
>>>>>>>> +bool ef100_mport_is_vf(struct mae_mport_desc *mport_desc);
>>>>>>>> #endif /* EF100_REP_H */
>>>>>>>> diff --git a/drivers/net/ethernet/sfc/efx_devlink.c b/drivers/net/ethernet/sfc/efx_devlink.c
>>>>>>>> index bb19d3ad7ffd..2a57c4f6d2b2 100644
>>>>>>>> --- a/drivers/net/ethernet/sfc/efx_devlink.c
>>>>>>>> +++ b/drivers/net/ethernet/sfc/efx_devlink.c
>>>>>>>> @@ -429,6 +429,49 @@ static int efx_devlink_add_port(struct efx_nic *efx,
>>>>>>>> return err;
>>>>>>>> }
>>>>>>>>
>>>>>>>> +static int efx_devlink_port_addr_get(struct devlink_port *port, u8 *hw_addr,
>>>>>>>> + int *hw_addr_len,
>>>>>>>> + struct netlink_ext_ack *extack)
>>>>>>>> +{
>>>>>>>> + struct efx_devlink *devlink = devlink_priv(port->devlink);
>>>>>>>> + struct mae_mport_desc *mport_desc;
>>>>>>>> + efx_qword_t pciefn;
>>>>>>>> + u32 client_id;
>>>>>>>> + int rc = 0;
>>>>>>>> +
>>>>>>>> + mport_desc = efx_mae_get_mport(devlink->efx, port->index);
>>>>>>> I may be missing something, where do you fail with -EOPNOTSUPP
>>>>>>> in case this is called for PHYSICAL port ?
>>>>>>>
>>>>>> We do not create a devlink port for the physical port.
>>>>> Well, you do:
>>>>>
>>>>> + switch (mport->mport_type) {
>>>>> + case MAE_MPORT_DESC_MPORT_TYPE_NET_PORT:
>>>>> + attrs.flavour = DEVLINK_PORT_FLAVOUR_PHYSICAL;
>>>>>
>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> Right.
>>>>
>>>> I was relying on devlink-port output which does not show the physical
>>>> port in my machine and completely forgot about it.
>>>>
>>>> I'm a bit confused at this point. Let me look at this further.
>>>>
>>> The reason devlink show/info does not report the PHYSICAL port is
>>> simple: current code does not create a devlink port for such mport.
>>>
>>> I say current code because in my first implementation (not upstreamed) I
>>> just created devlink ports when the mports where enumerated, what turned
>>> out to be a bit complicated for dealing with VFs creation/destruction,
>>> and after looking at how other drivers do this, just before the related
>>> netdev is registered, I went for that same approach. That leaves no
>>> option for the physical mport registered.
>>>
>>> I could add that creation at PF devlink port creation, if we consider
>>> this a necessity. I know the ideal devlink support in our driver should
>>> likely be more devlink design compliant, but it is also true drivers
>>> should make use of it as decided for fulfilling their necessities as
>>> long as it does not create confusion to users. Our current devlink
>>> necessity is for dealing with setting VFs mac address as required during
>>> previous representors patchset review:
>>>
>>> https://lore.kernel.org/netdev/20220728092008.2117846e@kernel.org/
>>>
>>> Do you see a problem not creating such a devlink port by now?
>> You don't have to create it. But loose the code setting PHYSICAL
>> flavour.
>>
>I'll do so adding a comment discarding the physical port creation.
Yes, and remove the related code.
>
>
>Thanks.
>
>>
>>>>> + attrs.phys.port_number = mport->port_idx;
>>>>> + devlink_port_attrs_set(dl_port, &attrs);
>>>>> + break;
>>>>> + case MAE_MPORT_DESC_MPORT_TYPE_VNIC:
>>>>> + if (mport->vf_idx != MAE_MPORT_DESC_VF_IDX_NULL) {
>>>>> + devlink_port_attrs_pci_vf_set(dl_port, 0, mport->pf_idx,
>>>>> + mport->vf_idx,
>>>>> + external);
>>>>> + } else {
>>>>> + devlink_port_attrs_pci_pf_set(dl_port, 0, mport->pf_idx,
>>>>> + external);
>>>>> + }
>>>>> + break;
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> I'm aware this is not "fully compliant" with devlink design idea, just
>>>>>> trying to use it for our current urgent necessities by now.
>>>>>>
>>>>>> Do you think this could be a problem?
>>>>> If you create port flavour = DEVLINK_PORT_FLAVOUR_PHYSICAL and it is not
>>>>> uplink, it is a problem :)
>>>>>
>>>>>
>>>>>
>>>>>>>> + if (!mport_desc)
>>>>>>>> + return -EINVAL;
>>>>>>>> +
>>>>>>>> + if (!ef100_mport_on_local_intf(devlink->efx, mport_desc))
>>>>>>>> + goto out;
>>>>>>>> +
>>>>>>>> + if (ef100_mport_is_vf(mport_desc))
>>>>>>>> + EFX_POPULATE_QWORD_3(pciefn,
>>>>>>>> + PCIE_FUNCTION_PF, PCIE_FUNCTION_PF_NULL,
>>>>>>>> + PCIE_FUNCTION_VF, mport_desc->vf_idx,
>>>>>>>> + PCIE_FUNCTION_INTF, PCIE_INTERFACE_CALLER);
>>>>>>>> + else
>>>>>>>> + EFX_POPULATE_QWORD_3(pciefn,
>>>>>>>> + PCIE_FUNCTION_PF, mport_desc->pf_idx,
>>>>>>>> + PCIE_FUNCTION_VF, PCIE_FUNCTION_VF_NULL,
>>>>>>>> + PCIE_FUNCTION_INTF, PCIE_INTERFACE_CALLER);
>>>>>>>> +
>>>>>>>> + rc = efx_ef100_lookup_client_id(devlink->efx, pciefn, &client_id);
>>>>>>>> + if (rc) {
>>>>>>>> + netif_err(devlink->efx, drv, devlink->efx->net_dev,
>>>>>>>> + "Failed to get client ID for port index %u, rc %d\n",
>>>>>>>> + port->index, rc);
>>>>>>>> + return rc;
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + rc = ef100_get_mac_address(devlink->efx, hw_addr, client_id, true);
>>>>>>>> +out:
>>>>>>>> + *hw_addr_len = ETH_ALEN;
>>>>>>>> +
>>>>>>>> + return rc;
>>>>>>>> +}
>>>>>>>> +
>>>>>>>> static int efx_devlink_info_get(struct devlink *devlink,
>>>>>>>> struct devlink_info_req *req,
>>>>>>>> struct netlink_ext_ack *extack)
>>>>>>>> @@ -442,6 +485,7 @@ static int efx_devlink_info_get(struct devlink *devlink,
>>>>>>>>
>>>>>>>> static const struct devlink_ops sfc_devlink_ops = {
>>>>>>>> .info_get = efx_devlink_info_get,
>>>>>>>> + .port_function_hw_addr_get = efx_devlink_port_addr_get,
>>>>>>>> };
>>>>>>>>
>>>>>>>> static struct devlink_port *ef100_set_devlink_port(struct efx_nic *efx, u32 idx)
>>>>>>>> --
>>>>>>>> 2.17.1
>>>>>>>>
>
Powered by blists - more mailing lists