netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Omer Shpigelman <oshpigelman@habana.ai>
To: Leon Romanovsky <leon@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"ogabbay@kernel.org" <ogabbay@kernel.org>,
	Zvika Yehudai <zyehudai@habana.ai>
Subject: Re: [PATCH 11/15] RDMA/hbl: add habanalabs RDMA driver
Date: Tue, 18 Jun 2024 11:08:34 +0000	[thread overview]
Message-ID: <461bf44e-fd2f-4c8b-bc41-48d48e5a7fcb@habana.ai> (raw)
In-Reply-To: <20240617190429.GB4025@unreal>

On 6/17/24 22:04, Leon Romanovsky wrote:
> [Some people who received this message don't often get email from leon@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On Mon, Jun 17, 2024 at 05:43:49PM +0000, Omer Shpigelman wrote:
>> On 6/13/24 22:18, Leon Romanovsky wrote:
>>> [Some people who received this message don't often get email from leon@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>>
>>> On Thu, Jun 13, 2024 at 11:22:04AM +0300, Omer Shpigelman wrote:
>>>> Add an RDMA driver of Gaudi ASICs family for AI scaling.
>>>> The driver itself is agnostic to the ASIC in action, it operates according
>>>> to the capabilities that were passed on device initialization.
>>>> The device is initialized by the hbl_cn driver via auxiliary bus.
>>>> The driver also supports QP resource tracking and port/device HW counters.
>>>>
>>>> Signed-off-by: Omer Shpigelman <oshpigelman@habana.ai>
>>>> Co-developed-by: Abhilash K V <kvabhilash@habana.ai>
>>>> Signed-off-by: Abhilash K V <kvabhilash@habana.ai>
>>>> Co-developed-by: Andrey Agranovich <aagranovich@habana.ai>
>>>> Signed-off-by: Andrey Agranovich <aagranovich@habana.ai>
>>>> Co-developed-by: Bharat Jauhari <bjauhari@habana.ai>
>>>> Signed-off-by: Bharat Jauhari <bjauhari@habana.ai>
>>>> Co-developed-by: David Meriin <dmeriin@habana.ai>
>>>> Signed-off-by: David Meriin <dmeriin@habana.ai>
>>>> Co-developed-by: Sagiv Ozeri <sozeri@habana.ai>
>>>> Signed-off-by: Sagiv Ozeri <sozeri@habana.ai>
>>>> Co-developed-by: Zvika Yehudai <zyehudai@habana.ai>
>>>> Signed-off-by: Zvika Yehudai <zyehudai@habana.ai>
>>>
>>> I afraid that you misinterpreted the "Co-developed-by" tag. All these
>>> people are probably touch the code and not actually sit together at
>>> the same room and write the code together. So, please remove the
>>> extensive "Co-developed-by" tags.
>>>
>>> It is not full review yet, but simple pass-by-comments.
>>>
>>
>> Actually except of two, all of the mentioned persons sat in the same room
>> and developed the code together.
>> The remaining two are located on a different site (but also together).
>> Isn't that what "Co-developed-by" tag for?
>> I wanted to give them credit for writing the code but I can remove if it's
>> not common.
> 
> Signed-off-by will be enough to give them credit.
> 

Ok, good enough.

>>
>>>> ---
>>>>  MAINTAINERS                              |   10 +
>>>>  drivers/infiniband/Kconfig               |    1 +
>>>>  drivers/infiniband/hw/Makefile           |    1 +
>>>>  drivers/infiniband/hw/hbl/Kconfig        |   17 +
>>>>  drivers/infiniband/hw/hbl/Makefile       |    8 +
>>>>  drivers/infiniband/hw/hbl/hbl.h          |  326 +++
>>>>  drivers/infiniband/hw/hbl/hbl_main.c     |  478 ++++
>>>>  drivers/infiniband/hw/hbl/hbl_verbs.c    | 2686 ++++++++++++++++++++++
>>>>  include/uapi/rdma/hbl-abi.h              |  204 ++
>>>>  include/uapi/rdma/hbl_user_ioctl_cmds.h  |   66 +
>>>>  include/uapi/rdma/hbl_user_ioctl_verbs.h |  106 +
>>>>  include/uapi/rdma/ib_user_ioctl_verbs.h  |    1 +
>>>>  12 files changed, 3904 insertions(+)
>>>>  create mode 100644 drivers/infiniband/hw/hbl/Kconfig
>>>>  create mode 100644 drivers/infiniband/hw/hbl/Makefile
>>>>  create mode 100644 drivers/infiniband/hw/hbl/hbl.h
>>>>  create mode 100644 drivers/infiniband/hw/hbl/hbl_main.c
>>>>  create mode 100644 drivers/infiniband/hw/hbl/hbl_verbs.c
>>>>  create mode 100644 include/uapi/rdma/hbl-abi.h
>>>>  create mode 100644 include/uapi/rdma/hbl_user_ioctl_cmds.h
>>>>  create mode 100644 include/uapi/rdma/hbl_user_ioctl_verbs.h
>>>
>>> <...>
>>>
>>>> +#define hbl_ibdev_emerg(ibdev, format, ...)  ibdev_emerg(ibdev, format, ##__VA_ARGS__)
>>>> +#define hbl_ibdev_alert(ibdev, format, ...)  ibdev_alert(ibdev, format, ##__VA_ARGS__)
>>>> +#define hbl_ibdev_crit(ibdev, format, ...)   ibdev_crit(ibdev, format, ##__VA_ARGS__)
>>>> +#define hbl_ibdev_err(ibdev, format, ...)    ibdev_err(ibdev, format, ##__VA_ARGS__)
>>>> +#define hbl_ibdev_warn(ibdev, format, ...)   ibdev_warn(ibdev, format, ##__VA_ARGS__)
>>>> +#define hbl_ibdev_notice(ibdev, format, ...) ibdev_notice(ibdev, format, ##__VA_ARGS__)
>>>> +#define hbl_ibdev_info(ibdev, format, ...)   ibdev_info(ibdev, format, ##__VA_ARGS__)
>>>> +#define hbl_ibdev_dbg(ibdev, format, ...)    ibdev_dbg(ibdev, format, ##__VA_ARGS__)
>>>> +
>>>> +#define hbl_ibdev_emerg_ratelimited(ibdev, fmt, ...)         \
>>>> +     ibdev_emerg_ratelimited(ibdev, fmt, ##__VA_ARGS__)
>>>> +#define hbl_ibdev_alert_ratelimited(ibdev, fmt, ...)         \
>>>> +     ibdev_alert_ratelimited(ibdev, fmt, ##__VA_ARGS__)
>>>> +#define hbl_ibdev_crit_ratelimited(ibdev, fmt, ...)          \
>>>> +     ibdev_crit_ratelimited(ibdev, fmt, ##__VA_ARGS__)
>>>> +#define hbl_ibdev_err_ratelimited(ibdev, fmt, ...)           \
>>>> +     ibdev_err_ratelimited(ibdev, fmt, ##__VA_ARGS__)
>>>> +#define hbl_ibdev_warn_ratelimited(ibdev, fmt, ...)          \
>>>> +     ibdev_warn_ratelimited(ibdev, fmt, ##__VA_ARGS__)
>>>> +#define hbl_ibdev_notice_ratelimited(ibdev, fmt, ...)                \
>>>> +     ibdev_notice_ratelimited(ibdev, fmt, ##__VA_ARGS__)
>>>> +#define hbl_ibdev_info_ratelimited(ibdev, fmt, ...)          \
>>>> +     ibdev_info_ratelimited(ibdev, fmt, ##__VA_ARGS__)
>>>> +#define hbl_ibdev_dbg_ratelimited(ibdev, fmt, ...)           \
>>>> +     ibdev_dbg_ratelimited(ibdev, fmt, ##__VA_ARGS__)
>>>> +
>>>
>>> Please don't redefine the existing macros. Just use the existing ones.
>>>
>>>
>>> <...>
>>>
>>
>> That's a leftover from some debug code. I'll remove.
>>
>>>> +     if (hbl_ib_match_netdev(ibdev, netdev))
>>>> +             ib_port = hbl_to_ib_port_num(hdev, netdev->dev_port);
>>>> +     else
>>>> +             return NOTIFY_DONE;
>>>
>>> It is not kernel coding style. Please write:
>>> if (!hbl_ib_match_netdev(ibdev, netdev))
>>>     return NOTIFY_DONE;
>>>
>>> ib_port = hbl_to_ib_port_num(hdev, netdev->dev_port);
>>>
>>
>> I'll fix the code, thanks.
>>
>>>> +
>>>
>>> <...>
>>>
>>>> +static int hbl_ib_probe(struct auxiliary_device *adev, const struct auxiliary_device_id *id)
>>>> +{
>>>> +     struct hbl_aux_dev *aux_dev = container_of(adev, struct hbl_aux_dev, adev);
>>>> +     struct hbl_ib_aux_ops *aux_ops = aux_dev->aux_ops;
>>>> +     struct hbl_ib_device *hdev;
>>>> +     ktime_t timeout;
>>>> +     int rc;
>>>> +
>>>> +     rc = hdev_init(aux_dev);
>>>> +     if (rc) {
>>>> +             dev_err(&aux_dev->adev.dev, "Failed to init hdev\n");
>>>> +             return -EIO;
>>>> +     }
>>>> +
>>>> +     hdev = aux_dev->priv;
>>>> +
>>>> +     /* don't allow module unloading while it is attached */
>>>> +     if (!try_module_get(THIS_MODULE)) {
>>>
>>> This part makes wonder, what are you trying to do here? What doesn't work for you
>>> in standard driver core and module load mechanism?
>>>
>>
>> Before auxiliary bus was introduced, we used EXPORT_SYMBOLs for inter
>> driver communication. That incremented the refcount of the used module so
>> it couldn't be removed while it is in use.
>> Auxiliary bus usage doesn't increment the used module refcount and hence
>> the used module can be removed while it is in use and that's something
>> we don't want to allow.
>> We could solve it by some global locking or in_use atomic but the most
>> simple and clean way is just to increment the used module refcount on
>> auxiliary device probe and decrement it on auxiliary device removal.
> 
> No, you was supposed to continue to use EXPORT_SYMBOLs and don't
> invent auxiliary ops structure (this is why you lost module
> reference counting).
> 

Sorry, but according to the auxiliary bus doc, a domain-specific ops
structure can be used.
We followed the usage example described at drivers/base/auxiliary.c.
What am I missing? 
Moreover, we'd like to support the mode where the IB or the ETH driver is
not loaded at all. But this cannot be achieved if we use EXPORT_SYMBOLs
exclusively for inter driver communication.

>>
>>>> +             dev_err(hdev->dev, "Failed to increment %s module refcount\n",
>>>> +                     module_name(THIS_MODULE));
>>>> +             rc = -EIO;
>>>> +             goto module_get_err;
>>>> +     }
>>>> +
>>>> +     timeout = ktime_add_ms(ktime_get(), hdev->pending_reset_long_timeout * MSEC_PER_SEC);
>>>> +     while (1) {
>>>> +             aux_ops->hw_access_lock(aux_dev);
>>>> +
>>>> +             /* if the device is operational, proceed to actual init while holding the lock in
>>>> +              * order to prevent concurrent hard reset
>>>> +              */
>>>> +             if (aux_ops->device_operational(aux_dev))
>>>> +                     break;
>>>> +
>>>> +             aux_ops->hw_access_unlock(aux_dev);
>>>> +
>>>> +             if (ktime_compare(ktime_get(), timeout) > 0) {
>>>> +                     dev_err(hdev->dev, "Timeout while waiting for hard reset to finish\n");
>>>> +                     rc = -EBUSY;
>>>> +                     goto timeout_err;
>>>> +             }
>>>> +
>>>> +             dev_notice_once(hdev->dev, "Waiting for hard reset to finish before probing IB\n");
>>>> +
>>>> +             msleep_interruptible(MSEC_PER_SEC);
>>>> +     }
>>>
>>> The code above is unexpected.
>>>
>>
>> We have no control on when the user insmod the IB driver.
> 
> It is not true, this is controlled through module dependencies
> mechanism.
> 

Yeah, if we would use EXPORT_SYMBOLs for inter driver communication but
we don't.

>> As a result it is possible that the IB auxiliary device will be probed
>> while the compute device is under reset (due to some HW error).
> 
> No, it is not possible. If you structure your driver right.
> 

Again, it is not possible if we would use EXPORT_SYMBOLs.
Please let me know if we misunderstood something because AFAIU we followed
the auxiliary bus doc usage example.

> Thanks

  reply	other threads:[~2024-06-18 11:09 UTC|newest]

Thread overview: 108+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-13  8:21 [PATCH 00/15] Introduce HabanaLabs network drivers Omer Shpigelman
2024-06-13  8:21 ` [PATCH 01/15] net: hbl_cn: add habanalabs Core Network driver Omer Shpigelman
2024-06-13 13:01   ` Przemek Kitszel
2024-06-13 14:16     ` Przemek Kitszel
2024-06-17  8:08     ` Omer Shpigelman
2024-06-17 11:48       ` Leon Romanovsky
2024-06-18  7:28         ` Omer Shpigelman
2024-06-15  0:05   ` Stephen Hemminger
2024-06-17  8:14     ` Omer Shpigelman
2024-06-17 14:05   ` Markus Elfring
2024-06-17 15:02     ` Andrew Lunn
2024-06-18  7:51       ` Omer Shpigelman
2024-06-13  8:21 ` [PATCH 02/15] net: hbl_cn: memory manager component Omer Shpigelman
2024-06-13  8:21 ` [PATCH 03/15] net: hbl_cn: physical layer support Omer Shpigelman
2024-06-13  8:21 ` [PATCH 04/15] net: hbl_cn: QP state machine Omer Shpigelman
2024-06-17 13:18   ` Leon Romanovsky
2024-06-18  5:50     ` Omer Shpigelman
2024-06-18  7:08       ` Leon Romanovsky
2024-06-18  7:58         ` Omer Shpigelman
2024-06-18  9:00           ` Leon Romanovsky
2024-06-24  7:24             ` Omer Shpigelman
2024-06-13  8:21 ` [PATCH 05/15] net: hbl_cn: memory trace events Omer Shpigelman
2024-06-13  8:21 ` [PATCH 06/15] net: hbl_cn: debugfs support Omer Shpigelman
2024-06-19 18:35   ` Sunil Kovvuri Goutham
2024-06-21 10:17     ` Omer Shpigelman
2024-06-21 10:30       ` Sunil Kovvuri Goutham
2024-06-23  7:25         ` Omer Shpigelman
2024-06-21 15:33       ` Andrew Lunn
2024-06-23  6:57         ` Omer Shpigelman
2024-06-23 15:02           ` Andrew Lunn
2024-06-24  7:21             ` Omer Shpigelman
2024-06-24  9:22             ` Leon Romanovsky
2024-12-17 10:00             ` Avri Kehat
2024-12-17 10:52               ` Andrew Lunn
2024-06-13  8:22 ` [PATCH 07/15] net: hbl_cn: gaudi2: ASIC register header files Omer Shpigelman
2024-06-13  8:22 ` [PATCH 08/15] net: hbl_cn: gaudi2: ASIC specific support Omer Shpigelman
2024-06-13  8:22 ` [PATCH 09/15] net: hbl_en: add habanalabs Ethernet driver Omer Shpigelman
2024-06-13 21:49   ` Andrew Lunn
2024-06-18  6:58     ` Omer Shpigelman
2024-06-18 14:19       ` Andrew Lunn
2024-06-19  7:16         ` Omer Shpigelman
2024-06-19  8:01           ` Przemek Kitszel
2024-06-19 12:15             ` Omer Shpigelman
2024-06-19 15:21           ` Jakub Kicinski
2024-06-20  8:43             ` Omer Shpigelman
2024-06-20 13:51               ` Jakub Kicinski
2024-06-20 19:14                 ` Andrew Lunn
2024-06-23 14:48                   ` Omer Shpigelman
2024-06-19 16:13           ` Andrew Lunn
2024-06-23  6:22             ` Omer Shpigelman
2024-06-23 14:46               ` Andrew Lunn
2024-06-26 10:13                 ` Omer Shpigelman
2024-06-26 14:13                   ` Andrew Lunn
2024-06-30  7:11                     ` Omer Shpigelman
2024-06-14 22:48   ` Joe Damato
2024-06-16  1:04     ` Andrew Lunn
2024-06-18 19:37     ` Omer Shpigelman
2024-06-18 21:19       ` Stephen Hemminger
2024-06-19 12:13         ` Omer Shpigelman
2024-06-15  0:10   ` Stephen Hemminger
2024-06-19 12:07     ` Omer Shpigelman
2024-06-15  0:16   ` Stephen Hemminger
2024-06-18 19:39     ` Omer Shpigelman
2024-06-19 15:40       ` Andrew Lunn
2024-06-20  8:36         ` Omer Shpigelman
2024-06-15 10:55   ` Zhu Yanjun
2024-06-18 11:16     ` Omer Shpigelman
2024-06-15 17:13   ` Zhu Yanjun
2024-06-16  1:08     ` Andrew Lunn
2024-06-13  8:22 ` [PATCH 10/15] net: hbl_en: gaudi2: ASIC specific support Omer Shpigelman
2024-06-13  8:22 ` [PATCH 11/15] RDMA/hbl: add habanalabs RDMA driver Omer Shpigelman
2024-06-13 19:18   ` Leon Romanovsky
2024-06-17 17:43     ` Omer Shpigelman
2024-06-17 19:04       ` Leon Romanovsky
2024-06-18 11:08         ` Omer Shpigelman [this message]
2024-06-18 12:58           ` Leon Romanovsky
2024-06-19  9:27             ` Omer Shpigelman
2024-06-19 10:52               ` Leon Romanovsky
2024-06-24  8:47                 ` Omer Shpigelman
2024-06-24  9:10                   ` Leon Romanovsky
2024-06-28 10:24                 ` Omer Shpigelman
2024-06-30 13:29                   ` Leon Romanovsky
2024-07-01 10:46                     ` Omer Shpigelman
2024-07-01 12:46                       ` Leon Romanovsky
2024-07-12 13:08                   ` Jason Gunthorpe
2024-07-14 10:18                     ` Omer Shpigelman
2024-07-16 13:40                       ` Jason Gunthorpe
2024-07-17  7:08                         ` Omer Shpigelman
2024-07-17  7:36                           ` Leon Romanovsky
2024-07-17 10:51                             ` Omer Shpigelman
2024-07-17 11:56                               ` Jason Gunthorpe
2024-07-17 12:33                               ` Leon Romanovsky
2024-07-18  6:54                                 ` Omer Shpigelman
2024-07-18  8:31                                   ` Leon Romanovsky
2024-06-18 16:01           ` Przemek Kitszel
2024-06-19  9:34             ` Omer Shpigelman
2024-06-17 14:17   ` Jason Gunthorpe
2024-06-19  9:39     ` Omer Shpigelman
2024-06-13  8:22 ` [PATCH 12/15] RDMA/hbl: direct verbs support Omer Shpigelman
2024-06-13  8:22 ` [PATCH 13/15] accel/habanalabs: network scaling support Omer Shpigelman
2024-06-19 18:41   ` Sunil Kovvuri Goutham
2024-06-21 10:21     ` Omer Shpigelman
2024-06-13  8:22 ` [PATCH 14/15] accel/habanalabs/gaudi2: CN registers header files Omer Shpigelman
2024-06-13  8:22 ` [PATCH 15/15] accel/habanalabs/gaudi2: network scaling support Omer Shpigelman
2024-06-17 12:34 ` [PATCH 00/15] Introduce HabanaLabs network drivers Alexander Lobakin
2024-06-19 11:40   ` Omer Shpigelman
2024-06-19 16:33 ` Jiri Pirko
2024-06-20  5:37   ` Omer Shpigelman

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=461bf44e-fd2f-4c8b-bc41-48d48e5a7fcb@habana.ai \
    --to=oshpigelman@habana.ai \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=ogabbay@kernel.org \
    --cc=zyehudai@habana.ai \
    /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).