Re: [PATCH RFC v4 net-next 11/13] pds_core: add the aux client API

On 3/15/23 1:21 AM, Leon Romanovsky wrote:

On Tue, Mar 14, 2023 at 09:53:25AM -0700, Shannon Nelson wrote:

quoted

On 3/14/23 5:14 AM, Leon Romanovsky wrote:

quoted

On Tue, Mar 07, 2023 at 09:13:08PM -0800, Shannon Nelson wrote:

quoted

Add the client API operations for registering, unregistering,
and running adminq commands.  We expect to add additional
operations for other clients, including requesting additional
private adminqs and IRQs, but don't have the need yet,

Signed-off-by: Shannon Nelson <redacted>
---
   drivers/net/ethernet/amd/pds_core/auxbus.c | 134 ++++++++++++++++++++-
   include/linux/pds/pds_auxbus.h             |  42 +++++++
   2 files changed, 174 insertions(+), 2 deletions(-)

<...>

quoted

+static struct pds_core_ops pds_core_ops = {
+     .register_client = pds_client_register,
+     .unregister_client = pds_client_unregister,
+     .adminq_cmd = pds_client_adminq_cmd,
+};

<...>

quoted

+/*
+ *   ptrs to functions to be used by the client for core services
+ */
+struct pds_core_ops {
+     /* .register() - register the client with the device
+      * padev:  ptr to the client device info
+      * Register the client with the core and with the DSC.  The core
+      * will fill in the client padrv->client_id for use in calls
+      * to the DSC AdminQ
+      */
+     int (*register_client)(struct pds_auxiliary_dev *padev);
+
+     /* .unregister() - disconnect the client from the device
+      * padev:  ptr to the client device info
+      * Disconnect the client from the core and with the DSC.
+      */
+     int (*unregister_client)(struct pds_auxiliary_dev *padev);
+
+     /* .adminq_cmd() - process an adminq request for the client
+      * padev:  ptr to the client device
+      * req:     ptr to buffer with request
+      * req_len: length of actual struct used for request
+      * resp:    ptr to buffer where answer is to be copied
+      * flags:   optional flags defined by enum pds_core_adminq_flags
+      *          and used for more flexible adminq behvior
+      *
+      * returns 0 on success, or
+      *         negative for error
+      * Client sends pointers to request and response buffers
+      * Core copies request data into pds_core_client_request_cmd
+      * Core sets other fields as needed
+      * Core posts to AdminQ
+      * Core copies completion data into response buffer
+      */
+     int (*adminq_cmd)(struct pds_auxiliary_dev *padev,
+                       union pds_core_adminq_cmd *req,
+                       size_t req_len,
+                       union pds_core_adminq_comp *resp,
+                       u64 flags);
+};

I don't expect to see any register/unregister AUX client code at all.

All clients are registered and unregistered through
auxiliary_driver_register()/auxiliary_driver_unregister() calls and
perform as standalone drivers.

Maybe client, register and unregister words means something else in this
series..

Yeah, I'm not thrilled with the overlap in nomenclature either.  In this
case we're talking about the logic in the pds_vdpa module connecting to the
services needed in the device FW, and getting a client_id from the FW that
is used for tracking client context in the FW.  Maybe these names can change
to something like "fw_client_reg" and "fw_client_unreg" - would that make it
more clear?

I feel that such ops are not needed at all. Once you create aux devices
(vdpa, eth, e.t.c), you would be able to connect only one driver with one
such device. It means context is already known at that point. In addition,
user controls if he/she wants aux specific devices by relevant devlink *_enable
knob.

Thanks

As this code matures here, as well as the internal gyrations happening, 
this makes more and more sense.  Some of the original work was there for 
greater flexibility in what we might need "soon", but much has gone 
away.  This is one of those things that we can whittle down.  The 
registration is still needed to tell the FW about the client, but can be 
moved out of the clients' responsibility and into the VF startup.

Thanks,
sln