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=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED 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 166ECC169C4 for ; Thu, 31 Jan 2019 20:16:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DF5AC20B1F for ; Thu, 31 Jan 2019 20:16:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727290AbfAaUQO (ORCPT ); Thu, 31 Jan 2019 15:16:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36448 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725802AbfAaUQO (ORCPT ); Thu, 31 Jan 2019 15:16:14 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 09F1BC0740E5; Thu, 31 Jan 2019 20:16:14 +0000 (UTC) Received: from carbon (ovpn-200-24.brq.redhat.com [10.40.200.24]) by smtp.corp.redhat.com (Postfix) with ESMTP id BB58662671; Thu, 31 Jan 2019 20:15:57 +0000 (UTC) Date: Thu, 31 Jan 2019 21:15:55 +0100 From: Jesper Dangaard Brouer To: David Miller Cc: mst@redhat.com, makita.toshiaki@lab.ntt.co.jp, jasowang@redhat.com, netdev@vger.kernel.org, virtualization@lists.linux-foundation.org, dsahern@gmail.com, hawk@kernel.org, Toke =?UTF-8?B?SMO4aWxhbmQtSsO4cmdl?= =?UTF-8?B?bnNlbg==?= Subject: Re: [PATCH net] virtio_net: Account for tx bytes and packets on sending xdp_frames Message-ID: <20190131211555.3b15c81f@carbon> In-Reply-To: <20190131.094523.2248120325911339180.davem@davemloft.net> 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> 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.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 31 Jan 2019 20:16:14 +0000 (UTC) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, 31 Jan 2019 09:45:23 -0800 (PST) David Miller wrote: > From: "Michael S. Tsirkin" > Date: Thu, 31 Jan 2019 10:25:17 -0500 > > > On Thu, Jan 31, 2019 at 08:40:30PM +0900, Toshiaki Makita wrote: > >> Previously virtnet_xdp_xmit() did not account for device tx counters, > >> which caused confusions. > >> To be consistent with SKBs, account them on freeing xdp_frames. > >> > >> Reported-by: David Ahern > >> Signed-off-by: Toshiaki Makita > > > > Well we count them on receive so I guess it makes sense for consistency > > > > Acked-by: Michael S. Tsirkin > > > > however, I really wonder whether adding more and more standard net stack > > things like this will end up costing most of XDP its speed. > > > > Should we instead make sure *not* to account XDP packets > > in any counters at all? XDP programs can use maps > > to do their own counting... > > This has been definitely a discussion point, and something we should > develop a clear, strong, policy on. > > 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. Performance wise, I don't see an issue. As updating these counters (packets and bytes) can be done as a bulk, either when driver NAPI RX func ends, or in TX DMA completion, like most drivers already do today. Further more, most drivers save this in per RX ring data-area, which are only summed when userspace read these. A separate question (and project) raised by David Ahern, was if we should have more detailed stats on the different XDP action return codes, as an easy means for sysadms to diagnose running XDP programs. That is something that require more discussions, as it can impact performance, and likely need to be opt-in. My opinion is yes we should do this for the sake of better User eXperience, BUT *only* if we can find a technical solution that does not hurt performance. --Jesper