> From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Wednesday, 27 August 2025 17.12 > > 27/08/2025 17:08, Morten Brørup: > > > From: Burakov, Anatoly [mailto:anatoly.bura...@intel.com] > > > Sent: Wednesday, 27 August 2025 16.14 > > > > > > On 8/20/2025 8:42 AM, Morten Brørup wrote: > > > >> From: Stephen Hemminger [mailto:step...@networkplumber.org] > > > >> Sent: Monday, 18 August 2025 18.34 > > > >> > > > >> On Wed, 12 Mar 2025 16:15:29 -0700 > > > >> Stephen Hemminger <step...@networkplumber.org> wrote: > > > >> > > > >>> This series adds common macros for safe iteration over lists. > > > >>> It is a subset copy of the macros from FreeBSD that are > > > >>> missing from the Linux header sys/queue.h > > > >>> > > > >>> Chose this over several other options: > > > >>> - let each driver define their own as needed. > > > >>> One Intel driver got it wrong, others will as well. > > > >>> - rename all the queue macros to RTE_XXX variants. > > > >>> Seems like useless renaming and confusion. > > > >>> - Several distros have libbsd package with the correct macros. > > > >>> But adding yet another dependency to DPDK would be annoying > > > >>> for something this basic. > > > >>> > > > >>> There are more macros in FreeBSD header that could be useful, > > > >>> but we can add those later as needed here. > > > >>> > > > >>> lib/eal/include/rte_queue.h | 174 > +++++++++++++++++++++++ > > > >> > > > >> Revisiting this and wondering about naming... > > > >> The file rte_queue.h is not really DPDK (ie not related to runtime > > > >> environment). > > > >> Thinking of calling it bsd_queue.h as a compromise > > > > > > > > Since it replaces sys/queue.h, then maybe sys_queue.h (or > rte_sys_queue.h). > > > > > > > > But more importantly: > > > > It is not really DPDK, and thus shouldn't really be part of the EAL. > > > > So here's an idea: > > > > As part of de-bloating the EAL, can we somehow add a new directory > structure > > > for independent "libraries" like this? > > > > And treat this rte_queue.h file as a "header file only" library, and put > it > > > there. > > > > Then, build wise, the EAL could depend on this "library". > > > > > > > > > > IMO it depends on what you mean by "EAL". EAL is environment abstraction > > > layer, and this header abstracts OS, thereby meeting description of an > > > "environment abstraction layer"? > > > > This library (header file) is generic, and has zero interaction with the > hardware and OS, so it's not an environment abstraction. > > I disagree here, it is something due by the OS libc, > but not reliably available everywhere. > > > The EAL has become a dump for "everything else" that isn't an individual > library with its own subdirectory of the /lib directory. > > IMO, it would be nice if we could separate generic utility libraries from > the EAL. > > I agree with the goal of having a thinner EAL. > > I'm not sure about this one.
I thought this file might be a good place to start separating utilities from abstraction. However, a well designed roadmap to re-organize the EAL is probably better than starting with this specific library. Sorry (not sorry) about the noise. I will keep reminding the community about the bloated EAL from time to time. :-)
