Hi, I too agree with Chris and Elias. Although my suggestion is not to change code variables or any code per say because it's not difficult to understand the code. But at least, we should change documentation/comments and CLI output which makes obvious that packet != vector (although it is currently). People tend to relate vector with vlib_frame and it is hard to make them understand that vector is not vlib_frame but a single packet.
Thanks, Nitin > -----Original Message----- > From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Christian > Hopps > Sent: Tuesday, March 31, 2020 7:36 PM > To: Elias Rudberg <elias.rudb...@bahnhof.net> > Cc: Christian Hopps <cho...@chopps.org>; dbar...@cisco.com; vpp- > d...@lists.fd.io > Subject: [EXT] Re: [vpp-dev] n_vectors... > > External Email > > ---------------------------------------------------------------------- > > > > 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 (#15973): https://lists.fd.io/g/vpp-dev/message/15973 Mute This Topic: https://lists.fd.io/mt/72724951/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
