All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>,
	Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
	Jesper Dangaard Brouer <hawk@kernel.org>,
	Larysa Zaremba <larysa.zaremba@intel.com>,
	netdev@vger.kernel.org, Alexander Duyck <alexanderduyck@fb.com>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Yunsheng Lin <linyunsheng@huawei.com>,
	linux-kernel@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
	Michal Kubiak <michal.kubiak@intel.com>,
	intel-wired-lan@lists.osuosl.org,
	David Christensen <drc@linux.vnet.ibm.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Intel-wired-lan] [PATCH net-next v5 00/14] net: intel: start The Great Code Dedup + Page Pool for iavf
Date: Mon, 27 Nov 2023 10:04:58 +0100	[thread overview]
Message-ID: <ZWRbusSZ4v0SuWmF@nanopsycho> (raw)
In-Reply-To: <20231124154732.1623518-1-aleksander.lobakin@intel.com>

Fri, Nov 24, 2023 at 04:47:18PM CET, aleksander.lobakin@intel.com wrote:
>Here's a two-shot: introduce Intel Ethernet common library (libie) and
>switch iavf to Page Pool. Details are in the commit messages; here's
>a summary:
>
>Not a secret there's a ton of code duplication between two and more Intel
>ethernet modules. Before introducing new changes, which would need to be
>copied over again, start decoupling the already existing duplicate
>functionality into a new module, which will be shared between several
>Intel Ethernet drivers. The first name that came to my mind was
>"libie" -- "Intel Ethernet common library". Also this sounds like
>"lovelie" (-> one word, no "lib I E" pls) and can be expanded as
>"lib Internet Explorer" :P
>The series is only the beginning. From now on, adding every new feature
>or doing any good driver refactoring will remove much more lines than add
>for quite some time. There's a basic roadmap with some deduplications
>planned already, not speaking of that touching every line now asks:
>"can I share this?". The final destination is very ambitious: have only
>one unified driver for at least i40e, ice, iavf, and idpf with a struct
>ops for each generation. That's never gonna happen, right? But you still
>can at least try.
>PP conversion for iavf lands within the same series as these two are tied
>closely. libie will support Page Pool model only, so that a driver can't
>use much of the lib until it's converted. iavf is only the example, the
>rest will eventually be converted soon on a per-driver basis. That is
>when it gets really interesting. Stay tech.

The world would not be the same without intel driver duplicates :/

Out of curiosity, what changed? I always thought this is
done for sake of easier out of tree driver development and old device
support dropping.
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

WARNING: multiple messages have this Message-ID (diff)
From: Jiri Pirko <jiri@resnulli.us>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
	Michal Kubiak <michal.kubiak@intel.com>,
	Larysa Zaremba <larysa.zaremba@intel.com>,
	Alexander Duyck <alexanderduyck@fb.com>,
	Yunsheng Lin <linyunsheng@huawei.com>,
	David Christensen <drc@linux.vnet.ibm.com>,
	Jesper Dangaard Brouer <hawk@kernel.org>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Paul Menzel <pmenzel@molgen.mpg.de>,
	netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v5 00/14] net: intel: start The Great Code Dedup + Page Pool for iavf
Date: Mon, 27 Nov 2023 10:04:58 +0100	[thread overview]
Message-ID: <ZWRbusSZ4v0SuWmF@nanopsycho> (raw)
In-Reply-To: <20231124154732.1623518-1-aleksander.lobakin@intel.com>

Fri, Nov 24, 2023 at 04:47:18PM CET, aleksander.lobakin@intel.com wrote:
>Here's a two-shot: introduce Intel Ethernet common library (libie) and
>switch iavf to Page Pool. Details are in the commit messages; here's
>a summary:
>
>Not a secret there's a ton of code duplication between two and more Intel
>ethernet modules. Before introducing new changes, which would need to be
>copied over again, start decoupling the already existing duplicate
>functionality into a new module, which will be shared between several
>Intel Ethernet drivers. The first name that came to my mind was
>"libie" -- "Intel Ethernet common library". Also this sounds like
>"lovelie" (-> one word, no "lib I E" pls) and can be expanded as
>"lib Internet Explorer" :P
>The series is only the beginning. From now on, adding every new feature
>or doing any good driver refactoring will remove much more lines than add
>for quite some time. There's a basic roadmap with some deduplications
>planned already, not speaking of that touching every line now asks:
>"can I share this?". The final destination is very ambitious: have only
>one unified driver for at least i40e, ice, iavf, and idpf with a struct
>ops for each generation. That's never gonna happen, right? But you still
>can at least try.
>PP conversion for iavf lands within the same series as these two are tied
>closely. libie will support Page Pool model only, so that a driver can't
>use much of the lib until it's converted. iavf is only the example, the
>rest will eventually be converted soon on a per-driver basis. That is
>when it gets really interesting. Stay tech.

The world would not be the same without intel driver duplicates :/

