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

Larysa Zaremba
2025-04-10T13:59:59Z

On Thu, Apr 10, 2025 at 04:44:43PM +0300, Leon Romanovsky wrote:
> On Thu, Apr 10, 2025 at 03:05:19PM +0200, Alexander Lobakin wrote:
> > From: Leon Romanovsky <leon@kernel.org>
> > 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@intel.com>
> > >>>>
> > >>>> 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.
>

While I do understand what kind of module relationship you consider problematic,
I still struggle to understand why stateless lib hierarchy can be problematic.
The fixes that you linked relate more to problematic resource sharing, of which
libeth has none, it does not have its own memory or its own threads, this is
just collection of data structures and functions.

> >
> > >
> > > 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.
>
> Thanks