Re: Capture send packets in ZC mode

Alfredo Cardigliano <[email protected]> Tue, 7 Nov 2017 16:13:49 +0100
Newsgroups	gmane.linux.ntop.general
Message-ID	<[email protected]>
Hi Charles
I guess you are using the standard PF_RING API, any chance you can try the ZC API to
check if there is any difference? (the passive-wait implementation is different, and it usually
perform better).
I also pushed a change to the standard API, please update and let us know if you see any
improvement.

Thank you
Alfredo

> On 3 Nov 2017, at 15:08, Charles-Antoine Mathieu <[email protected]> wrote:
> 
> I found a major difference between doing the pfring_recv call with the
> wait_for_incoming_packet flag set and a busy loop with the flag set to
> 0.
> 
> Do you know why the flag induce so much latency ?
> 
> With wait_for_incoming_packet set to 1
> # ./ntop
> 2017/11/03 14:54:50 Opening PF_RING capture zc:eth2@0
> 2017/11/03 14:54:51 1.031169ms
> 2017/11/03 14:54:51 3.125617ms
> 2017/11/03 14:54:51 42.012934ms
> 2017/11/03 14:54:51 13.026811ms
> 2017/11/03 14:54:52 14.241295ms
> 2017/11/03 14:54:52 53.317201ms
> 2017/11/03 14:54:52 21.21709ms
> 2017/11/03 14:54:52 60.293962ms
> 2017/11/03 14:54:53 28.195748ms
> 2017/11/03 14:54:53 67.271545ms
> 2017/11/03 14:54:53 35.182174ms
> 2017/11/03 14:54:53 3.112353ms
> 2017/11/03 14:54:54 42.200138ms
> 2017/11/03 14:54:54 10.104631ms
> 2017/11/03 14:54:54 49.172548ms
> 
> Busy loop with With wait_for_incoming_packet set to 0
> # ./ntop
> 2017/11/03 14:53:54 Opening PF_RING capture zc:eth2@0
> 2017/11/03 14:53:54 112.808µs
> 2017/11/03 14:53:54 101.491µs
> 2017/11/03 14:53:54 105.697µs
> 2017/11/03 14:53:55 116.839µs
> 2017/11/03 14:53:55 92.49µs
> 2017/11/03 14:53:55 116.731µs
> 2017/11/03 14:53:55 101.466µs
> 2017/11/03 14:53:56 135.863µs
> 2017/11/03 14:53:56 112.909µs
> 2017/11/03 14:53:56 99.826µs
> 2017/11/03 14:53:56 111.789µs
> 2017/11/03 14:53:57 137.237µs
> 2017/11/03 14:53:57 191.66µs
> 2017/11/03 14:53:57 97.025µs
> 2017/11/03 14:53:57 100.77µs
> 2017/11/03 14:53:58 122.966µs
> 2017/11/03 14:53:58 91.301µs
> 2017/11/03 14:53:58 98.335µs
> 2017/11/03 14:53:58 80.595µs
> 
> 
> # ping 176.31.237.4
> PING 176.31.237.4 (176.31.237.4) 56(84) bytes of
> data.
> 64 bytes from 176.31.237.4: icmp_seq=1 ttl=60 time=0.185 ms
> 64
> bytes from 176.31.237.4: icmp_seq=2 ttl=60 time=0.171 ms
> 64 bytes from
> 176.31.237.4: icmp_seq=3 ttl=60 time=0.198 ms
> 64 bytes from
> 176.31.237.4: icmp_seq=4 ttl=60 time=0.203 ms
> 64 bytes from
> 176.31.237.4: icmp_seq=5 ttl=60 time=0.201 ms
> 64 bytes from
> 176.31.237.4: icmp_seq=6 ttl=60 time=0.191 ms
> 64 bytes from
> 176.31.237.4: icmp_seq=7 ttl=60 time=0.215 ms
> 64 bytes from
> 176.31.237.4: icmp_seq=8 ttl=60 time=0.172 ms
> 64 bytes from
> 176.31.237.4: icmp_seq=9 ttl=60 time=0.205 ms
> ^C
> --- 176.31.237.4 ping
> statistics ---
> 9 packets transmitted, 9 received, 0% packet loss, time
> 7996ms
> rtt min/avg/max/mdev = 0.171/0.193/0.215/0.019 ms
> 
> 
> On Mon, 2017-10-30 at 17:25 +0100, Charles-Antoine Mathieu wrote:
>> I tried a lot of different configurations but could not figure out
>> why
>> I get those weird latencies by taking the time right after send ans
>> recv calls.
>> 
>> I'm reduced the code to the minimum and put it in this repository if
>> you want to take a quick look.
>> https://github.com/camathieu/pfring_latency#pfring_latency
>> 
>> Now, I wonder if there is some tweaks in the module or driver
>> parameter
>> that I overlooked or if it could be related to golang because I'm out
>> of ideas ^^.
>> 
>> On Fri, 2017-10-27 at 10:18 +0200, Charles-Antoine Mathieu wrote:
>>> 
>>> Yes :
>>> 
>>> https://github.com/google/gopacket/blob/master/pfring/pfring.go#L24
>>> 7
>>> 
>>> On Thu, 2017-10-26 at 19:14 +0200, Alfredo Cardigliano wrote:
>>>> 
>>>> 
>>>> Hi
>>>> are you setting the flush flag to 1 when calling pfring_send()?
>>>> 
>>>> Alfredo
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 26 Oct 2017, at 18:42, Charles-Antoine Mathieu <charles-
>>>>> antoine.
>>>>> [email protected]> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I'm trying to implement that, but my results looks odd. I'm
>>>>> trying
>>>>> to
>>>>> ping a bunch of ~20 hosts with a latency of ~1.77 ms every 5
>>>>> seconds.
>>>>> 
>>>>> I capture time right after pfring_send and pfring_recv. For
>>>>> every
>>>>> batch
>>>>> I get around the same latency for every host but the latency
>>>>> range
>>>>> from
>>>>> 1ms to 300ms.
>>>>> 
>>>>> 37.187.9.32 : 11.532119ms
>>>>> 37.187.9.245 : 11.54512ms
>>>>> 37.187.9.124 : 11.525933ms
>>>>> ... 5 sec later the next batch ...
>>>>> 37.187.9.14 : 107.540483ms
>>>>> 37.187.9.17 : 107.519064ms
>>>>> 37.187.9.32 : 107.505375ms
>>>>> 
>>>>> I wonder if you are aware of some kind of buffering that might
>>>>> happen
>>>>> in the process to yield such results.
>>>>> 
>>>>> The ring is opened in ZC mode
>>>>> NIC model is Intel Corporation 82599ES 10-Gigabit SFI/SFP+
>>>>> Network
>>>>> Connection (rev 01)
>>>>> 
>>>>> I'm using gopacket and ARISTA's nanotime package to capture a
>>>>> monotonic
>>>>> time which rely upon CLOCK_MONOTONIC, it seems more reliable
>>>>> and
>>>>> lightweight that time.Now() to me.
>>>>> https://github.com/aristanetworks/goarista/blob/master/monotime
>>>>> /n
>>>>> an
>>>>> otim
>>>>> e.go
>>>>> 
>>>>> On Fri, 2017-10-06 at 16:38 +0200, Alfredo Cardigliano wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Hi
>>>>>> in ZC mode kernel is bypassed, thus you should send the
>>>>>> packet
>>>>>> and
>>>>>> call clock_gettime()
>>>>>> immediately after in order to compute latency (the same
>>>>>> function
>>>>>> is
>>>>>> used for RX in this case).
>>>>>> 
>>>>>> Alfredo
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 6 Oct 2017, at 16:34, Charles-Antoine Mathieu <charles-
>>>>>>> antoine.m
>>>>>>> [email protected]> wrote:
>>>>>>> 
>>>>>>> Hello,
>>>>>>> 
>>>>>>> I have a process that sends and receive ICMP packets using
>>>>>>> PF_RING.
>>>>>>> 
>>>>>>> I'd like to capture send and received packets to be able to
>>>>>>> compute
>>>>>>> the
>>>>>>> latency. When I'm not in ZC mode I get the send and the
>>>>>>> received
>>>>>>> packet
>>>>>>> in the capture. However in ZC mode I only get the received
>>>>>>> packets
>>>>>>> in
>>>>>>> the capture.
>>>>>>> 
>>>>>>> Is there a way go get the same behaviour in ZC mode ?
>>>>>>> _______________________________________________
>>>>>>> Ntop mailing list
>>>>>>> [email protected]
>>>>>>> http://listgateway.unipi.it/mailman/listinfo/ntop
>>>>>> _______________________________________________
>>>>>> Ntop mailing list
>>>>>> [email protected]
>>>>>> http://listgateway.unipi.it/mailman/listinfo/ntop
>>>>> _______________________________________________
>>>>> Ntop mailing list
>>>>> [email protected]
>>>>> http://listgateway.unipi.it/mailman/listinfo/ntop
>>>> _______________________________________________
>>>> Ntop mailing list
>>>> [email protected]
>>>> http://listgateway.unipi.it/mailman/listinfo/ntop
>>> _______________________________________________
>>> Ntop mailing list
>>> [email protected]
>>> http://listgateway.unipi.it/mailman/listinfo/ntop
>> _______________________________________________
>> Ntop mailing list
>> [email protected]
>> http://listgateway.unipi.it/mailman/listinfo/ntop
> _______________________________________________
> Ntop mailing list
> [email protected]
> http://listgateway.unipi.it/mailman/listinfo/ntop

_______________________________________________
Ntop mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop
signature.asc (application/pgp-signature, 833 B)