From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH net-next,v2] IPv6 ifstats separation Date: Fri, 5 Oct 2018 06:13:39 -0700 Message-ID: References: <20181004190828.26536-1-ssuryaextr@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org To: Stephen Suryaputra , eric.dumazet@gmail.com Return-path: Received: from mail-pl1-f194.google.com ([209.85.214.194]:34254 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727733AbeJEUMV (ORCPT ); Fri, 5 Oct 2018 16:12:21 -0400 Received: by mail-pl1-f194.google.com with SMTP id f18-v6so6840974plr.1 for ; Fri, 05 Oct 2018 06:13:41 -0700 (PDT) In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 10/05/2018 06:00 AM, Stephen Suryaputra wrote: > On Thu, Oct 4, 2018 at 4:42 PM Eric Dumazet 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.