Re: [dpdk-dev] [RFC PATCH 0/2] Move PMDs out of lib directory

[Bruce Richardson <bruce.richardson@intel.com>]

On Thu, May 07, 2015 at 10:11:15PM +0100, Wiles, Keith wrote:
> 
> 
> On 5/7/15, 9:04 AM, "Bruce Richardson" <bruce.richardson@intel.com> wrote:
> 
> >On Thu, May 07, 2015 at 05:45:20PM +0200, Marc Sune wrote:
> >> 
> >> 
> >> On 07/05/15 17:35, Bruce Richardson wrote:
> >> >The "lib" directory is getting very crowded, with both general libs and
> >> >poll mode drivers in it. This patch set proposes to move the PMDs out
> >>of the
> >> >lib folder and to put them in a separate "pmds" folder. This should
> >>help
> >> >with code browse-ability as the number of libs, and pmds increases.
> >> >
> >> >Comments or objections?
> >> >
> >> >Bruce Richardson (2):
> >> >   pmds: Use relative rather than absolute paths
> >> >   pmds: move pmds from lib to separate pmd dir
> >> >
> >> >  create mode 100644 pmds/librte_pmd_xenvirt/rte_mempool_gntalloc.c
> >> >  create mode 100644 pmds/librte_pmd_xenvirt/rte_xen_lib.c
> >> >  create mode 100644 pmds/librte_pmd_xenvirt/rte_xen_lib.h
> >> >  create mode 100644 pmds/librte_pmd_xenvirt/virtio_logs.h
> >> >  create mode 100644 pmds/librte_pmd_xenvirt/virtqueue.h
> >> >
> >> 
> >> But at the end they are also libraries. What about something like:
> >> 
> >> * libs/core <= fundamental libraries (eal, mbuf rings...)
> >> * libs/pmds <= all pmds
> >> 
> >> And other feature-group oriented, higher level lib, directories (not
> >>sure
> >> right now how to better classify them right now):
> >> * libs/processing <= packet processing
> >> * libs/utils
> >> ...
> >> 
> >Yes, they are all just libs, so we could make "pmds" be a sub-dir of the
> >lib
> >folder. I prefer the shorter path myself, but if others want a multi-level
> >hierarchy it's no big deal.
> 
> I like the dpdk/pmds as dpdk/lib/pmds is a bit longer, but I also see if
> we want to move the pmds to other repo(s) in the future it would be easier
> (I think) to have the subtree at the top. To me pmds are not really
> libraries as I think of libc or libcrypto or something along that path.
> 
> The PMDs need to be plug able and they maybe more like loadable modules
> then libraries in the future.
> 
> >
> >For the other libs, I'm not sure we need to split them up, and I also
> >think
> >that trying to divide them into categories - and what those categories
> >should
> >be could - cause endless discussion. However, maybe I'm overly
> >pessimistic... :-)
> 
> I agree with Bruce here we just need the PMDS split out for now.

However, if in future we might want to split out the other libs into categories,
it may make more sense to have the pmds as a subfolder lib.

I still think I prefer having pmds at the top level of the tree, though.

/Bruce