We should not rename variables in existing codes unless we're rewriting from scratch. It's already hard enough to cherry-pick bugfixes from master/latest to stable/2001 and stable/1908.
Making wholesale variable name changes turns every subsequent cherry-pick into an adventure. In the interests of not breaking release-train software, we really can't go there. I wish that the available tooling would allow us the freedom you seek, but they do not. Dave P.S. mapping "n_vectors" to whatever it means to you seems like a pretty minimal entry barrier. It's not like the code is inconsistent. -----Original Message----- From: Elias Rudberg <elias.rudb...@bahnhof.net> Sent: Tuesday, March 31, 2020 9:21 AM To: Dave Barach (dbarach) <dbar...@cisco.com>; cho...@chopps.org; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] n_vectors... Hi Chris and Dave, Thanks for bringing this up, and thanks for explaining! I agree with Chris that this is confusing, it makes it much more difficult to understand the code. Perhaps this is the kind of thing that doesn't matter much to those who are already familiar with the code, while at the same time it matters a lot for newcomers. If you want to lower the threshold for new people to be able to come in and understand the code and possibly contribute, then I think it would be a good idea to fix this even if it means changing many lines of code. It could be argued that the fact that "n_vectors" exists in so many places makes it even more important to have a reasonable name for it. One way could be to start with renaming things in some of the main data structures like those in vlib/node.h and vlib/threads.h and such places, and the changes the compiler will force as a result of that. Best regards, Elias On Tue, 2020-03-31 at 00:45 +0000, Dave Barach via Lists.Fd.Io wrote: > Hmmm, yeah. Been at this for years, I can’t really remember when we > settled on e.g. n_vectors vs. n_vector_elts or some such. > > In new code, it’s perfectly fair to use whatever names seem fit for > purpose. > > Vlib would be happy doing image processing, or any other kind of > vector processing. There’s no law which says that frames need to have > 32-bit elements. Each node decides. > > FWIW... Dave > > From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Christian > Hopps > Sent: Monday, March 30, 2020 8:07 PM > To: vpp-dev <vpp-dev@lists.fd.io> > Cc: Christian Hopps <cho...@chopps.org> > Subject: [vpp-dev] n_vectors... > > Something has always bothered me about my understanding of VPPs use of > the term "vector" and "vectors". When I think of Vector Packet > Processing I think of processing a vector (array) of packets in a > single call to a node. The code, though, then seems to refer to the > individual packets as "vectors" when it uses field names like > "n_vectors" to refer to the number of buffers in a frame, or when > "show runtime" talks about "vectors per call", when I think it's > really talking about "packets/buffers per call" (and my mind wants to > think that it's always *1* vector/frame of packets per call by > design). > > I find this confusing, and so I thought I'd ask if there was some > meaning here I'm missing? > > Thanks, > Chris.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15957): https://lists.fd.io/g/vpp-dev/message/15957 Mute This Topic: https://lists.fd.io/mt/72667316/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
