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=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 6044BC282C4 for ; Mon, 4 Feb 2019 11:53:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 32E372082F for ; Mon, 4 Feb 2019 11:53:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728273AbfBDLx2 (ORCPT ); Mon, 4 Feb 2019 06:53:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54286 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727555AbfBDLx2 (ORCPT ); Mon, 4 Feb 2019 06:53:28 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 899AB2D7E3; Mon, 4 Feb 2019 11:53:27 +0000 (UTC) Received: from localhost (ovpn-200-36.brq.redhat.com [10.40.200.36]) by smtp.corp.redhat.com (Postfix) with ESMTP id 881B0848DA; Mon, 4 Feb 2019 11:53:09 +0000 (UTC) Date: Mon, 4 Feb 2019 12:53:07 +0100 From: Jesper Dangaard Brouer To: David Ahern Cc: David Miller , mst@redhat.com, makita.toshiaki@lab.ntt.co.jp, jasowang@redhat.com, netdev@vger.kernel.org, virtualization@lists.linux-foundation.org, hawk@kernel.org, Toke =?UTF-8?B?SMO4aWxhbmQtSsO4cmdlbnNlbg==?= , brouer@redhat.com, Jakub Kicinski , John Fastabend , Daniel Borkmann , Saeed Mahameed , Tariq Toukan Subject: Re: [PATCH net] virtio_net: Account for tx bytes and packets on sending xdp_frames Message-ID: <20190204125307.08492005@redhat.com> In-Reply-To: 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> 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.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 04 Feb 2019 11:53:27 +0000 (UTC) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sat, 2 Feb 2019 14:27:26 -0700 David Ahern wrote: > On 1/31/19 1:15 PM, Jesper Dangaard Brouer wrote: > >> > >> David, Jesper, care to chime in where we ended up in that last thread > >> discussion this? > > > > IHMO packets RX and TX on a device need to be accounted, in standard > > counters, regardless of XDP. For XDP RX the packet is counted as RX, > > regardless if XDP choose to XDP_DROP. On XDP TX which is via > > XDP_REDIRECT or XDP_TX, the driver that transmit the packet need to > > account the packet in a TX counter (this if often delayed to DMA TX > > completion handling). We cannot break the expectation that RX and TX > > counter are visible to userspace stats tools. XDP should not make these > > packets invisible. > > Agreed. What I was pushing on that last thread was Rx, Tx and dropped > are all accounted by the driver in standard stats. Basically if the > driver touched it, the driver's counters should indicate that. Sound like we all agree (except with the dropped counter, see below). Do notice that mlx5 driver doesn't do this. It is actually rather confusing to use XDP on mlx5, as when XDP "consume" which include XDP_DROP, XDP_REDIRECT or XDP_TX, then the driver standard stats are not incremented... the packet is invisible to "ifconfig" stat based tools. > The push back was on dropped packets and whether that counter should be > bumped on XDP_DROP. My opinion is the XDP_DROP action should NOT increment the drivers drop counter. First of all the "dropped" counter is also use for other stuff, which will confuse that this counter express. Second, choosing XDP_DROP is a policy choice, it still means it was RX-ed at the driver level. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer