On 10/05/2018 06:00 AM, Stephen Suryaputra wrote:
> On Thu, Oct 4, 2018 at 4:42 PM Eric Dumazet <eric.duma...@gmail.com> wrote:
>>
>> How have you decided some counters can be 'slow' and other 'fast' ?
>>
>> I can tell you I see many ultra-fast candidates in your 'slow' list :/
>
> Based on what others have categorized based on what's in the code and
> IMHO they make sense:
Well, you better test, because you missed a few counters that are hit hard in
the fast
path for normal (non DDOS) packets.
>
> enum
> {
> IPSTATS_MIB_NUM = 0,
> /* frequently written fields in fast path, kept in same cache line */
> IPSTATS_MIB_INPKTS, /* InReceives */
> IPSTATS_MIB_INOCTETS, /* InOctets */
> IPSTATS_MIB_INDELIVERS, /* InDelivers */
> IPSTATS_MIB_OUTFORWDATAGRAMS, /* OutForwDatagrams */
> IPSTATS_MIB_OUTPKTS, /* OutRequests */
> IPSTATS_MIB_OUTOCTETS, /* OutOctets */
> /* other fields */
> IPSTATS_MIB_INHDRERRORS, /* InHdrErrors */
> ...
> __IPSTATS_MIB_MAX
> };
>
>>
>> Also think about DDOS.
>>
>> After your patch, all these 'wrong packets' will incur an expensive
>> operation on a shared and highly contented cache line,
>> effectively making the attack easier to conduct.
>>
>
> I agree about it is becoming more expensive to hit the slow counters
> due to the check whether they are enabled or not.
What do you mean ?
The real cost is having dozens of cpus updating the same cache lines if the
SNMP counter
is an atomic instead of per-cpu counters.
Make sure to test this on a configuration with 16 (or more) RX queues,
and cpus handling NIC IRQS spread on multiple NUMA nodes.
