netdev - Re: [PATCH 11/15] RDMA/hbl: add habanalabs RDMA driver

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2c767517-e24c-416b-9083-d3a220ffc14c@habana.ai>
Date: Sun, 14 Jul 2024 10:18:12 +0000
From: Omer Shpigelman <oshpigelman@...ana.ai>
To: Jason Gunthorpe <jgg@...pe.ca>
CC: Leon Romanovsky <leon@...nel.org>,
        "gregkh@...uxfoundation.org"
	<gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        "linux-rdma@...r.kernel.org"
	<linux-rdma@...r.kernel.org>,
        "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>,
        "ogabbay@...nel.org" <ogabbay@...nel.org>,
        Zvika Yehudai <zyehudai@...ana.ai>
Subject: Re: [PATCH 11/15] RDMA/hbl: add habanalabs RDMA driver

On 7/12/24 16:08, Jason Gunthorpe wrote:
> [You don't often get email from jgg@...pe.ca. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On Fri, Jun 28, 2024 at 10:24:32AM +0000, Omer Shpigelman wrote:
> 
>> We need the core driver to access the IB driver (and to the ETH driver as
>> well). As you wrote, we can't use exported symbols from our IB driver nor
>> rely on function pointers, but what about providing the core driver an ops
>> structure? meaning exporting a register function from the core driver that
>> should be called by the IB driver during auxiliary device probe.
>> Something like:
>>
>> int hbl_cn_register_ib_aux_dev(struct auxiliary_device *adev,
>>                              struct hbl_ib_ops *ops)
>> {
>> ...
>> }
>> EXPORT_SYMBOL(hbl_cn_register_ib_aux_dev);
> 
> Definately do not do some kind of double-register like this.
> 
> The auxiliary_device scheme can already be extended to provide ops for
> each sub device.
> 
> Like
> 
> struct habana_driver {
>    struct auxiliary_driver base;
>    const struct habana_ops *ops;
> };
> 
> If the ops are justified or not is a different question.
> 

Well, I suggested this double-register option because I got a comment that
the design pattern of embedded ops structure shouldn't be used.
So I'm confused now...

>> module reference counter. But we also get the ability to access the IB
>> driver from the core driver (to report a HW error for example).
> 
> Report a HW error seems reasonable to me
> 
> Other driver have used notifier chains for this kind of stuff though.
> 
> Jason

I'll look into the option of using notifier chains in this case, although
as I saw it, the notifier chains are more suitable for broadcast updates
where the updater is not necessarily aware of the identity nor the number
of the subscribers. It looks kind of overkill for our error reporting case
which is simpler.