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=-1.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 E03DAC282CC for ; Wed, 6 Feb 2019 15:52:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id ACA0F218AD for ; Wed, 6 Feb 2019 15:52:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="aVnQaHat" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729941AbfBFPwb (ORCPT ); Wed, 6 Feb 2019 10:52:31 -0500 Received: from mail-pl1-f193.google.com ([209.85.214.193]:40975 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729145AbfBFPwb (ORCPT ); Wed, 6 Feb 2019 10:52:31 -0500 Received: by mail-pl1-f193.google.com with SMTP id k15so3251281pls.8 for ; Wed, 06 Feb 2019 07:52:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=OOi2X2VlcAGQ1LVhBiWepuFlGF4jRlK5v/DjfHfY9cw=; b=aVnQaHatnPFuxM0Q4C8VaJKP3LtbPbg5WpuC49JZTOn2XdsnUe9vKVsl7RC2Cnt0v4 HAmSj/64cTTEkHE2FjnHdDS7UF3J3FvluctNTCXRVpMvGPCxoPNXmKpMO6iHq4fYJKSa zPJJ5nDXqr/m2sypVF1b+WKWReZY7obCNUnAozsU/owILumg6efJ6gscUjAt8U751nvF b6+mtdqepv+Gb1a6cGF3tC1a7yNkh0xnCEoFllaf1zQIhmt1a4iEXbf144sn1Tpb0aKC CjPo6/TFtofDOleNfbdAV0jrX2A4FwCN2E8bCq/t1wHracsDlAiyrL8zcgEpG113sQzp kRDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=OOi2X2VlcAGQ1LVhBiWepuFlGF4jRlK5v/DjfHfY9cw=; b=nIeNHiyD1RD8JLYmMJBnBcb+5otxAyqwyRJ7+f0SGvqKAQSO1XjQJzypw/NtVvt79W EcaZPX6ez3iCwiz5r0OLwEsuwDy/EuRyEKtK3YogY1xqcxScN8o8LL/cxpRpIKKGM5sa 6IfBLqpS4EQDGCecfYlLk2vzn0EkrCianD0m8idbM0Y0ePbQt2y3QDC3kepxAngGjfRI jXn3vHOnyJqgZaozgBikVmC3KVlOJJz7R+hbg5wq23BTKNAiCQCoUwhockFqHaBaCaX2 w3IytoB8vj7KA2QO63l22N7j/DQ6aCX5uxQuGhEM9meWcazHWbue+g5hkdCuyKfwRdba Y5Kg== X-Gm-Message-State: AHQUAuYbU410Ep/E6j/dC40HD8CjrF6DyViCXs3U7T/emkCaCV25q0c3 3oX0wJuTm9I3vQ8M2k7MKzV3jg== X-Google-Smtp-Source: AHgI3IYN3KIPaFK/MhIJBdoMcDohJRsdMetg2FjDUVDVheDl86pMuwJoGKQYkoFslIdDAYt5M+re0w== X-Received: by 2002:a17:902:9687:: with SMTP id n7mr11079321plp.94.1549468350203; Wed, 06 Feb 2019 07:52:30 -0800 (PST) Received: from cakuba.netronome.com ([172.85.50.179]) by smtp.gmail.com with ESMTPSA id 84sm8292668pfk.134.2019.02.06.07.52.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 06 Feb 2019 07:52:30 -0800 (PST) Date: Wed, 6 Feb 2019 07:52:16 -0800 From: Jakub Kicinski To: Jesper Dangaard Brouer Cc: Saeed Mahameed , "dsahern@gmail.com" , "thoiland@redhat.com" , "virtualization@lists.linux-foundation.org" , "borkmann@iogearbox.net" , Tariq Toukan , "john.fastabend@gmail.com" , "mst@redhat.com" , "netdev@vger.kernel.org" , "jasowang@redhat.com" , "davem@davemloft.net" , "makita.toshiaki@lab.ntt.co.jp" Subject: Re: [PATCH net] virtio_net: Account for tx bytes and packets on sending xdp_frames Message-ID: <20190206075216.22b66d58@cakuba.netronome.com> In-Reply-To: <20190206144814.46996933@carbon> References: <1548934830-2389-1-git-send-email-makita.toshiaki@lab.ntt.co.jp> <20190131101516-mutt-send-email-mst@kernel.org> <20190131.094523.2248120325911339180.davem@davemloft.net> <20190131211555.3b15c81f@carbon> <20190204125307.08492005@redhat.com> <140ecbe1e25f54f90d859cc696c4119aa96bc6eb.camel@mellanox.com> <20190206144814.46996933@carbon> Organization: Netronome Systems, Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, 6 Feb 2019 14:48:14 +0100, Jesper Dangaard Brouer wrote: > On Wed, 6 Feb 2019 00:06:33 +0000 > Saeed Mahameed wrote: > > > 3) Unrelated, In non XDP case, if skb allocation fails or driver fails > > to pass the skb up to the stack for somereason, should the driver > > increase rx packets ? IMHO the answer should be yes if we want to have > > similar behavior between XDP and non XDP cases. > > I don't think "skb allocation fails" should increase rx packets > counter. The difference is that these events are outside sysadm/users > control, and is an error detected inside the driver. The XDP program > takes a policy choice to XDP_DROP a packet, which can be accounted > inside the XDP prog (as the samples show) or as we also discuss via a > more generic XDP-action counters. FWIW that's my understanding as well. My understanding of Linux stats is that they are incrementing one counter per packet. I.e. in RX direction success packets are those given to the stack, and for TX those given to the hardware. Standards (IETF/IEEE) usually count stats on the same layer boundary, but I think software generally counts when it's done with the packet. I haven't seen it documented anywhere, yet. I have tried to document it in the docs of the recent RFC: https://patchwork.ozlabs.org/patch/1032332/ Incidentally XDP_DROP may have been better named XDP_DISCARD from stats perspective ;)