Mailing List Archive: PF_RING + bridge continue

PF_RING + bridge continue

Jul 14, 2019, 9:38 AM

Post #1 of 7 (2181 views)

Hello,

After some more testing it looks like it might have nothing to do with PF_RING attached to a bridge.

My test is sending a 1024 bytes UDP packet at a fast rate (about 110,000 packets per second) to a small old Linux

box running the PF_RING enabled process.

The process is pending on pfring_recv() waiting to get new packets on br0 .

What I was able to see is that at some point after the test has started,

the drops count (got it from pfring_stats()) went up rapidly.

while pfring_recv() was pending forever and not getting triggered to read more packets.

What did I do wrong?
Thanks

Eitan.

Re: PF_RING + bridge continue [ In reply to ]

eitanm at me

Jul 14, 2019, 10:55 AM

Post #2 of 7 (2181 views)

Permalink

Looks like after the first packet is drooped there is no way for my application to continue and receive packets.

As long as there are no doped packets all is OK, the first drop practically breaks the application.

It does not matter if pfring_recv() is blocking or not

[ 679.175760] [PF_RING] Welcome to PF_RING 7.5.0 ($Revision: unknown$) // Custom kernel
[ 679.175760] (C) 2004-17 ntop.org
[ 679.185328] LINUX_VERSION_CODE 00040E7B
[ 679.189173] [PF_RING] Min # ring slots 4096
[ 679.193358] [PF_RING] Slot version     17
[ 679.197368] [PF_RING] Capture TX       Yes [RX+TX]
[ 679.202183] [PF_RING] IP Defragment    No
[ 679.206208] NET: Registered protocol family 27
[ 679.210679] [PF_RING] pf_ring initialized correctly

On 14/07/2019 19:38, Eitan Michaelson wrote:

Hello,

After some more testing it looks like it might have nothing to do with PF_RING attached to a bridge.

My test is sending a 1024 bytes UDP packet at a fast rate (about 110,000 packets per second) to a small old Linux

box running the PF_RING enabled process.

The process is pending on pfring_recv() waiting to get new packets on br0 .

What I was able to see is that at some point after the test has started,

the drops count (got it from pfring_stats()) went up rapidly.

while pfring_recv() was pending forever and not getting triggered to read more packets.

What did I do wrong?
Thanks

Eitan.

_______________________________________________ Ntop-dev mailing list Ntop-dev@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-dev"]http://listgateway.unipi.it/mailman/listinfo/ntop-dev

Re: PF_RING + bridge continue [ In reply to ]

cardigliano at ntop

Jul 15, 2019, 1:04 AM

Post #3 of 7 (2181 views)

Permalink

Hi Eitan
please check the other email thread, I pushed a fix for this, please update from github or wait for the next packages later today.

Thank you
Alfredo

> On 14 Jul 2019, at 19:55, Eitan Michaelson <eitanm@me.com> wrote:
>
>
> Looks like after the first packet is drooped there is no way for my application to continue and receive packets.
> As long as there are no doped packets all is OK, the first drop practically breaks the application.
> It does not matter if pfring_recv() is blocking or not
>
> [ 679.175760] [PF_RING] Welcome to PF_RING 7.5.0 ($Revision: unknown$) // Custom kernel
> [ 679.175760] (C) 2004-17 ntop.org <http://ntop.org/>
> [ 679.185328] LINUX_VERSION_CODE 00040E7B
> [ 679.189173] [PF_RING] Min # ring slots 4096
> [ 679.193358] [PF_RING] Slot version 17
> [ 679.197368] [PF_RING] Capture TX Yes [RX+TX]
> [ 679.202183] [PF_RING] IP Defragment No
> [ 679.206208] NET: Registered protocol family 27
> [ 679.210679] [PF_RING] pf_ring initialized correctly
>
>
>
> On 14/07/2019 19:38, Eitan Michaelson wrote:
>> Hello,
>>
>> After some more testing it looks like it might have nothing to do with PF_RING attached to a bridge.
>> My test is sending a 1024 bytes UDP packet at a fast rate (about 110,000 packets per second) to a small old Linux
>> box running the PF_RING enabled process.
>>
>> The process is pending on pfring_recv() waiting to get new packets on br0 .
>>
>> What I was able to see is that at some point after the test has started,
>> the drops count (got it from pfring_stats()) went up rapidly.
>> while pfring_recv() was pending forever and not getting triggered to read more packets.
>>
>> What did I do wrong?
>> Thanks
>> Eitan.
>>
>>
>>
>> _______________________________________________
>> Ntop-dev mailing list
>> Ntop-dev@listgateway.unipi.it <mailto:Ntop-dev@listgateway.unipi.it>
>> http://listgateway.unipi.it/mailman/listinfo/ntop-dev <http://listgateway.unipi.it/mailman/listinfo/ntop-dev>_______________________________________________
> Ntop-dev mailing list
> Ntop-dev@listgateway.unipi.it <mailto:Ntop-dev@listgateway.unipi.it>
> http://listgateway.unipi.it/mailman/listinfo/ntop-dev <http://listgateway.unipi.it/mailman/listinfo/ntop-dev>

Re: PF_RING + bridge continue [ In reply to ]

cardigliano at ntop

Jul 15, 2019, 1:04 AM

Post #4 of 7 (2181 views)

Permalink

Re: PF_RING + bridge continue [ In reply to ]

eitanm at me

Jul 15, 2019, 1:15 AM

Post #5 of 7 (2181 views)

Permalink

OK will do,

But, I'm currently using 7.5.0 as seen on that mini log as sent (DL it about 14 days ago)

should this be the fixed version ?

On 15/07/2019 11:04, Alfredo Cardigliano wrote:

Hi Eitan please check the other email thread, I pushed a fix for this, please update from github or wait for the next packages later today.
Thank you
Alfredo

On 14 Jul 2019, at 19:55, Eitan Michaelson <eitanm@me.com> wrote:

Looks like after the first packet is drooped there is no way for my application to continue and receive packets. As long as there are no doped packets all is OK, the first drop practically breaks the application. It does not matter if pfring_recv() is blocking or not
[? 679.175760] [PF_RING] Welcome to PF_RING 7.5.0 ($Revision: unknown$) // Custom kernel
[? 679.175760] (C) 2004-17?http://ntop.org/"]ntop.org
[? 679.185328] LINUX_VERSION_CODE 00040E7B
[? 679.189173] [PF_RING] Min # ring slots 4096
[? 679.193358] [PF_RING] Slot version???? 17
[? 679.197368] [PF_RING] Capture TX?????? Yes [RX+TX]
[? 679.202183] [PF_RING] IP Defragment??? No
[? 679.206208] NET: Registered protocol family 27
[? 679.210679] [PF_RING] pf_ring initialized correctly

On 14/07/2019 19:38, Eitan Michaelson wrote:

Hello,?

After some more testing it looks like it might have nothing to do with PF_RING attached to a bridge. My test is sending a 1024 bytes UDP packet at a fast rate (about 110,000 packets per second) to a small old Linux box running the PF_RING enabled process.
The process is pending on pfring_recv() waiting to get new packets on br0 .

What I was able to see is that at some point after the test has started, the drops count (got it from pfring_stats()) went up rapidly.
while pfring_recv() was pending forever and not getting triggered to read more packets.

What did I do wrong?
Thanks Eitan.

_______________________________________________ Ntop-dev mailing list Ntop-dev@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-dev"]http://listgateway.unipi.it/mailman/listinfo/ntop-dev
_______________________________________________
Ntop-dev mailing list
Ntop-dev@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop-dev"]http://listgateway.unipi.it/mailman/listinfo/ntop-dev

_______________________________________________ Ntop-dev mailing list Ntop-dev@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-dev"]http://listgateway.unipi.it/mailman/listinfo/ntop-dev

