From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f195.google.com (mail-pg1-f195.google.com [209.85.215.195]) by dpdk.org (Postfix) with ESMTP id 0CBBC1B453 for ; Sat, 16 Feb 2019 01:37:05 +0100 (CET) Received: by mail-pg1-f195.google.com with SMTP id h11so3218006pgl.0 for ; Fri, 15 Feb 2019 16:37:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=EB1wpbosQiKvv6k5eVsShPWPIqVhF3mgvCMe63AMn0Q=; b=0IcOREm+rOIk1Jr3yJ778RKCWresCTh7w4FYPumQaxU/xFLwgyD3SzR0rQDBP+tfaU C7JCyDkdoDSZSPw8wLh84kEP1mc5KNY+VrSsRsCM4sQBbT9yn40A3Av4pXXmmqBPpDac kF9885uQFX0IVheltagmx4HFrwQpeNzCgoEuQWOir3w6euiMxwBHnJkvrjtebPimSfYN 0btWTRGXaJ1yvpJdAVEBw+StxoDJYv4YSczfwU5UWAVJgpD81P4CSn1FyQzhIJeos00+ Jni5vtu7Fba/y5TmZGuAwb1MkXUgvPzkJDHeVUS/j/LJug7e+yHChp0LeK49W10ps7F/ VsZA== 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:mime-version:content-transfer-encoding; bh=EB1wpbosQiKvv6k5eVsShPWPIqVhF3mgvCMe63AMn0Q=; b=O7NxFeBctHBUrSyUTrB4CNEdBHFXr37xKnAb/ATc0+i9YigNm39dpljMtOOneISYPP qTWKvI5GFb9JvJEzlV81AZcXJ7g5Fzj6wjTAqALnwDmy+z7ufKDp5kb2tmmhp3yY229/ QrC0JKaM17YtNBeDSPUzu4cdLXjC7UAphDBO7mYIp5zwt2waROmFA/WMY/LupJ9QK/5i 0bq88/uCNu2Y3iXfGxGfxBw1l3IO16o6lzGwCBQthjWN1YxTfQhu9gvmlTmyEW8g0qdc zhBq42YxbmFUmWBeUolMr3MY8n5EQg7hxJffUZDCUEv8qrXAzSpL6bsvKkPAGM9FPsCS ZovA== X-Gm-Message-State: AHQUAuZzZ/ZZyZkHaOnqvBd6OC3pzJKJIUv0tuBVqNbkW8ATpuILtWf8 ti5eNuBN9QZ6bnPTnqe+g7ffig== X-Google-Smtp-Source: AHgI3IZQNtDCxz2fDhNfStv59Dcyy1gM6LquoPHQmzdN2phApaQszyXOsDhgFTLrziUv7rwt5A3f6Q== X-Received: by 2002:a63:c40a:: with SMTP id h10mr7893646pgd.131.1550277424956; Fri, 15 Feb 2019 16:37:04 -0800 (PST) Received: from shemminger-XPS-13-9360 (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id n19sm6333663pfg.67.2019.02.15.16.37.04 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 15 Feb 2019 16:37:04 -0800 (PST) Date: Fri, 15 Feb 2019 16:37:00 -0800 From: Stephen Hemminger To: Thomas Monjalon Cc: "Ananyev, Konstantin" , David Marchand , "Richardson, Bruce" , "dev@dpdk.org" , "Lu, Wenzhuo" , "Wu, Jingjing" , "Iremonger, Bernard" , Maxime Coquelin , "Yigit, Ferruh" , Andrew Rybchenko , "Wiles, Keith" Message-ID: <20190215163700.1b04ba6f@shemminger-XPS-13-9360> In-Reply-To: <6177115.1iB7W0vHcD@xps> References: <1550158972-21895-1-git-send-email-david.marchand@redhat.com> <2601191342CEEE43887BDE71AB977258012413A4D8@irsmsx105.ger.corp.intel.com> <6177115.1iB7W0vHcD@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 3/5] app/testpmd: add missing transmit errors stats X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2019 00:37:06 -0000 On Fri, 15 Feb 2019 20:38:59 +0100 Thomas Monjalon wrote: > 15/02/2019 19:42, Ananyev, Konstantin: > > >>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of David Marchand > > >>> I am also for option 2 especially because of this. > > >>> A driver that refuses a packet for reason X (which is a limitation, or an > > >>> incorrect config or whatever that is not a transient condition) but gives > > >>> it back to the application is a bad driver. > > > > >>Why? What.s wrong to leave it to the upper layer to decide what to > > >>do with the packets that can't be sent (by one reason or another)? > > > > >How does the upper layer know if this is a transient state or something that can't be resolved? > > > > Via rte_errno, for example. > > rte_errno is not a result per packet. > I think it is better to "eat" the packet > as it is done for those transmitted to the HW. > > First off rte_errno doesn't work for a burst API. IMHO (which matches /2) all drivers should only increment oerrors for something for a packet which it could not transmit because of hardware condition (link down etc) or mbuf which has parameters which can not be handled. In either case, the packet must be dropped by driver and oerrors incremented. The driver should also maintain internal stats (available by xstats) for any conditions like this. When no tx descriptors are available, the driver must not increment any counter and return partial success to the application. If application then wants to do back pressure or drop it should keep its own statistics. This is close to the original model in the Intel drivers, and matches what BSD and Linux do on the OS level for drivers. Like many driver assumptions the corner cases were not explicitly documented and new drivers probably don't follow the same pattern.