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]> 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]> 
>> 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]> 
>>> 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]> 
>>>> 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]> 
>>>>> 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]> 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]
>>>>>> 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
>>> 
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> 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

Reply via email to