From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id AA937A3160 for ; Fri, 11 Oct 2019 19:13:27 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E67531EB5A; Fri, 11 Oct 2019 19:13:25 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id BB7D11EB4F; Fri, 11 Oct 2019 19:13:23 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2019 10:13:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,284,1566889200"; d="scan'208";a="206510570" Received: from fmusates-mobl1.ger.corp.intel.com (HELO [10.237.221.119]) ([10.237.221.119]) by orsmga002.jf.intel.com with ESMTP; 11 Oct 2019 10:13:21 -0700 To: Stephen Hemminger Cc: dev@dpdk.org, "John W. Linville" , stable@dpdk.org, ciwillia@brocade.com References: <1570634949-26819-1-git-send-email-flavia.musatescu@intel.com> <1570728870-26668-1-git-send-email-flavia.musatescu@intel.com> <20191010113533.43333afe@hermes.lan> From: "Musatescu, Flavia" Message-ID: <62ba077a-e200-cbb7-81a6-dca8f7571d98@intel.com> Date: Fri, 11 Oct 2019 18:13:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20191010113533.43333afe@hermes.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH v2] net/af_packet: improve Tx statistics accuracy 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/10/2019 19:35, Stephen Hemminger wrote: > On Thu, 10 Oct 2019 18:34:30 +0100 > Flavia Musatescu wrote: > >> When sendto call fails and ENOBUFS error is being set some of the >> packets are actually successfully transmitted. There is no available >> count of those packets, so in order to make the statistics more >> accurate, all the previously enqueued packets will be considered >> successful, even though this is not entirely correct. >> >> Before: >> testpmd Tx statistics: >> TX-packets: 7529062 TX-errors: 3702150 TX-bytes: 451743720 >> pktgen Rx statistics: >> Total Rx Pkts: 10700700 >> >> After: >> testpmd TX statistics: >> TX-packets: 11510625 TX-errors: 0 TX-bytes: 690637500 >> pktgen Rx statistics: >> Total Rx Pkts: 10974307 >> >> Fixes: 74b7fc0a0ff1 ("net/af_packet: fix packet bytes counting") >> Cc: ciwillia@brocade.com >> Cc: stable@dpdk.org >> >> Signed-off-by: Flavia Musatescu >> >> --- >> v2: >> * Changed the comment >> --- >> drivers/net/af_packet/rte_eth_af_packet.c | 8 ++++++-- >> 1 file changed, 6 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/net/af_packet/rte_eth_af_packet.c b/drivers/net/af_packet/rte_eth_af_packet.c >> index 6df09f2..df281bf 100644 >> --- a/drivers/net/af_packet/rte_eth_af_packet.c >> +++ b/drivers/net/af_packet/rte_eth_af_packet.c >> @@ -244,8 +244,12 @@ eth_af_packet_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts) >> } >> >> /* kick-off transmits */ >> - if (sendto(pkt_q->sockfd, NULL, 0, MSG_DONTWAIT, NULL, 0) == -1) { >> - /* error sending -- no packets transmitted */ >> + if (sendto(pkt_q->sockfd, NULL, 0, MSG_DONTWAIT, NULL, 0) == -1 && >> + errno != ENOBUFS) { >> + /* >> + * In case of a ENOBUFS error all of the enqueued packets will >> + * be considered successful even though only some are sent. >> + */ >> num_tx = 0; >> num_tx_bytes = 0; >> } > What about EINTR or EAGAIN? Hi Stephen, I agree with EAGAIN error case as I was able to test this scenario and check the statistics. Can we get an EINTR error in case of a nonblocking operation (MSG_DONTWAIT flag is being used)? Is this a common situation and will the gain justify the cost of an additional check? Do you have any suggestions for how I could test this scenario? Thanks, Flavia