And if I use the DNA drivers, then I guess NAPI is not involved, right? does it solve the problem?
On Thu, Nov 6, 2014 at 5:34 PM, Behrooz Shafiee <[email protected]> wrote: > Oh, I see. So I guess there is no way to stop NAPI thread from doing so? I > mean can't NAPI first check the ring then read from NIC? > > On Thu, Nov 6, 2014 at 5:28 PM, Alfredo Cardigliano <[email protected]> > wrote: > >> The NAPI thread is fast enough dequeueing from the NIC, but then it find >> the ring full and discards the packets (drops). >> >> Alfredo >> >> >> On 06 Nov 2014, at 23:25, Behrooz Shafiee <[email protected]> wrote: >> >> Hi Alfredo, >> >> I got your point but I don't understand the point of flow-control then! >> If I'm slow then pfring should slow down reading from NIC so NIC will >> notice the slowdown and sends a pause frame to the sender! Is there >> anything wrong with this logic? >> >> Thanks, >> >> On Thu, Nov 6, 2014 at 5:21 PM, Alfredo Cardigliano <[email protected] >> > wrote: >> >>> Hi Behrooz >>> your application is not fast enough dequeueing packets from the ring, >>> thus the drops. >>> You should try increasing the ring size (via insmod parameter), it helps >>> at least with spikes. >>> >>> Alfredo >>> >>> On 06 Nov 2014, at 23:01, Behrooz Shafiee <[email protected]> wrote: >>> >>> Hello Pavel, >>> >>> I'm not sure what do you mean but here is the output of to during run: >>> >>> top - 16:58:48 up 2:27, 8 users, load average: 0.25, 0.59, 0.81 >>> Tasks: 211 total, 4 running, 207 sleeping, 0 stopped, 0 zombie >>> %Cpu(s): 7.3 us, 7.1 sy, 0.0 ni, 84.6 id, 0.2 wa, 0.8 hi, 0.0 si, >>> 0.0 st >>> KiB Mem: 16334304 total, 5330972 used, 11003332 free, 112164 buffers >>> KiB Swap: 10207228 total, 0 used, 10207228 free. 2101892 cached >>> Mem >>> >>> I just realized that if I use pfring_stats when I receive the whole >>> 5000 packet the number of drops is 0 and when I don't receive all of them >>> the number of drops in the stats is around 2000-3000. >>> >>> On Thu, Nov 6, 2014 at 4:54 PM, Pavel Odintsov <[email protected] >>> > wrote: >>> >>>> Hello! >>>> >>>> Could you show top header and htop output? >>>> >>>> On Fri, Nov 7, 2014 at 12:48 AM, Behrooz Shafiee <[email protected]> >>>> wrote: >>>> > Hi everyone, >>>> > >>>> > I have implemented a small transmission protocol over pfring. I rely >>>> on the >>>> > Ethernet flow control meaning that I assume that in the same subnet I >>>> won't >>>> > loose any packet (I've no router so no queueing...). Everything was >>>> fine >>>> > until I did some stress test as follows. >>>> > I have a rcvThread which block on pfring_recv() function for each one >>>> > incoming packet and process it. I start a huge number of other >>>> threads(e.g >>>> > 5000) and each of them send a req to server through pfring_send (resp >>>> is one >>>> > packet). And then server replies with 5000 packet. most of the time i >>>> > receive the 5000 packets but sometimes I miss some of them. For >>>> example I >>>> > reach the line after pfring_recv() 4503 times. I thought this is due >>>> to >>>> > overflow in the NIC but I use intel pro which has both rx/tx flow >>>> pause >>>> > frame on and I actually used a packet dump tool (such as wireshark) >>>> and I >>>> > see the packets are being received by the NIC. So I assume they get >>>> lost >>>> > somewhere a long the line from NIC to pfring_recv() function. Can >>>> anyone >>>> > help me what might have gone wrong? >>>> > >>>> > PS. I use pfring in normal mode not DNA >>>> > >>>> > >>>> > Thanks, >>>> > -- >>>> > Behrooz >>>> > >>>> > _______________________________________________ >>>> > Ntop-misc mailing list >>>> > [email protected] >>>> > http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>> >>>> >>>> >>>> -- >>>> Sincerely yours, Pavel Odintsov >>>> _______________________________________________ >>>> Ntop-misc mailing list >>>> [email protected] >>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>> >>> >>> >>> >>> -- >>> Behrooz >>> _______________________________________________ >>> Ntop-misc mailing list >>> [email protected] >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>> >>> >>> >>> _______________________________________________ >>> Ntop-misc mailing list >>> [email protected] >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>> >> >> >> >> -- >> Behrooz >> _______________________________________________ >> Ntop-misc mailing list >> [email protected] >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> >> >> >> _______________________________________________ >> Ntop-misc mailing list >> [email protected] >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> > > > > -- > Behrooz > -- Behrooz
_______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
