> On Jul 12, 2019, at 9:53 AM, Damjan Marion <[email protected]> wrote: > >>> 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….
But I don't see how my code is different from vlib_buffer_enqueue_to_next. I'm not sure what you mean by scalar, but if you look closely I'm collecting the buffer indices directly into each next node's frame in parallel, it's not serial, and I only "put" a frame when the frame is full or at the very end of processing. Pretty sure switching to vlib_buffer_enqueue_to_next would just involve a lot of extra buffer index copying going on. :) Thanks, Chris.
signature.asc
Description: Message signed with OpenPGP
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13502): https://lists.fd.io/g/vpp-dev/message/13502 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]] -=-=-=-=-=-=-=-=-=-=-=-
