From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f53.google.com (mail-pl0-f53.google.com [209.85.160.53]) by dpdk.org (Postfix) with ESMTP id 5DD5C1B689 for ; Thu, 8 Feb 2018 18:32:35 +0100 (CET) Received: by mail-pl0-f53.google.com with SMTP id f4so154755plr.10 for ; Thu, 08 Feb 2018 09:32:35 -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=YSyvd11Z3zHpv0BfkYDgdMERi7aP2OSDRR6J/fg3O1A=; b=GseHBOgHIVU+snrDJyhAmveGlHGlHU/qAkhRUsOhZtCZhViy41wUU0OpYua4ByE2yB eGsvEjW3VsRs/WaUGNGIij2ZLx/anf4lp3AxLzB36C3aVNLKZC2rx8JRJaY2aadDB7+z bJamJ4jawFEjlJAE9dIQDoJOO+ZLvrXqjQ97OsstdrS8EOH8BL8qTrcHTFKI9iniS3+w DD0/fAesHLxizqmFIT4nNjEhP7Il9Pbz9T3klbK9M5dmz5c7RQrnhe7Gbg5ZwIpJxGeK yZM5XxgKU7d5gMpBEPd2cXGfvfM8EK3q8xMc+6W1nt0IhZtfgFJLWL6VA/AUu1NviD0d K/5Q== 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=YSyvd11Z3zHpv0BfkYDgdMERi7aP2OSDRR6J/fg3O1A=; b=p4i4rp9t7r+f5kOYmMMoep/DsyE06kjLwz1w/GJHaX6Z4tj9G+oiYUetKpabErN57i hwMkvnUxBy4QDZ3AsUoQ0GEOFIChJGA3QBRXJChS2LswJsav5thXiEH6RtbfFR7TqXD6 uAp3/iIA+QU6Ty8nJ3YBVjCyjitWQNOJWxRMy4apGuFVAnY9xiGeTjzDbhGo1e7PFC7B CoIsQeehurcbmxnR7xBy1kAWb8zTwIsXzagNiOQCxAFGeHw5gSnp9d3N0YY0BvyE4H3e y8T2mzeboP3/CMaI0Y4ogsJypp2pvKSwfZuglTjavbFohnREb+x1Ixm9lDxWgnvAA2Dn iEow== X-Gm-Message-State: APf1xPBUbEOekY0yXhFMtmTJwKm1OjWSg2rKZQbQu0o+lr+hiZjVajdB Schr9ckbtPl2TkfiUvcNbxLdng== X-Google-Smtp-Source: AH8x226AbareKQnj/ZVkO9mx8++MAzMzxi/9S9oRqljdcQETdvza8hPHSwXDMk+nmfxxP5Kivch6Lg== X-Received: by 2002:a17:902:3381:: with SMTP id b1-v6mr1365269plc.20.1518111154451; Thu, 08 Feb 2018 09:32:34 -0800 (PST) Received: from xeon-e3 (204-195-71-95.wavecable.com. [204.195.71.95]) by smtp.gmail.com with ESMTPSA id h8sm2004420pfk.121.2018.02.08.09.32.33 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 08 Feb 2018 09:32:34 -0800 (PST) Date: Thu, 8 Feb 2018 09:32:26 -0800 From: Stephen Hemminger To: Matthew Coppola Cc: users@dpdk.org Message-ID: <20180208093226.20f2159d@xeon-e3> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-users] i40e VF Rx/Tx CRC Bytes Discrepancy X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 17:32:35 -0000 On Thu, 8 Feb 2018 11:52:55 -0500 Matthew Coppola wrote: > Hi, > > I am noticing a discrepancy in the Rx/Tx Byte counters when using the > i40e driver as a virtual function. Specifically I am observing that > the Rx bytes are 4 bytes per packet larger than the Tx Bytes. > > My application is transmitting a packet and then receiving the same > packet back (in a service function chaining application). I verified > that the packets being transmitted and received were the same by > capturing on the interfaces using pdump and analyzing the output in > Wireshark. > > I believe the discrepancy comes from correcting for the Ethernet FCS. > I see that in i40e_ethdev.c the CRC bytes are corrected for in the > i40e_update_vsi_stats() and i40e_read_stats_registers() functions by > using the following correction (see below). Note the left-hand side > changes slightly depending on the specific function. > > pf->internal_stats.rx_bytes -= (pf->internal_stats.rx_unicast + > pf->internal_stats.rx_multicast + pf->internal_stats.rx_broadcast) * > ETHER_CRC_LEN; > > However I did not see this correction being used in the vf driver > (i40e_ethdev_vf.c). By adding a correction to i40evf_update_stats() as > follows I can reconcile the counters (and make them consistent with > the PF behavior). > > nes->rx_bytes -= (nes->rx_unicast + nes->rx_multicast + > nes->rx_broadcast) * ETHER_CRC_LEN; > > I would like to know if this is the expected behavior or if this is a > bug in the driver? If this is the expected behavior can you please > explain why I should expect a discrepancy between the Rx and Tx Byte > counters? > > > Some additional information: > > The application I am observing this behaviour in is using DPDK 17.08. > (However I don't see any fixes for this in version 17.11). > > The NIC is an Intel Corporation XL710/X710 Virtual Function (rev 02) > (output from lspci). > > > Thank you for your time, and please let me know if you require further > information. It is an Intel driver bug. All drivers must NOT include CRC bytes in counters. The DPDK (and Linux, BSD) convention is that byte counters do not include the CRC bytes. Note: Cisco routers include the CRC bytes; but everyone else does not.