> On 30 Apr 2018, at 17:52, Amir Kaduri <akadur...@gmail.com> wrote: > > Thanks for the answers. > > So the only way to make handlep->timeout>=0, is by setting the > file-descriptor to "blocking" (nonblock=0) according to the logic in function > pcap_setnonblock_mmap() and this is something that we would like to avoid. > Therefore, we do the polling (non-blocking) in the application that uses > pcap/pf_ring. > The problem we have is with low-traffic network. According to the logic in > function copy_data_to_ring(), as long as the queue didn't reach the > "poll_num_pkts_watermark" threshold (in our case 128 packets), > the poll() (in userspace) won't be called (since wake_up_interruptible(..) > is not called), which means that we have packets that are stuck in the ring > till the queue reaches the watermark. > > I wonder if you see any rationale in improving the pf_ring kernel module > code, to call wake_up_interruptible() (in order to flush the queue) if some > "timeout" passed and the queue is not empty (but still didn't reach the > watermark).
I think that using the watermark in combination with a timeout is a good idea. Alfredo > Amir > > > On Thu, Apr 26, 2018 at 6:00 PM, Alfredo Cardigliano <cardigli...@ntop.org > <mailto:cardigli...@ntop.org>> wrote: > > >> On 26 Apr 2018, at 15:34, Amir Kaduri <akadur...@gmail.com >> <mailto:akadur...@gmail.com>> wrote: >> >> Hi Alfredo, >> >> My code is based on libpcap, while pfring's userland examples use pfring >> APIs directly, therefore things are a bit harder for me. >> >> Short clarification about a related code-line: >> Please look at the following line: >> https://github.com/ntop/PF_RING/blob/dev/userland/libpcap-1.8.1/pcap-linux.c#L1875 >> >> <https://github.com/ntop/PF_RING/blob/dev/userland/libpcap-1.8.1/pcap-linux.c#L1875> >> >> (1) If I understand it correctly, if wait_for_incoming_packet is true, then >> pfring_poll() should be called. >> Don't you want wait_for_incoming_packet to be true in case >> pf_ring_active_poll is true? > > “active” means spinning, thus poll should not be used in that case. > >> Currently, its the opposite (i.e. if pf_ring_active_poll is true, >> wait_for_incoming_packet will be false thus pfring_poll() won't be called). > > This seems to be correct > >> >> (2) If the code is ok, then the only way for me to make >> wait_for_incoming_packet true (for pfring_poll() to be called) is by making >> handlep->timeout >= 0. >> Correct? > > Correct > > Alfredo > >> >> Thanks, >> Amir >> >> On Mon, Apr 9, 2018 at 10:51 AM, Alfredo Cardigliano <cardigli...@ntop.org >> <mailto:cardigli...@ntop.org>> wrote: >> Hi Amir >> if I understand correctly, pfcount_multichannel is working, while in your >> application >> it seems that poll does not honor the timeout, if this is the case it seems >> the problem >> is not in the kernel module, I think you should look for differences between >> the two applications.. >> >> Alfredo >> >>> On 9 Apr 2018, at 07:20, Amir Kaduri <akadur...@gmail.com >>> <mailto:akadur...@gmail.com>> wrote: >>> >>> Hi Alfredo, >>> >>> I'm back to investigate/debug this issue in my environment, and maybe >>> you'll manage to save me some time: >>> >>> When I use the example program "pfcount_multichannel", poll-duration works >>> for me as expected: >>> For watermark=128, poll-duration=1000, even if less than 128 packets >>> received, I get them in pfcount_multichannel. >>> >>> On the other hand, in my other program (which is a complex one), the >>> userspace application gets the packets only after 128 packets >>> aggregated by the ring, regardless the polling rate (which is done always >>> using 50ms timeout). >>> >>> Maybe you can figure out what can "hold" the packets in the ring and >>> forward them to userspace only when the watermark threshold passes? >>> Maybe something is missing during initialization? >>> (for simplicity I'm not using rehash, and not using any filters). >>> >>> Thanks >>> >>> On Tue, Oct 31, 2017 at 6:32 PM, Alfredo Cardigliano <cardigli...@ntop.org >>> <mailto:cardigli...@ntop.org>> wrote: >>> Hi Amir >>> that's correct, however for some reason it seems it is not the case in your >>> tests. >>> >>> Alfredo >>> >>> On 31 Oct 2017, at 12:08, Amir Kaduri <akadur...@gmail.com >>> <mailto:akadur...@gmail.com>> wrote: >>> >>>> Thanks. tot_insert apparently works ok. >>>> >>>> Regarding function copy_data_to_ring(): >>>> At the end of it there is the statement: >>>> if(num_queued_pkts(pfr) >= pfr->poll_num_pkts_watermark) >>>> wake_up_interruptible(&pfr->ring_slots_waitqueue); >>>> >>>> Since watermark is set to 128, and I send <128 packets, this causes them >>>> to wait in kernel queue. >>>> But since poll_duration is set to 1 (1 millisecond I assume), I expect the >>>> condition to check this also (meaning, there are packets in queue but 1 >>>> millisecond passed and they weren't read), >>>> the wake_up_interruptible should also be called. No? >>>> >>>> Thanks, >>>> Amir >>>> >>>> >>>> On Tue, Oct 31, 2017 at 10:20 AM, Alfredo Cardigliano >>>> <cardigli...@ntop.org <mailto:cardigli...@ntop.org>> wrote: >>>> >>>> >>>>> On 31 Oct 2017, at 08:42, Amir Kaduri <akadur...@gmail.com >>>>> <mailto:akadur...@gmail.com>> wrote: >>>>> >>>>> Hi Alfredo, >>>>> >>>>> I'm trying to debug the issue, and I have a question about the code, to >>>>> make sure that there is no problem there: >>>>> Specifically, I'm referring to the function "pfring_mod_recv": >>>>> In order that the line that refers to poll_duration ("pfring_poll(ring, >>>>> ring->poll_duration)") will be reached, there are 2 conditions that >>>>> should occur: >>>>> 1. pfring_there_is_pkt_available(ring) should return false (otherwise, >>>>> the function returns at the end of the condition). >>>>> 2. wait_for_incoming_packet should be set to true. >>>>> Currently, I'm referring to the first one: >>>>> In order that the macro pfring_there_is_pkt_available(ring) will return >>>>> false, ring->slots_info->tot_insert should be equal to >>>>> ring->slots_info->tot_read. >>>>> What I see in my tests that they don't get equal. I always see that >>>>> tot_insert>tot_read, and sometimes they get eual when tot_read++ is >>>>> called but it happens inside the condition, so the "pfring_mod_recv" >>>>> returns with 1. >>>> >>>> It seems to be correct. The kernel module inserts packets into the ring >>>> increasing tot_insert, the userspace library reads packets from the ring >>>> increasing tot_read. This means that if tot_insert == tot_read there is no >>>> packet to read. If there is a bug, it should be in the kernel module that >>>> is somehow not adding packets to the ring (thus not updating tot_insert). >>>> >>>> Alfredo >>>> >>>>> I remind that I set the watermark to be high, in order to see the >>>>> poll_duration takes effect. >>>>> >>>>> Could you please approve that you don't see any problem in the code? >>>>> >>>>> Thanks, >>>>> Amir >>>>> >>>>> >>>>> On Thu, Oct 26, 2017 at 12:22 PM, Alfredo Cardigliano >>>>> <cardigli...@ntop.org <mailto:cardigli...@ntop.org>> wrote: >>>>> Hi Amir >>>>> yes, that’s the way it should work, if this is not the case, some >>>>> debugging is needed to identify the problem >>>>> >>>>> Alfredo >>>>> >>>>>> On 26 Oct 2017, at 10:14, Amir Kaduri <akadur...@gmail.com >>>>>> <mailto:akadur...@gmail.com>> wrote: >>>>>> >>>>>> Basically, the functionality that I would like to have is even if less >>>>>> than poll-watermark-threshold (default: 128) packets arrives the socket, >>>>>> they will be forwarded to userland if 1 millisecond has passed. >>>>>> How can I gain this? Isn't it by using pfring_set_poll_duration()? >>>>>> >>>>>> Alfredo, could you please clarify? >>>>>> >>>>>> Thanks, >>>>>> Amir >>>>>> >>>>>> On Wed, Oct 18, 2017 at 8:48 PM, Amir Kaduri <akadur...@gmail.com >>>>>> <mailto:akadur...@gmail.com>> wrote: >>>>>> Hi, >>>>>> >>>>>> I'm using pf_ring 6.6.0 (no ZC) on CentOS 7, on 10G interfaces (ixgbe >>>>>> drivers). >>>>>> As far as I understand the relation between poll-watermark and >>>>>> poll-duration, packets will be queued untill one of comes first: or >>>>>> passing the poll-watermark packets threshold, or a poll-duration >>>>>> milliseconds has passed. >>>>>> I set poll-watermark to the maximum (4096) (using >>>>>> pfring_set_poll_watermark()) and set poll-duration to the minimum (1) >>>>>> (using pfring_set_poll_duration()). >>>>>> I've sent 400 packets to the socket. I see that they are received by the >>>>>> NIC, but they didn't pass to userland. Only when passing 500 packets, a >>>>>> chunk of them passed to userland. >>>>>> I don't quite understand the behavior: since poll-duration is 1 >>>>>> (millisecond I assume), I've expected all the packets to pass to >>>>>> userland immediately, even though poll-watermark is much higher. >>>>>> >>>>>> Can anyone shed some light on the above? >>>>>> >>>>>> Thanks, >>>>>> Amir >>>>>> >>>>>> _______________________________________________ >>>>>> Ntop-misc mailing list >>>>>> Ntop-misc@listgateway.unipi.it <mailto:Ntop-misc@listgateway.unipi.it> >>>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>>>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >>>>> >>>>> _______________________________________________ >>>>> Ntop-misc mailing list >>>>> Ntop-misc@listgateway.unipi.it <mailto:Ntop-misc@listgateway.unipi.it> >>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >>>>> >>>>> _______________________________________________ >>>>> Ntop-misc mailing list >>>>> Ntop-misc@listgateway.unipi.it <mailto:Ntop-misc@listgateway.unipi.it> >>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >>>> >>>> _______________________________________________ >>>> Ntop-misc mailing list >>>> Ntop-misc@listgateway.unipi.it <mailto:Ntop-misc@listgateway.unipi.it> >>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >>>> >>>> _______________________________________________ >>>> Ntop-misc mailing list >>>> Ntop-misc@listgateway.unipi.it <mailto:Ntop-misc@listgateway.unipi.it> >>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >>> _______________________________________________ >>> Ntop-misc mailing list >>> Ntop-misc@listgateway.unipi.it <mailto:Ntop-misc@listgateway.unipi.it> >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >>> >>> _______________________________________________ >>> Ntop-misc mailing list >>> Ntop-misc@listgateway.unipi.it <mailto:Ntop-misc@listgateway.unipi.it> >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >> >> _______________________________________________ >> Ntop-misc mailing list >> Ntop-misc@listgateway.unipi.it <mailto:Ntop-misc@listgateway.unipi.it> >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >> >> _______________________________________________ >> Ntop-misc mailing list >> Ntop-misc@listgateway.unipi.it <mailto:Ntop-misc@listgateway.unipi.it> >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> > > _______________________________________________ > Ntop-misc mailing list > Ntop-misc@listgateway.unipi.it <mailto:Ntop-misc@listgateway.unipi.it> > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> > > _______________________________________________ > Ntop-misc mailing list > Ntop-misc@listgateway.unipi.it > http://listgateway.unipi.it/mailman/listinfo/ntop-misc
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Ntop-misc mailing list Ntop-misc@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc
