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_duratio
>>> n()).
>>> 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
