[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <66d6dbc1-5829-4097-8b36-c8776c86bce6@intel.com>
Date: Wed, 16 Apr 2025 17:49:01 +0200
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: Larysa Zaremba <larysa.zaremba@...el.com>
CC: <intel-wired-lan@...ts.osuosl.org>, Tony Nguyen
<anthony.l.nguyen@...el.com>, "David S. Miller" <davem@...emloft.net>, "Eric
Dumazet" <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>, Simon Horman <horms@...nel.org>, Jonathan Corbet
<corbet@....net>, Przemek Kitszel <przemyslaw.kitszel@...el.com>, Jiri Pirko
<jiri@...nulli.us>, Mustafa Ismail <mustafa.ismail@...el.com>, "Tatyana
Nikolova" <tatyana.e.nikolova@...el.com>, Andrew Lunn
<andrew+netdev@...n.ch>, Michael Ellerman <mpe@...erman.id.au>, Maciej
Fijalkowski <maciej.fijalkowski@...el.com>, Lee Trager <lee@...ger.us>,
"Madhavan Srinivasan" <maddy@...ux.ibm.com>, Sridhar Samudrala
<sridhar.samudrala@...el.com>, Jacob Keller <jacob.e.keller@...el.com>,
Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>, Mateusz Polchlopek
<mateusz.polchlopek@...el.com>, Wenjun Wu <wenjun1.wu@...el.com>, Ahmed Zaki
<ahmed.zaki@...el.com>, <netdev@...r.kernel.org>,
<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>, "Karlsson,
Magnus" <magnus.karlsson@...el.com>, Emil Tantilov
<emil.s.tantilov@...el.com>, Madhu Chittim <madhu.chittim@...el.com>, "Josh
Hay" <joshua.a.hay@...el.com>, Milena Olech <milena.olech@...el.com>,
<pavan.kumar.linga@...el.com>, "Singhai, Anjali" <anjali.singhai@...el.com>
Subject: Re: [PATCH iwl-next 00/14] Introduce iXD driver
From: Larysa Zaremba <larysa.zaremba@...el.com>
Date: Tue, 8 Apr 2025 14:47:46 +0200
> This patch series adds the iXD driver, which supports the Intel(R)
> Control Plane PCI Function on Intel E2100 and later IPUs and FNICs.
> It facilitates a centralized control over multiple IDPF PFs/VFs/SFs
> exposed by the same card. The reason for the separation is to be able
> to offload the control plane to the host different from where the data
> plane is running.
BTW please move everything you're adding to libeth to libie instead.
This PCI/VC/CP functionality is unlikely to be used by other vendors.
Since libie_cp.ko or how you may want to call it won't link with base
libie.ko, it won't have any pre-idpf HW-specific symbols, so that idpf
could link with it.
libeth stuff is purely vendor-agnostic and I'd really like to keep it so.
Thanks,
Olek
Powered by blists - more mailing lists