Re: [Ntop-misc] pf_ring: Clarification regarding the relation between poll-watermark and poll-duration

[Alfredo Cardigliano]

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  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(>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  
>> wrote:
>> 
>> 
>>> On 31 Oct 2017, at 08:42, Amir Kaduri  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 
  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  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  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
>>> 

Re: [Ntop-misc] pf_ring: Clarification regarding the relation between poll-watermark and poll-duration

[Amir Kaduri]

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(>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 
wrote:

>
>
> On 31 Oct 2017, at 08:42, Amir Kaduri  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  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  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

Re: [Ntop-misc] pf_ring: Clarification regarding the relation between poll-watermark and poll-duration

[Alfredo Cardigliano]

> On 31 Oct 2017, at 08:42, Amir Kaduri  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  > 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 > > 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 > > 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



signature.asc
Description: Message signed with OpenPGP
___
Ntop-misc mailing list
Ntop-misc@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

Re: [Ntop-misc] pf_ring: Clarification regarding the relation between poll-watermark and poll-duration

[Amir Kaduri]

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.
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 
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  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  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