> On 12 Jul 2019, at 15:40, Christian Hopps <[email protected]> wrote:
>
> Thanks for the review.. I have a comments and a question inline...
>
>> On Jul 12, 2019, at 9:11 AM, Damjan Marion <[email protected]> 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.
yeah, painful...
>
>> 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.
Definitely most common case is dual stride case, you need to prefetch buffer
metadata first as you need to read b->current_data out to know where exactly is
data you want to prefetch in second round.
>
>> 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.
speed matters :) your scalar approach is slow for most common case which is
many packets going to same next….
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13501): https://lists.fd.io/g/vpp-dev/message/13501
Mute This Topic: https://lists.fd.io/mt/32438895/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
