Alfredo, Now I understand why zsend.c uses 256 buffers. So I guess I’ve answered my question - I only need a single buffer handle as I’m not pre-building a bunch of packets as zsend.c does.
Thanks, Mike > On Aug 11, 2015, at 10:47 AM, Michael Nicolazzo <[email protected]> > wrote: > > Alfredo, > > Thanks again. This leads to another question. If I create packets, much like > zsend, then I only need a single buffer handle? I fill in the buffer, enqueue > it, am given a new buffer in the same handle which I then fill, enqueue it, > etc? If this is so, why does zsend.c allocate 256 buffers that it rotates > through? > > Mike > >> On Aug 11, 2015, at 10:34 AM, Alfredo Cardigliano <[email protected]> >> wrote: >> >> Without a multiqueue this is not possible, when you send() the packet to the >> first queue, your actual buffer handle will point to a new buffer (a swap >> operation takes place, this is needed for zero-copy), thus with the second >> send() you are actually sending uninitialised data, instead sending to a >> multiqueue the same packet reference is passed to both queues. >> >> Alfredo >> >>> On 11 Aug 2015, at 16:20, Michael Nicolazzo <[email protected]> wrote: >>> >>> Alfredo, >>> >>> Thanks. One other question - what are the consequences if instead of a >>> multi-queue I queue the same packet to two different individual queues? >>> >>> Thanks again, >>> >>> Mike >>> >>>> On Aug 11, 2015, at 10:16 AM, Alfredo Cardigliano <[email protected]> >>>> wrote: >>>> >>>> >>>>> On 11 Aug 2015, at 15:45, Michael Nicolazzo <[email protected]> >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I have a question about the behavior of pfring_zc multi_queue. Suppose I >>>>> bundle two queues into a multi_queue. What happens if I send a buffer to >>>>> both queues, but one of the queues has an error, such as full? Will >>>>> send_pkt_multi queue one and and fail the other? >>>> >>>> Correct >>>> >>>>> If so, how can I tell which queue had the problem? >>>> >>>> With the current API the only way is checking queue stats. >>>> >>>> Alfredo >>>> >>>>> >>>>> 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 >> >> _______________________________________________ >> 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
