Hi Mike yes this should work, as long as the number of buffers you keep aside in thread 3 is smaller than the number of buffers in the pool you use for allocating packets pfring_zc_get_packet_handle, of course. However, in case there is no buffer available in the pool (pfring_zc_get_packet_handle failure) I would just return one of the buffers kept aside to the next read, to avoid drops, but this actually depends on the priority in your application.
Best Regards Alfredo > On 29 Dec 2015, at 21:24, Michael Nicolazzo <[email protected]> wrote: > > Hi, > > I have a question regarding handling buffers with pfring_zc in a rather > complex environment. I have three threads handling buffers. Thread 1 reads > buffers from an interface queue and puts the buffer on a multiqueue for > threads 2 and 3 to process. Thread 2 processes the packet and then reads its > queue for the next buffer, returning the buffer it just handled in the > process. (I assume at this time that since another thread must handle the > same buffer that it is not really released to the pool until the other thread > is done with it). Thread 3, however, will send the buffer out a different > interface, but only after delaying it for some time. So it must return to > reading its queue without returning the buffer it just received. I am > planning to handle this by saving the buffer somewhere, explicitly getting a > new buffer from the pool (pfring_zc_get_packet_handle) and returning that > buffer when I do the next read. When I am ready to transmit the saved buffer, > I will put the buffer on > an outgoing interface queue and return the buffer given back to me as a > result of the pfring_zc_send_pkt call to the pool > (pfring_zc_release_packet_handle). > > Will this work? Is this the best way to handle this situation? > > Thanks, > > Mike > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc _______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
