OK, thanks!

Mike

> On Dec 30, 2015, at 12:05 PM, Alfredo Cardigliano <[email protected]> 
> wrote:
> 
> 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

_______________________________________________
Ntop-misc mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

Reply via email to