From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 2C94DDD2 for ; Tue, 24 Oct 2017 15:01:35 +0200 (CEST) Received: by mail-wm0-f52.google.com with SMTP id 78so13289419wmb.1 for ; Tue, 24 Oct 2017 06:01:35 -0700 (PDT) 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=DnZr2xfZoHuhJUTpZm26O1h/dUBSDiVxaE7fXnio7Js=; b=lnDOiLIODDLnpXDb93RWpNxPD/FoT+t0zNNSVMTnrIOgAapoZQLYbf8FatUnnUNS1S Wh4B3l9XLLIuscXWh7wUcrpEtdEnMs/VpxEbvA0yqEJx/79tJDpGVbLGvtUFWiK1hji9 qF36gR327D/Q0Tg7pzb4iwA6jxGSjUvu10QSIa/IgbIb2VIXSbtm7BNaZcO3Q8aph5H0 /5MuuTRgAYx67lt0Q373XG5McV58/ylU61fXSOCMpQ39Mr465o7EXolvmeKGh7GP6kn1 EYIsxugK5MLinRLaDJLDp4P4lvFu2R766iUklLwFOCpDFq9cHb0eST25dq5+L/AjUqAE L27w== 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=DnZr2xfZoHuhJUTpZm26O1h/dUBSDiVxaE7fXnio7Js=; b=b2iMXqdY1rHsanLVqxSBIVn6mvSzNfbZuBG4AYLHZH08iKT1IQSxWhe6FwWQOXon6H Qr2cy9owwiGRZxwusbvizkthauZ0AcnIDs+H6rRRh8YAqiWXvRGoMfGiTJRpeJm7yNfZ 58MY7+QgnqBYPIHcAvDKjbHyNrLyOTX/soe5VyUdisgxywxdDuK+B7wyrJ6f2uCu/TaQ p0iBg0OSjs8GMDRhFTyO+/fxKsB87lQ9utOmZDWf+beskpo3fO0jWXtgyx8z6iYrLaU0 xfm/3C+O/GezMkHxmCHT/Wb7iPirYFAtfeDB9o1aXlMMYlM9jTjnR/N7KtAQwCP46XEb DNDQ== X-Gm-Message-State: AMCzsaXEiYaRRy3/G7liL20qBDlXVuxxg5Q1NBzyr4KMDyhI9uvB5MXJ YlIz7kOPeekuu8drJ2H8erL9OdBEdkg= X-Google-Smtp-Source: ABhQp+TSH73kgKHYfSOjnbmCOxw422tE+BrPLvaZf0oPz8YhFgWp/lnA0u9r6c9jLiA25hH4RWKSYg== X-Received: by 10.28.154.204 with SMTP id c195mr7790381wme.80.1508850094823; Tue, 24 Oct 2017 06:01:34 -0700 (PDT) Received: from shemminger-XPS-13-9360 ([62.168.35.124]) by smtp.gmail.com with ESMTPSA id f27sm297997wrf.63.2017.10.24.06.01.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 24 Oct 2017 06:01:34 -0700 (PDT) Date: Tue, 24 Oct 2017 15:01:24 +0200 From: Stephen Hemminger To: Nitin Katiyar Cc: "dev@dpdk.org" Message-ID: <20171024150124.6dbe211f@shemminger-XPS-13-9360> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] Issue with MTU/max_rx_pkt_len handling by different NICs/PMD drivers 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: Tue, 24 Oct 2017 13:01:35 -0000 On Tue, 24 Oct 2017 12:25:38 +0000 Nitin Katiyar wrote: > Hi, > While testing MTU configuration of physical ports using OVS-DPDK we have found that Fortville and Niantic behaves differently for Tagged packets. Both allows TX of packets with size up to programmed MTU value but in receive direction Fortville drops packets of size equal to configured MTU. Additionally, Fortville does not report any error/drop counter if packets with size more than configured MTU (max frame size) are received. In Niantic we can see error counters getting incremented if packets of size more than MTU are received. > > When ports are started, device attribute max_rx_pkt_len is set during device/queue init by application (OVS in our case) and this max_rx_pkt_len is used to program hardware register in device which in turn determines the maximum size of packet/frame that it can receive. > What we have found during testing is that Niantic could receive tagged/untagged packets of size equal to max_rx_pkt_len but Fortville could only receive tagged packets (single tag) up to size <= (max_rx_pkt_len - 4). Datasheet of Niantic mentions that device implicitly accounts for VLAN tag(s) in addition to Maximum Frame size programmed which is not the case for Fortville. This causes issue with MTU settings and maximum frame size that NIC can receive with tagged and untagged traffic. > We have tested it with OVS-DPDK where it uses device attribute max_rx_pkt_len to set max frame size in accordance with the configured MTU size of port. However, Ixgbe (Niantic) and i40e (Fortville) interpret it differently. I looked at some other PMD drivers and different drivers interpret dev_conf.rxmode.max_rx_pkt_len differently i.e. some adds one or two VLAN, few don't include it and some use this field differently. It creates issue with MTU while running same application on different NICs and PMD drivers need to be fixed to have consistent behavior with MTU/Max Frame Size settings. > > Regards, > Nitin Katiyar MTU on most operating systems is advisory to device driver. The device driver may receive packets up to that MTU or larger. How much bigger depends on how the hardware receive packet limit is implemented. Same thing happens in Linux and BSD.