Re: PF_RING + bridge continue [ In reply to ]

cardigliano at ntop

Jul 15, 2019, 1:31 AM

Post #6 of 7 (2181 views)

Permalink

Hi Eitan
7.5 is dev, thus the answer is yes.

Alfredo

> On 15 Jul 2019, at 10:15, Eitan Michaelson <eitanm@me.com> wrote:
>
> OK will do,
> But, I'm currently using 7.5.0 as seen on that mini log as sent (DL it about 14 days ago)
> should this be the fixed version ?
>
>
> On 15/07/2019 11:04, Alfredo Cardigliano wrote:
>> Hi Eitan
>> please check the other email thread, I pushed a fix for this, please update from github or wait for the next packages later today.
>>
>> Thank you
>> Alfredo
>>
>>> On 14 Jul 2019, at 19:55, Eitan Michaelson <eitanm@me.com <mailto:eitanm@me.com>> wrote:
>>>
>>>
>>> Looks like after the first packet is drooped there is no way for my application to continue and receive packets.
>>> As long as there are no doped packets all is OK, the first drop practically breaks the application.
>>> It does not matter if pfring_recv() is blocking or not
>>>
>>> [ 679.175760] [PF_RING] Welcome to PF_RING 7.5.0 ($Revision: unknown$) // Custom kernel
>>> [ 679.175760] (C) 2004-17 ntop.org <http://ntop.org/>
>>> [ 679.185328] LINUX_VERSION_CODE 00040E7B
>>> [ 679.189173] [PF_RING] Min # ring slots 4096
>>> [ 679.193358] [PF_RING] Slot version 17
>>> [ 679.197368] [PF_RING] Capture TX Yes [RX+TX]
>>> [ 679.202183] [PF_RING] IP Defragment No
>>> [ 679.206208] NET: Registered protocol family 27
>>> [ 679.210679] [PF_RING] pf_ring initialized correctly
>>>
>>>
>>>
>>> On 14/07/2019 19:38, Eitan Michaelson wrote:
>>>> Hello,
>>>>
>>>> After some more testing it looks like it might have nothing to do with PF_RING attached to a bridge.
>>>> My test is sending a 1024 bytes UDP packet at a fast rate (about 110,000 packets per second) to a small old Linux
>>>> box running the PF_RING enabled process.
>>>>
>>>> The process is pending on pfring_recv() waiting to get new packets on br0 .
>>>>
>>>> What I was able to see is that at some point after the test has started,
>>>> the drops count (got it from pfring_stats()) went up rapidly.
>>>> while pfring_recv() was pending forever and not getting triggered to read more packets.
>>>>
>>>> What did I do wrong?
>>>> Thanks
>>>> Eitan.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ntop-dev mailing list
>>>> Ntop-dev@listgateway.unipi.it <mailto:Ntop-dev@listgateway.unipi.it>
>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-dev <http://listgateway.unipi.it/mailman/listinfo/ntop-dev>_______________________________________________
>>> Ntop-dev mailing list
>>> Ntop-dev@listgateway.unipi.it <mailto:Ntop-dev@listgateway.unipi.it>
>>> http://listgateway.unipi.it/mailman/listinfo/ntop-dev <http://listgateway.unipi.it/mailman/listinfo/ntop-dev>
>>
>>
>> _______________________________________________
>> Ntop-dev mailing list
>> Ntop-dev@listgateway.unipi.it <mailto:Ntop-dev@listgateway.unipi.it>
>> http://listgateway.unipi.it/mailman/listinfo/ntop-dev <http://listgateway.unipi.it/mailman/listinfo/ntop-dev>_______________________________________________
> Ntop-dev mailing list
> Ntop-dev@listgateway.unipi.it <mailto:Ntop-dev@listgateway.unipi.it>
> http://listgateway.unipi.it/mailman/listinfo/ntop-dev <http://listgateway.unipi.it/mailman/listinfo/ntop-dev>