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> 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>
>> wrote:
>>
>>
>>> On 31 Oct 2017, at 08:42, Amir Kaduri <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> 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> 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> 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
>>>>> 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
>>>
>>> _______________________________________________
>>> Ntop-misc mailing list
>>> Ntop-misc@listgateway.unipi.it
>>> 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
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc@listgateway.unipi.it
> 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
