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>
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> 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
>
_______________________________________________
Ntop-misc mailing list
Ntop-misc@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop-misc
