> On Mar 31, 2020, at 9:20 AM, Elias Rudberg <elias.rudb...@bahnhof.net> wrote: > > 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.
As someone who UTSL as a first, second and third setp, I tend to agree. It made things harder then they probably needed to be when I was trying to grok the gestalt. Lot of history though, hard to change (or even ask) for something like this. A happy start for me would be if "show runtime" didn't call packets "Vectors". And, if someone repurposed vlib for non-packets they could change "Packets" to "Elements" or whatever they want :) Of course I did this in our local branch, but wasn't planning on trying to upstream. Thanks, Chris. > > 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 (#15959): https://lists.fd.io/g/vpp-dev/message/15959 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] -=-=-=-=-=-=-=-=-=-=-=-
