On Wed, Nov 23, 2016 at 09:11:54AM -0500, Neil Horman wrote:
> > Could we define some of the potential subtrees now and look to introduce
> > them in the this release cycle? EAL and the Core libs, as suggested by
> > Thomas, seem like 2 obvious ones.
> >
> Sure, I'd suggest the following:
I would pull the git history to see which components are in
active status in last release (or even, in last few release).
And try to make a sub-tree if corresponding component is hot.
# the 2nd volume shows how many patches prefixed with a related component
[yliu at yliu-dev ~/dpdk]$ git log --oneline v16.07..v16.11 | awk '{print $2}'
| \
sort | uniq -c | sort -nr | head -30 | nl
1 52 doc:
2 40 net/ixgbe/base:
3 38 app/test:
4 37 kni:
5 27 vhost:
6 27 net/virtio:
7 27 net/mlx5:
8 26 app/testpmd:
9 25 net/i40e:
10 23 net/pcap:
11 22 net/bnxt:
12 20 net/enic:
13 18 net/qede:
14 17 net/thunderx:
15 16 net/qede/base:
16 16 eal:
17 15 net/ixgbe:
18 14 net:
19 14 crypto/qat:
20 13 scripts:
21 13 net/bnx2x:
22 12 net/i40e/base:
23 12 examples/ipsec-secgw:
24 11 mbuf:
25 11 hash:
26 10 lib:
27 10 examples/ip_pipeline:
28 10 ethdev:
29 9 pci:
30 7 net/vmxnet3:
...
46 3 pdump:
47 3 net/virtio_user:
48 3 net/ring:
49 3 net/nfp:
50 3 net/mlx:
51 3 net/ena:
52 3 net/e1000:
53 3 net/bonding:
...
56 2 sched:
57 2 port:
...
65 1 timer:
66 1 remove
67 1 pmdinfogen:
68 1 net/igb:
69 1 net/enic/base:
70 1 meter:
...
84 1 cfgfile:
85 1 app/procinfo:
86 1 app/proc_info:
87 1 acl:
Something obvious is that:
- "doc" deserves a sub-tree, and John is a perfect committer for that
if he's willing to.
- generally, I'd agree with Neil that most (if not all) pmds may need
a sub-tree. While, some others may not, for example, net/ring, net/pcap.
For those non-active pmds, I think it's okay to let the generic
pmd committer to cover them.
- it's not that wise to me to list all the components we have so far
and make a sub-tree for each of them.
For example, some components like librte_{port, pdump, cfgfile, acl,
and etc} just have few (or even, just one) commits in last release.
It makes no sense to me to introduce a tree for each of them.
Another thought is we could also create sub-trees based on category
but not on components like Neil suggested, especially that EAL looks
way too big to be maintained in one tree. Instead, it could be something
like:
- a tree for BSD
- a tree for ARM (and some other trees for other platforms)
- a tree for mem related (mempool, mbuf, hugepage, etc)
- a tree for BUS
- ...
Last but not the least, I think it's general good to have more and
more trees in the end. But I don't think it's a good idea to go
radically and create all those trees once (say in one release).
Something I would like to suggest is one or two (or a bit more) at
a release. For example, if I remember them well, we have next-net
tree at 16.04, and next-virtio (including vhost) at 16.07, and a
recent one, next-crypto at 16.11.
--yliu
> * net-pmds:
> - all network pmds located under drivers/net
> - librte_net
> - libtre_ether
> - librte_ip_frag
> - librte_pdump
> - librte_port
> * crypto-pmds:
> - all crypto pmds located under drivers/crypto
> - librte_cryptodev
> * eal:
> - librte_eal
> * core:
> - librte_cfgfile
> - librte_cmdline
> - librte_compat
> - librte_kvargs
> - librte_kni
> - librte_compat
> * misc:
> - librte_acl
> - librte_distributor
> - librte_hash
> - librte_jobstats
> - librte_lpm
> - librte_meter
> - librte_pipeline
> - librte_power
> - librte_reorder
> - librte_ring
> - librte_sched
> - librte_table
> - librte_timer
> - librte_vhost
>
> Thats just a rough stab mind, but perhaps it would get the ball rolling. I'd
> be
> willing to take maintainership of one of these subtrees if there is consensus
> around my doing so.
