11/08/2023 14:59, Bruce Richardson: > On Fri, Aug 11, 2023 at 02:46:13PM +0200, David Marchand wrote: > > On Wed, Aug 9, 2023 at 3:36 PM Bruce Richardson > > <bruce.richard...@intel.com> wrote: > > > > > > There is a general desire to reduce the size and scope of EAL. To this > > > end, this patchset makes a (very) small step in that direction by taking > > > the logging functionality out of EAL and putting it into its own library > > > that can be built and maintained separately. > > > > > > As with the first RFC for this, the main obstacle is the "fnmatch" > > > function which is needed by both EAL and the new log function when > > > building on windows. While the function cannot stay in EAL - or we would > > > have a circular dependency, moving it to a new library or just putting > > > it in the log library have the disadvantages that it then "leaks" into > > > the public namespace without an rte_prefix, which could cause issues. > > > Since only a single function is involved, subsequent versions take a > > > different approach to v1, and just moves the offending function to be a > > > static function in a header file. This allows use by multiple libs > > > without conflicting names or making it public. > > > > > > The other complication, as explained in v1 RFC was that of multiple > > > implementations for different OS's. This is solved here in the same > > > way as v1, by including the OS in the name and having meson pick the > > > correct file for each build. Since only one file is involved, there > > > seemed little need for replicating EAL's separate subdirectories > > > per-OS. > > > > Series applied, thanks Bruce for this first step. > > > > As mentionned during the maintainers weekly call yesterday, this is > > only a first "easy" step but, thinking of next steps, more splitting > > may not be that easy. > > I took a look after doing this patchset to try and find more easy to > extract parts, but did not find many. The EAL is pretty intertwined now. > As I look at it, there are really two ways to try and dis-entangle it - > bottoms-up or top-down. This patchset is an example of the former, taking a > logical set of related APIs and pulling them out into a separate library > that EAL can depend upon. There may be some other API-sets like this we can > pull out, but in my search I didn't find any.
A small thing to easily separate is rte_bitmap. > The other tops-down approach may be worth looking at too. We can try and > take the top-level EAL init function and separate it out into a separate > initialization library (which may be called "EAL" with the rest being > called something else). I have not tried this approach to see how it goes, > but pulling out the init may allow further dis-entangling of other parts of > EAL. I agree we should start with separating the init logic. I would call it rte_init. We may need rte_opts for command line parsing. I think the name EAL should be kept for the low-level functions, abstracting differences between OS, CPU and toolchains. Next steps would be to try to separate memory and CPU management in 2 different libraries. We'll need to decide whether rte_service is part of the CPU management. Same question for multiprocess communication rte_mp and rte_keepalive. I suppose we can keep IRQ and threading in EAL. VFIO may be managed in a separate library perhaps. Once we do that, the low-level libraries like log, kvargs and telemetry can depend on EAL, being the very low-level common denominator. The trace subsystem can probably become a separate library as well. In a later step, we can think about bus and device management. And the ideal would be to extract tailq, once all logic is out of EAL. How does it sound?
