From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by dpdk.org (Postfix) with ESMTP id 451722BBD for ; Tue, 28 Jun 2016 11:23:43 +0200 (CEST) Received: by mail-oi0-f48.google.com with SMTP id u201so14505628oie.0 for ; Tue, 28 Jun 2016 02:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7u7pmtkMPGW14u0OjPDM8OZZ+eyPoNlNlRWLcPEPdAU=; b=P/C3cln5hdEnv5rv1/2l1UE6wjkfnBm/sSzZurq3N4SL/cqm4sy7EXsxDsgcvDfma5 +e6Lea6xxWtyenqplEzbxmimuImOQwsl1XYR4i9mbeXZTzVhJO5pHsJNUd0ONthnTlf+ rZhPq4a9I2vQ3ysSOu9ByfgUUCGEjfF8bgLUWdnkqidsfO/cuEKPW/r7qNMRwH2QQCwF W0jTkdIxlReC1L9sN2BpQos8jqmMu1zHBsW7p9axuhNcp4xM7uz6sr9MqAnN+Mt0kMK/ H7iOLaHz8iEk/TYtIm8P9vHKebAKAYq+RRoXSJVIQt4VbHnRnTKgZ/Nd+fS58jk5eJ2f opvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7u7pmtkMPGW14u0OjPDM8OZZ+eyPoNlNlRWLcPEPdAU=; b=UROr/8hXtIZyk12RrhliPibdSEMlHbWeEGAoHRuLwyJGjE+cuU9/UUOt+eyy49Imq9 DMBrkaj9M8ejbuZ/R94JUTWMLeRrjjDgjFwGBhdFUHXcmd5TYtgIq4DK9Gz/n4bKJOjE gnc38WthS+NILkus2HF0GqI/eepRQVBsMeoMLDdz2QmWawAmFjCcVup7wTAOhyF+j3bt IJhL8VjRwIroak044h3hNpCFjFTH5nzULWdDGxLXbBzP+Vll05KHgYDCkDotUzCsgBYb RygKfFeVN13vCMaPII8zwf6wELhO5H3l0QXkVj79i/almJxGrhzfx1Sf1FGuekeBex4b dq4g== X-Gm-Message-State: ALyK8tKed3R1m8DeHfqCoST/Tl/XaWE62XcaQ2uLPCDpJnYo7wdL2W2s0PGZ9PsViBD2tJ5TCl6FouD2L0O6sw== X-Received: by 10.157.61.195 with SMTP id l61mr1160265otc.31.1467105822653; Tue, 28 Jun 2016 02:23:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.0.6 with HTTP; Tue, 28 Jun 2016 02:23:23 -0700 (PDT) In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09090348B7E1@shsmsx102.ccr.corp.intel.com> References: <6A0DE07E22DDAD4C9103DF62FEBC09090348B7E1@shsmsx102.ccr.corp.intel.com> From: Asim Jamshed Date: Tue, 28 Jun 2016 18:23:23 +0900 Message-ID: To: "Lu, Wenzhuo" Cc: "dev@dpdk.org" Content-Type: text/plain; charset=UTF-8 Subject: Re: [dpdk-dev] Fwd: dpdk ixgbe PMD lro limits X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 09:23:43 -0000 On Tue, Jun 28, 2016 at 5:42 PM, Lu, Wenzhuo wrote: > Hi Asim, > > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Asim Jamshed >> Sent: Tuesday, June 28, 2016 2:41 PM >> To: dev@dpdk.org >> Subject: [dpdk-dev] Fwd: dpdk ixgbe PMD lro limits >> >> Hi, >> >> Apologies in advance if this question has been asked in the past. >> >> I have been performing mTCP-related tests on dpdk-16.04 with ixgbe PMD. I am >> using 82599ES 10-Gigabit adapters for my experiments. I have a few queries >> regarding LRO. >> >> 1) What is the theoretical maximum size of the Ethernet frame I can get from >> the driver once LRO is enabled? In my experiments, I was seeing packet size as >> high as 16KB. Can it be as high as ~2^16 bytes (iph->tot_len)? > I'm not sure about if I understand your question correctly. Assume you're talking about the TCP segment after LRO. So, it's said there are no limitations on the maximum packet length. The issue that I am facing is fixing the size of mbuf. The default size of mbuf is (2048 + sizeof(struct rte_mbuf) + RTE_PKTMBUF_HEADROOM) which needs to be augmented once lro is enabled (am I right?). I tried stretching the limits of the mempool by increasing mbuf size to (65536 + sizeof(struct rte_mbuf) + RTE_PKTMBUF_HEADROOM), and I got the following error: Initializing port 0... EAL: Error - exiting with code: 1 Cause: rte_eth_rx_queue_setup:err=-22, port=0, queueid: 0 My exact calls for rte_mempool_create() and rte_eth_rx_queue_setup() were: pktmbuf_pool = rte_mempool_create(name, 8192, MBUF_SIZE, 256, sizeof(struct rte_pktmbuf_pool_private), rte_pktmbuf_pool_init, NULL, rte_pktmbuf_init, NULL, rte_socket_id(), 0); ret = rte_eth_rx_queue_setup(portid, rxlcore_id, 128, rte_eth_dev_socket_id(portid), &rx_conf, pktmbuf_pool); > >> >> 2) Since the NIC is reassembling payloads (of one flow) into a single packet, >> what does the Ethernet controller do with the tcp checksum field in the TCP >> header? I am observing that each LRO packet has checksum value as zero? Is >> that normal? I could not find any relevant documentation on the Web. > That's expected. > You can search 82599 datasheet. I think that's what you're looking for. Thanks! Regards, --Asim > >> >> Thanks in advance, >> --Asim