Out of curiosity, what changed? I always thought this is
done for sake of easier out of tree driver development and old device
support dropping.

  parent reply	other threads:[~2023-11-27  9:05 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-24 15:47 [Intel-wired-lan] [PATCH net-next v5 00/14] net: intel: start The Great Code Dedup + Page Pool for iavf Alexander Lobakin
2023-11-24 15:47 ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 01/14] page_pool: make sure frag API fields don't span between cachelines Alexander Lobakin
2023-11-24 15:47   ` Alexander Lobakin
2023-11-25 12:29   ` [Intel-wired-lan] " Yunsheng Lin
2023-11-25 12:29     ` Yunsheng Lin
2023-11-27 14:08     ` [Intel-wired-lan] " Alexander Lobakin
2023-11-27 14:08       ` Alexander Lobakin
2023-11-29  2:55       ` [Intel-wired-lan] " Yunsheng Lin
2023-11-29  2:55         ` Yunsheng Lin
2023-11-29 13:12         ` [Intel-wired-lan] " Alexander Lobakin
2023-11-29 13:12           ` Alexander Lobakin
2023-11-26 22:54   ` [Intel-wired-lan] " Jakub Kicinski
2023-11-26 22:54     ` Jakub Kicinski
2023-11-27 14:12     ` [Intel-wired-lan] " Alexander Lobakin
2023-11-27 14:12       ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 02/14] page_pool: don't use driver-set flags field directly Alexander Lobakin
2023-11-24 15:47   ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 03/14] page_pool: avoid calling no-op externals when possible Alexander Lobakin
2023-11-24 15:47   ` Alexander Lobakin
2023-11-25 13:04   ` [Intel-wired-lan] " Yunsheng Lin
2023-11-25 13:04     ` Yunsheng Lin
2023-11-27 14:32     ` [Intel-wired-lan] " Alexander Lobakin
2023-11-27 14:32       ` Alexander Lobakin
2023-11-27 18:17       ` [Intel-wired-lan] " Jakub Kicinski
2023-11-27 18:17         ` Jakub Kicinski
2023-11-28 16:50         ` [Intel-wired-lan] " Alexander Lobakin
2023-11-28 16:50           ` Alexander Lobakin
2023-11-29  3:17       ` [Intel-wired-lan] " Yunsheng Lin
2023-11-29  3:17         ` Yunsheng Lin
2023-11-29 13:17         ` [Intel-wired-lan] " Alexander Lobakin
2023-11-29 13:17           ` Alexander Lobakin
2023-11-30  8:46           ` Yunsheng Lin
2023-11-30  8:46             ` Yunsheng Lin
2023-11-30 11:58             ` Alexander Lobakin
2023-11-30 11:58               ` Alexander Lobakin
2023-11-30 12:20               ` Yunsheng Lin
2023-11-30 12:20                 ` Yunsheng Lin
2023-12-01 14:37                 ` Alexander Lobakin
2023-12-01 14:37                   ` Alexander Lobakin
2023-12-12 15:25                 ` Christoph Hellwig
2023-12-12 15:25                   ` Christoph Hellwig
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 04/14] net: intel: introduce Intel Ethernet common library Alexander Lobakin
2023-11-24 15:47   ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 05/14] iavf: kill "legacy-rx" for good Alexander Lobakin
2023-11-24 15:47   ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 06/14] iavf: drop page splitting and recycling Alexander Lobakin
2023-11-24 15:47   ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 07/14] page_pool: constify some read-only function arguments Alexander Lobakin
2023-11-24 15:47   ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 08/14] page_pool: add DMA-sync-for-CPU inline helpers Alexander Lobakin
2023-11-24 15:47   ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 09/14] libie: add Rx buffer management (via Page Pool) Alexander Lobakin
2023-11-24 15:47   ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 10/14] iavf: pack iavf_ring more efficiently Alexander Lobakin
2023-11-24 15:47   ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 11/14] iavf: switch to Page Pool Alexander Lobakin
2023-11-24 15:47   ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 12/14] libie: add common queue stats Alexander Lobakin
2023-11-24 15:47   ` Alexander Lobakin
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 13/14] libie: add per-queue Page Pool stats Alexander Lobakin
2023-11-24 15:47   ` Alexander Lobakin
2023-11-29 13:40   ` [Intel-wired-lan] " Alexander Lobakin
2023-11-29 13:40     ` Alexander Lobakin
2023-11-29 14:29     ` [Intel-wired-lan] " Jakub Kicinski
2023-11-29 14:29       ` Jakub Kicinski
2023-11-30 16:01       ` [Intel-wired-lan] " Alexander Lobakin
2023-11-30 16:01         ` Alexander Lobakin
2023-11-30 16:45         ` [Intel-wired-lan] " Alexander Lobakin
2023-11-30 16:45           ` Alexander Lobakin
2023-12-01  6:55           ` [Intel-wired-lan] " Jakub Kicinski
2023-12-01  6:55             ` Jakub Kicinski
2023-11-24 15:47 ` [Intel-wired-lan] [PATCH net-next v5 14/14] iavf: switch queue stats to libie Alexander Lobakin
2023-11-24 15:47   ` Alexander Lobakin
2023-11-27  9:04 ` Jiri Pirko [this message]
2023-11-27  9:04   ` [PATCH net-next v5 00/14] net: intel: start The Great Code Dedup + Page Pool for iavf Jiri Pirko
2023-11-27 10:23   ` [Intel-wired-lan] " Przemek Kitszel
2023-11-27 10:23     ` Przemek Kitszel

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=ZWRbusSZ4v0SuWmF@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=aleksander.lobakin@intel.com \
    --cc=alexanderduyck@fb.com \
    --cc=davem@davemloft.net \
    --cc=drc@linux.vnet.ibm.com \
    --cc=edumazet@google.com \
    --cc=hawk@kernel.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=kuba@kernel.org \
    --cc=larysa.zaremba@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linyunsheng@huawei.com \
    --cc=maciej.fijalkowski@intel.com \
    --cc=michal.kubiak@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pmenzel@molgen.mpg.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.