> On 10 Jan 2019, at 07:15, Raj <rajlistu...@gmail.com> wrote: > > On Wed, Jan 9, 2019 at 4:18 PM Damjan Marion <dmar...@me.com> wrote: >>> On 9 Jan 2019, at 09:53, Raj <rajlistu...@gmail.com> wrote: >>> 1. static_always_inline void >>> vlib_buffer_enqueue_to_next (vlib_main_t * vm, vlib_node_runtime_t * node, >>> u32 * buffers, u16 * nexts, uword count) >>> >> >> This function simply gets array of buffer indices and array of next indices, >> and enqueues those buffers to be processed by those next nodes... > > Is this function only used in the case of feature arc, where some > packets satisfies certain criteria and moves to a different node? > Basically from where do we get the array of next indices?
No, it can be used without feature arcs. > > Also in the code certain macros CLIB_HAVE_VEC128, CLIB_HAVE_VEC256 and > CLIB_HAVE_VEC512 are defined. I could not figure out what these do. They don't do anything, they are just set or not set depending on availability of vector instructions on the target cpu. > >>> type can be either LOAD or STORE. What is the purpose of these two >>> operations? >> On x86, there was only load prefetch for a long time, recently store >> prefetch is introduced >> with Skylake microarchitecture. You can find explanation here: > > Based on code walkthrough, one thing I have observed is where ever > .function is defined, static binding happens. In other nodes, dynamic > binding based on the macro VLIB_NODE_FN happens. yep > So If I understand > correctly, we have to use STORE in the latter case. But we can use > LOAD as well. There is no hard and fast rule. Please correct me if I'm > wrong. It is good practice to pick the one which you really need. i.e. if you want to prefetch for store, just use STORE, if store is not available compiler will do LOAD instead... -- Damjan
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11911): https://lists.fd.io/g/vpp-dev/message/11911 Mute This Topic: https://lists.fd.io/mt/28982509/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
