Thanks for the review.. I have a comments and a question inline... > On Jul 12, 2019, at 9:11 AM, Damjan Marion <dmar...@me.com> wrote: > >> ... > > Hi Cristian, > > You are not fist one trying to do that, few of us did and we all failed :).
:) > Few comments: > > 1. It is going to be painful to use "perf top" on this code, as annotation > will be useless when those macros are used Well for handling that case one can do the macro expansion in the code. > 2. while most of our nodes are just mechanically duplicated, to get best > performace you need to manually interleave, prefetches with rest of the code > (good example is dpdk-input node) > 3. I don’t see how your macro will work with double prefetch strides, i.e. > prefetch data which depends on b->current_data. These macros are intended to cover the common use case, but not every case. They certainly would work to replace more than a couple instances I've seen of the hand-copied pattern. > 4. CLIB_N_PREFETCHES can hardly be 16 as number of outstanding prefetches on > x86 is 12 and that number did not change for many years. Beside that those 12 > slots are shared with 2 hardware prefetches so it is hard to expect that you > will have more than 8 available. On arm I think it is even less specially on > low end CPUs. Sure, whatever the value is it was 16 where I looked. In any case the only point was you only have to change a single value in the macro (probably should be a parameter). > 5. you should consider using vlib_buffer_enqueue_to_next() instead of > vlib_get_next_frame/vlib_put_next_frame scheme Can you help me understand this? I may be reading the code wrong but vlib_buffer_enqueue_to_next() appears to just be copying buffer indices into each next nodes frame (after calling clib_get_next_frame()), and then calling vlib_put_next_frame(). This is exactly what my code is already doing so it would appear to be 100% overhead to call it. Thanks, Chris.
signature.asc
Description: Message signed with OpenPGP
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13500): https://lists.fd.io/g/vpp-dev/message/13500 Mute This Topic: https://lists.fd.io/mt/32438895/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
