Hi Chandrika sorry for late reply, I’ve been busy with other activities, the irq rate depends on the way the application handles poll/select, the traffic rate, and other factors. This said, I was not able to reproduce the rate you are describing, probably it also depends on the traffic you have or other conditions.
Alfredo > On 9 Sep 2019, at 05:17, Chandrika Gautam <[email protected]> > wrote: > > Hi Alfredo, > > Have you been able to look at this further ??? > > Any feedback on ksoftirq reaching 100% continuously. > > Regards, > Chandrika > > Sent from my iPhone > > On Sep 4, 2019, at 8:11 PM, Alfredo Cardigliano <[email protected] > <mailto:[email protected]>> wrote: > >> Hi Chandrika >> this is definitely strange: please note that with standard drivers >> interrupts >> are not controlled by PF_RING as they are managed by the driver itself.. >> this is interesting, I will take a look asap. >> >> Alfredo >> >>> On 4 Sep 2019, at 14:15, Chandrika Gautam <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> That’s the secondary issue which we will focus later on. >>> >>> So let me rephrase the problem statements - >>> 1. This does not involve zc! Problem 1- When we are using our software >>> integrated with pfring 7.5.0, we do not see counters incremented in cat >>> /proc/interrupts/ for the interface from which we are reading the packets. >>> We are using standard i40e. driver on rhel 7.6 and have reduced the number >>> of queues of this card interfaces to 4 and set the smp affinity explicitly. >>> Second problem - we can see ksoftirq for the assigned cores taking 100% of >>> CPU due to which we are observing drop at the interface as well. >>> When we run tcpdump on the same interface, we can see the interrupts counts >>> incrementing using above same command. >>> >>> 2- above observation is same when we deploy zc compiled i40e driver ; >>> >>> Will there be no interrupts with i40e driver when used with pf_ring ?? >>> >>> Regards, >>> Chandrika >>> Sent from my iPhone >>> >>> On Sep 4, 2019, at 1:04 PM, Alfredo Cardigliano <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> Hi Chandrika >>>> are you observing better performance with ixgbe? Please note that ixgbe >>>> has a bigger buffer in the card, >>>> this could explain better performance in case of high traffic rate (what >>>> is the pps rate in this case?) >>>> >>>> Alfredo >>>> >>>>> On 28 Aug 2019, at 12:56, Chandrika Gautam <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Hi Alfredo, >>>>> >>>>> Interrupts are not seen either with standard driver or with the zc >>>>> compiled i40e driver as well. >>>>> >>>>> What we do in our application is - >>>>> We load zc compiled i40e driver and put a zc license on that interface >>>>> but we do not open device using zc: prefix. >>>>> Using this we have observed better performAnce in our application when >>>>> used with ixgbe driver. >>>>> >>>>> Regards, >>>>> Chandrika >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Aug 28, 2019, at 12:58 PM, Alfredo Cardigliano <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>>> Hi Chandrika >>>>>> are you using the i40e-zc driver or the standard driver? >>>>>> Please note that ZC enables interrupts only when required for >>>>>> performance reason, >>>>>> for example some libpcap-based applications require interrupts as they >>>>>> use poll/select, >>>>>> instead many pf_ring-based application do not use interrupts at all >>>>>> (they do active polling). >>>>>> >>>>>> Alfredo >>>>>> >>>>>>> On 28 Aug 2019, at 08:59, Chandrika Gautam >>>>>>> <[email protected] <mailto:[email protected]>> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Hi Team, >>>>>>> >>>>>>> >>>>>>> >>>>>>> We have compiled our software with PF_RING 7.5.0 which reads from an >>>>>>> interface on i40e driver. >>>>>>> >>>>>>> Whenever we start our software, it process the traffic received on the >>>>>>> interface but no interrupts are seen. >>>>>>> >>>>>>> Whenever we start tcpdump on the same interface, then interrupts can be >>>>>>> seen. >>>>>>> >>>>>>> Can you please help to validate this behavior. Is it expected behavior >>>>>>> ? We need to validate that the interrupts are coming on the cores to >>>>>>> which we have set the affnity. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Chandrika >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ntop-misc mailing list >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>>>>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >>>>>> _______________________________________________ >>>>>> Ntop-misc mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>>>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc>_______________________________________________ >>>>> Ntop-misc mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >>>> _______________________________________________ >>>> Ntop-misc mailing list >>>> [email protected] <mailto:[email protected]> >>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc>_______________________________________________ >>> Ntop-misc mailing list >>> [email protected] <mailto:[email protected]> >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >> _______________________________________________ >> Ntop-misc mailing list >> [email protected] <mailto:[email protected]> >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc>_______________________________________________ > 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
