From: Leon Romanovsky <leon@kernel.org>
To: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
Cc: jgg@nvidia.com, intel-wired-lan@lists.osuosl.org,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
david.m.ertman@intel.com
Subject: Re: [Intel-wired-lan] [iwl-next v4 1/1] iidc/ice/irdma: Update IDC to support multiple consumers
Date: Tue, 25 Feb 2025 09:55:30 +0200 [thread overview]
Message-ID: <20250225075530.GD53094@unreal> (raw)
In-Reply-To: <20250225050428.2166-2-tatyana.e.nikolova@intel.com>
On Mon, Feb 24, 2025 at 11:04:28PM -0600, Tatyana Nikolova wrote:
> From: Dave Ertman <david.m.ertman@intel.com>
>
> To support RDMA for E2000 product, the idpf driver will use the IDC
> interface with the irdma auxiliary driver, thus becoming a second
> consumer of it. This requires the IDC be updated to support multiple
> consumers. The use of exported symbols no longer makes sense because it
> will require all core drivers (ice/idpf) that can interface with irdma
> auxiliary driver to be loaded even if hardware is not present for those
> drivers.
In auxiliary bus world, the code drivers (ice/idpf) need to created
auxiliary devices only if specific device present. That auxiliary device
will trigger the load of specific module (irdma in our case).
EXPORT_SYMBOL won't trigger load of irdma driver, but the opposite is
true, load of irdma will trigger load of ice/idpf drivers (depends on
their exported symbol).
>
> To address this, implement an ops struct that will be universal set of
> naked function pointers that will be populated by each core driver for
> the irdma auxiliary driver to call.
No, we worked very hard to make proper HW discovery and driver autoload,
let's not return back. For now, it is no-go.
<...>
> +/* Following APIs are implemented by core PCI driver */
> +struct idc_rdma_core_ops {
> + int (*vc_send_sync)(struct idc_rdma_core_dev_info *cdev_info, u8 *msg,
> + u16 len, u8 *recv_msg, u16 *recv_len);
> + int (*vc_queue_vec_map_unmap)(struct idc_rdma_core_dev_info *cdev_info,
> + struct idc_rdma_qvlist_info *qvl_info,
> + bool map);
> + /* vport_dev_ctrl is for RDMA CORE driver to indicate it is either ready
> + * for individual vport aux devices, or it is leaving the state where it
> + * can support vports and they need to be downed
> + */
> + int (*vport_dev_ctrl)(struct idc_rdma_core_dev_info *cdev_info,
> + bool up);
> + int (*request_reset)(struct idc_rdma_core_dev_info *cdev_info,
> + enum idc_rdma_reset_type reset_type);
> +};
Core driver can call to callbacks in irdma, like you already have for
irdma_iidc_event_handler(), but all calls from irdma to core driver must
be through exported symbols. It gives us race-free world in whole driver
except one very specific place (irdma_iidc_event_handler).
Thanks
WARNING: multiple messages have this Message-ID (diff)
From: Leon Romanovsky <leon@kernel.org>
To: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
Cc: jgg@nvidia.com, intel-wired-lan@lists.osuosl.org,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
david.m.ertman@intel.com
Subject: Re: [iwl-next v4 1/1] iidc/ice/irdma: Update IDC to support multiple consumers
Date: Tue, 25 Feb 2025 09:55:30 +0200 [thread overview]
Message-ID: <20250225075530.GD53094@unreal> (raw)
In-Reply-To: <20250225050428.2166-2-tatyana.e.nikolova@intel.com>
On Mon, Feb 24, 2025 at 11:04:28PM -0600, Tatyana Nikolova wrote:
> From: Dave Ertman <david.m.ertman@intel.com>
>
> To support RDMA for E2000 product, the idpf driver will use the IDC
> interface with the irdma auxiliary driver, thus becoming a second
> consumer of it. This requires the IDC be updated to support multiple
> consumers. The use of exported symbols no longer makes sense because it
> will require all core drivers (ice/idpf) that can interface with irdma
> auxiliary driver to be loaded even if hardware is not present for those
> drivers.
In auxiliary bus world, the code drivers (ice/idpf) need to created
auxiliary devices only if specific device present. That auxiliary device
will trigger the load of specific module (irdma in our case).
EXPORT_SYMBOL won't trigger load of irdma driver, but the opposite is
true, load of irdma will trigger load of ice/idpf drivers (depends on
their exported symbol).
>
> To address this, implement an ops struct that will be universal set of
> naked function pointers that will be populated by each core driver for
> the irdma auxiliary driver to call.
No, we worked very hard to make proper HW discovery and driver autoload,
let's not return back. For now, it is no-go.
<...>
> +/* Following APIs are implemented by core PCI driver */
> +struct idc_rdma_core_ops {
> + int (*vc_send_sync)(struct idc_rdma_core_dev_info *cdev_info, u8 *msg,
> + u16 len, u8 *recv_msg, u16 *recv_len);
> + int (*vc_queue_vec_map_unmap)(struct idc_rdma_core_dev_info *cdev_info,
> + struct idc_rdma_qvlist_info *qvl_info,
> + bool map);
> + /* vport_dev_ctrl is for RDMA CORE driver to indicate it is either ready
> + * for individual vport aux devices, or it is leaving the state where it
> + * can support vports and they need to be downed
> + */
> + int (*vport_dev_ctrl)(struct idc_rdma_core_dev_info *cdev_info,
> + bool up);
> + int (*request_reset)(struct idc_rdma_core_dev_info *cdev_info,
> + enum idc_rdma_reset_type reset_type);
> +};
Core driver can call to callbacks in irdma, like you already have for
irdma_iidc_event_handler(), but all calls from irdma to core driver must
be through exported symbols. It gives us race-free world in whole driver
except one very specific place (irdma_iidc_event_handler).
Thanks
next prev parent reply other threads:[~2025-02-25 7:55 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-25 5:04 [Intel-wired-lan] [iwl-next v4 0/1] Add RDMA support for Intel IPU E2000 (GEN3) Tatyana Nikolova
2025-02-25 5:04 ` Tatyana Nikolova
2025-02-25 5:04 ` [Intel-wired-lan] [iwl-next v4 1/1] iidc/ice/irdma: Update IDC to support multiple consumers Tatyana Nikolova
2025-02-25 5:04 ` Tatyana Nikolova
2025-02-25 7:55 ` Leon Romanovsky [this message]
2025-02-25 7:55 ` Leon Romanovsky
2025-02-26 17:36 ` [Intel-wired-lan] " Ertman, David M
2025-02-26 17:36 ` Ertman, David M
2025-02-26 18:50 ` [Intel-wired-lan] " Leon Romanovsky
2025-02-26 18:50 ` Leon Romanovsky
2025-02-26 23:01 ` [Intel-wired-lan] " Ertman, David M
2025-02-26 23:01 ` Ertman, David M
2025-03-02 8:26 ` [Intel-wired-lan] " Leon Romanovsky
2025-03-02 8:26 ` Leon Romanovsky
2025-03-13 23:38 ` [Intel-wired-lan] " Samudrala, Sridhar
2025-03-14 18:12 ` Leon Romanovsky
2025-03-15 1:18 ` Samudrala, Sridhar
2025-03-17 11:57 ` Leon Romanovsky
2025-03-18 17:01 ` Samudrala, Sridhar
2025-03-18 17:20 ` Jason Gunthorpe
2025-03-18 19:45 ` Samudrala, Sridhar
2025-03-19 8:04 ` Leon Romanovsky
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=20250225075530.GD53094@unreal \
--to=leon@kernel.org \
--cc=david.m.ertman@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jgg@nvidia.com \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=tatyana.e.nikolova@intel.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.