From: Simon Horman <simon.horman@corigine.com>
To: Gautam Dawar <gautam.dawar@amd.com>
Cc: linux-net-drivers@amd.com, jasowang@redhat.com,
Edward Cree <ecree.xilinx@gmail.com>,
Martin Habets <habetsm.xilinx@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Richard Cochran <richardcochran@gmail.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
eperezma@redhat.com, harpreet.anand@amd.com, tanuj.kamde@amd.com,
koushik.dutta@amd.com
Subject: Re: [PATCH net-next v4 06/14] sfc: implement vDPA management device operations
Date: Mon, 10 Apr 2023 12:22:42 +0200 [thread overview]
Message-ID: <ZDPjcpBQBPqmZKh1@corigine.com> (raw)
In-Reply-To: <20230407081021.30952-7-gautam.dawar@amd.com>
On Fri, Apr 07, 2023 at 01:40:07PM +0530, Gautam Dawar wrote:
> To allow vDPA device creation and deletion, add a vDPA management
> device per function. Currently, the vDPA devices can be created
> only on a VF. Also, for now only network class of vDPA devices
> are supported.
>
> Signed-off-by: Gautam Dawar <gautam.dawar@amd.com>
Hi Gautam,
some minor feedback from my side is inline.
> diff --git a/drivers/net/ethernet/sfc/ef100_nic.c b/drivers/net/ethernet/sfc/ef100_nic.c
...
> @@ -1286,13 +1286,35 @@ int ef100_probe_netdev_pf(struct efx_nic *efx)
>
> int ef100_probe_vf(struct efx_nic *efx)
> {
> - return ef100_probe_main(efx);
> + struct ef100_nic_data *nic_data __maybe_unused;
> + int rc;
> +
> + rc = ef100_probe_main(efx);
> + if (rc)
> + return rc;
> +
> +#ifdef CONFIG_SFC_VDPA
> + nic_data = efx->nic_data;
> + if (nic_data->vdpa_supported) {
> + rc = ef100_vdpa_register_mgmtdev(efx);
> + if (rc)
> + pci_warn(efx->pci_dev,
> + "register_mgmtdev failed, rc: %d\n", rc);
> + }
> +#endif
I think it would be nicer to factor the #ifdef coded out, perhaps into a
helper like this (completely untested!).
void ef100_probe_vf_vdpa(struct efx_nic *efx)
{
#ifdef CONFIG_SFC_VDPA
struct ef100_nic_data *nic_data = efx->nic_data;
nic_data = efx->nic_data;
if (nic_data->vdpa_supported) {
int rc = ef100_vdpa_register_mgmtdev(efx);
if (rc)
pci_warn(efx->pci_dev,
"register_mgmtdev failed, rc: %d\n", rc);
}
#endif
}
Or perhaps an approach similar to the one you have taken,
but using IS_ENABLED() rather than #ifdef
> +
> + return 0;
> }
>
> void ef100_remove(struct efx_nic *efx)
> {
> struct ef100_nic_data *nic_data = efx->nic_data;
>
> +#ifdef CONFIG_SFC_VDPA
> + if (nic_data->vdpa_supported)
nic_data is dereferenced here.
But a bit futher down this function there is a check for nic_data being NULL.
Reported by Smatch as:
drivers/net/ethernet/sfc/ef100_nic.c:1325 ef100_remove() warn: variable dereferenced before check 'nic_data' (see line 1314)
> + ef100_vdpa_unregister_mgmtdev(efx);
> +#endif
Again, I think it would be nice to factor this #ifdef out somehow.
> +
> if (IS_ENABLED(CONFIG_SFC_SRIOV) && efx->mae) {
> efx_ef100_fini_reps(efx);
> efx_fini_mae(efx);
> diff --git a/drivers/net/ethernet/sfc/ef100_nic.h b/drivers/net/ethernet/sfc/ef100_nic.h
> index a01e9d643ccd..e63ea555116c 100644
> --- a/drivers/net/ethernet/sfc/ef100_nic.h
> +++ b/drivers/net/ethernet/sfc/ef100_nic.h
> @@ -69,6 +69,13 @@ enum ef100_bar_config {
> EF100_BAR_CONFIG_VDPA,
> };
>
> +#ifdef CONFIG_SFC_VDPA
> +enum ef100_vdpa_class {
> + EF100_VDPA_CLASS_NONE,
> + EF100_VDPA_CLASS_NET,
> +};
> +#endif
> +
I don't think there is any need to guard this with an #ifdef
> struct ef100_nic_data {
> struct efx_nic *efx;
> struct efx_buffer mcdi_buf;
> @@ -76,9 +83,11 @@ struct ef100_nic_data {
> u32 datapath_caps2;
> u32 datapath_caps3;
> unsigned int pf_index;
> + unsigned int vf_index;
> u16 warm_boot_count;
> #ifdef CONFIG_SFC_VDPA
> bool vdpa_supported; /* true if vdpa is supported on this PCIe FN */
> + enum ef100_vdpa_class vdpa_class;
> #endif
> u8 port_id[ETH_ALEN];
> DECLARE_BITMAP(evq_phases, EFX_MAX_CHANNELS);
...
> diff --git a/drivers/net/ethernet/sfc/ef100_vdpa.h b/drivers/net/ethernet/sfc/ef100_vdpa.h
...
> +static inline bool efx_vdpa_is_little_endian(struct ef100_vdpa_nic *vdpa_nic)
> +{
> + return virtio_legacy_is_little_endian() ||
> + (vdpa_nic->features & (1ULL << VIRTIO_F_VERSION_1));
> +}
Using BIT_ULL seems appropriate here.
...
> diff --git a/drivers/net/ethernet/sfc/net_driver.h b/drivers/net/ethernet/sfc/net_driver.h
> index 3dc9eae5a81d..1da71deac71c 100644
> --- a/drivers/net/ethernet/sfc/net_driver.h
> +++ b/drivers/net/ethernet/sfc/net_driver.h
> @@ -1090,6 +1090,12 @@ struct efx_nic {
> int rx_packet_len_offset;
> int rx_packet_ts_offset;
> bool rx_scatter;
> +#ifdef CONFIG_SFC_VDPA
> + /** @mgmt_dev: vDPA Management device */
> + struct vdpa_mgmt_dev *mgmt_dev;
> + /** @vdpa_nic: vDPA device structure (EF100) */
> + struct ef100_vdpa_nic *vdpa_nic;
> +#endif
I think the commends belong in the kdoc immediately above the structure
definition. Or is this the way it is done for conditionally present
fields (I don't know) ?
> struct efx_rss_context rss_context;
> struct mutex rss_lock;
> u32 vport_id;
> --
> 2.30.1
>
next prev parent reply other threads:[~2023-04-10 10:24 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-07 8:10 [PATCH net-next v4 00/14] sfc: add vDPA support for EF100 devices Gautam Dawar
2023-04-07 8:10 ` [PATCH net-next v4 01/14] sfc: add function personality " Gautam Dawar
2023-04-07 8:10 ` [PATCH net-next v4 02/14] sfc: implement MCDI interface for vDPA operations Gautam Dawar
2023-04-10 9:54 ` Simon Horman
2023-04-07 8:10 ` [PATCH net-next v4 03/14] sfc: update MCDI headers for CLIENT_CMD_VF_PROXY capability bit Gautam Dawar
2023-04-07 8:10 ` [PATCH net-next v4 04/14] sfc: evaluate vdpa support based on FW capability CLIENT_CMD_VF_PROXY Gautam Dawar
2023-04-07 8:10 ` [PATCH net-next v4 05/14] sfc: implement init and fini functions for vDPA personality Gautam Dawar
2023-04-07 8:10 ` [PATCH net-next v4 06/14] sfc: implement vDPA management device operations Gautam Dawar
2023-04-10 10:22 ` Simon Horman [this message]
2023-04-07 8:10 ` [PATCH net-next v4 07/14] sfc: implement vdpa device config operations Gautam Dawar
2023-04-07 8:10 ` [PATCH net-next v4 08/14] sfc: implement vdpa vring " Gautam Dawar
2023-04-10 12:48 ` Simon Horman
2023-04-07 8:10 ` [PATCH net-next v4 09/14] sfc: implement device status related vdpa " Gautam Dawar
2023-04-08 3:20 ` Jakub Kicinski
2023-04-10 6:23 ` Gautam Dawar
2023-04-10 12:47 ` Simon Horman
2023-04-07 8:10 ` [PATCH net-next v4 10/14] sfc: implement filters for receiving traffic Gautam Dawar
2023-04-08 3:21 ` Jakub Kicinski
2023-04-10 6:25 ` Gautam Dawar
2023-04-07 8:10 ` [PATCH net-next v4 11/14] sfc: use PF's IOMMU domain for running VF's MCDI commands Gautam Dawar
2023-04-07 8:10 ` [PATCH net-next v4 12/14] sfc: unmap VF's MCDI buffer when switching to vDPA mode Gautam Dawar
2023-04-07 8:10 ` [PATCH net-next v4 13/14] sfc: update vdpa device MAC address Gautam Dawar
2023-04-07 8:10 ` [PATCH net-next v4 14/14] sfc: register the vDPA device Gautam Dawar
2023-04-09 9:13 ` [PATCH net-next v4 00/14] sfc: add vDPA support for EF100 devices Leon Romanovsky
2023-04-10 1:39 ` Jason Wang
2023-04-10 6:33 ` Gautam Dawar
2023-04-10 7:53 ` Leon Romanovsky
2023-04-24 15:46 ` Martin Habets
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=ZDPjcpBQBPqmZKh1@corigine.com \
--to=simon.horman@corigine.com \
--cc=davem@davemloft.net \
--cc=ecree.xilinx@gmail.com \
--cc=edumazet@google.com \
--cc=eperezma@redhat.com \
--cc=gautam.dawar@amd.com \
--cc=habetsm.xilinx@gmail.com \
--cc=harpreet.anand@amd.com \
--cc=jasowang@redhat.com \
--cc=koushik.dutta@amd.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net-drivers@amd.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
--cc=tanuj.kamde@amd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.