Re: [Intel-wired-lan] [PATCH iwl-next 05/14] libeth: add control queue support

[Alexander Lobakin]

From: Leon Romanovsky <leon@xxxxxxxxxx>
Date: Thu, 10 Apr 2025 16:44:43 +0300

> On Thu, Apr 10, 2025 at 03:05:19PM +0200, Alexander Lobakin wrote:
>> From: Leon Romanovsky <leon@xxxxxxxxxx>
>> Date: Thu, 10 Apr 2025 14:23:49 +0300
>>
>>> On Thu, Apr 10, 2025 at 12:44:33PM +0200, Larysa Zaremba wrote:
>>>> On Thu, Apr 10, 2025 at 11:21:37AM +0300, Leon Romanovsky wrote:
>>>>> On Tue, Apr 08, 2025 at 02:47:51PM +0200, Larysa Zaremba wrote:
>>>>>> From: Phani R Burra <phani.r.burra@xxxxxxxxx>
>>>>>>
>>>>>> Libeth will now support control queue setup and configuration APIs.
>>>>>> These are mainly used for mailbox communication between drivers and
>>>>>> control plane.
>>>>>>
>>>>>> Make use of the page pool support for managing controlq buffers.
> 
> <...>
> 
>>>> Module dependencies are as follows:
>>>>
>>>> libeth_rx and libeth_pci do not depend on other modules.
>>>> libeth_cp depends on both libeth_rx and libeth_pci.
>>>> idpf directly uses libeth_pci, libeth_rx and libeth_cp.
>>>> ixd directly uses libeth_cp and libeth_pci.
>>>
>>> You can do whatever module architecture for netdev devices, but if you
>>> plan to expose it to RDMA devices, I will vote against any deep layered
>>> module architecture for the drivers.
>>
>> No plans for RDMA there.
>>
>> Maybe link the whole kernel to one vmlinux then?
> 
> It seems that you didn't understand at all about what we are talking
> here. Please use the opportunity that you are working for the same
> company with Larysa and ask her offline. She understood perfectly about
> which modules we are talking.

She described to you how this looks like currently. No Larysa didn't
understand how scenarios like you described are possible.

> 
>>
>>>
>>> BTW, please add some Intel prefix to the modules names, they shouldn't
>>> be called in generic names like libeth, e.t.c
>>
>> Two modules with the same name can't exist within the kernel. libeth was
>> available and I haven't seen anyone wanting to take it. It's not common
>> at all to name a module starting with "lib".
> 
> Again, please talk with Larysa. ETH part is problematic in libeth name
> and not LIB.

Do you think we don't talk internally? I wouldn't write all this if
Larysa agreed with you or understood clearly what the problem is.

Don't make her responsible for your own words.
I've still noticed zero proofs for both topics.

As for libeth_, there are no generic code which would use this exact
prefix. Not "lib", not "eth", but whole "libeth".
There are no clear rules how to name or not name the modules. If it's
free and the subsys maintainers are fine, it's fine.

Thanks,
Olek