From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B36C4C433ED for ; Thu, 8 Apr 2021 18:20:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 745706113B for ; Thu, 8 Apr 2021 18:20:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232416AbhDHSVK (ORCPT ); Thu, 8 Apr 2021 14:21:10 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:43761 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232287AbhDHSVJ (ORCPT ); Thu, 8 Apr 2021 14:21:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617906057; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pT8CvBydo1jfCeR1V2jxAI3YYezDelf8vI+96e7B6ik=; b=iwdLezoScy2ExrRQe3+vSN5SGlK1i5WwEdM+E49UWcV3ewiDJf4yTMySdvaG0f1DCqqAUH dtQZ7Tr64ZNQ3TH2HjLkqVgvNjcesj79vSa2BrZ64NNZqPo0mC3HyK8WrDPLMz2kcKXLtm 1lhkfOMS+ym9CdUAnkTR0Avd2QlJsJw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-423-UbNX9G3qNWaA-GMYYUqGtw-1; Thu, 08 Apr 2021 14:20:55 -0400 X-MC-Unique: UbNX9G3qNWaA-GMYYUqGtw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7D7CB8030C4; Thu, 8 Apr 2021 18:20:53 +0000 (UTC) Received: from carbon (unknown [10.36.110.19]) by smtp.corp.redhat.com (Postfix) with ESMTP id 85D045D9DC; Thu, 8 Apr 2021 18:20:42 +0000 (UTC) Date: Thu, 8 Apr 2021 20:20:41 +0200 From: Jesper Dangaard Brouer To: Lorenzo Bianconi Cc: Song Liu , Lorenzo Bianconi , bpf , Networking , "David S . Miller" , Jakub Kicinski , Alexei Starovoitov , Daniel Borkmann , brouer@redhat.com Subject: Re: [PATCH bpf-next] cpumap: bulk skb using netif_receive_skb_list Message-ID: <20210408202041.720ec643@carbon> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, 8 Apr 2021 12:10:19 +0200 Lorenzo Bianconi wrote: > > On Thu, Apr 1, 2021 at 9:49 AM Lorenzo Bianconi wrote: > > > > > > > On Thu, Apr 1, 2021 at 1:57 AM Lorenzo Bianconi wrote: > > > > > > > > > > > [...] > > > > > > > > - /* Inject into network stack */ > > > > > - ret = netif_receive_skb_core(skb); > > > > > - if (ret == NET_RX_DROP) > > > > > - drops++; > > > > > > > > I guess we stop tracking "drops" with this patch? > > > > > > > > Thanks, > > > > Song > > > > > > Hi Song, > > > > > > we do not report the packets dropped by the stack but we still count the drops > > > in the cpumap. If you think they are really important I guess we can change > > > return value of netif_receive_skb_list returning the dropped packets or > > > similar. What do you think? > > > > I think we shouldn't silently change the behavior of the tracepoint below: > > > > trace_xdp_cpumap_kthread(rcpu->map_id, n, drops, sched, &stats); > > > > Returning dropped packets from netif_receive_skb_list() sounds good to me. > > Hi Song, > > I reviewed the netif_receive_skb_list() and I guess the code needed to count > number of dropped frames is a bit intrusive and we need to add some checks > in the hot path. > Moreover the dropped frames are already accounted in the networking stack > (e.g. mib counters for the ip traffic). > Since drop counter is just exported in a tracepoint in cpu_map_kthread_run, > I guess we can just not count dropped packets in the networking stack here > and rely on the mib counters. What do you think? > > @Jesper: since you added the original code, what do you think about it? I'm actually fine with not counting the drops in the tracepoint. As you say it is already accounted elsewere in MIB counters for the network stack. Which is actually better, as having this drop counter in tracepoint have confused people before (when using xdp_redirect_cpu). If they instead looked at the MIB counters, it should be easier to understand why the drop happens. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer