From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by dpdk.org (Postfix) with ESMTP id C0BE05934 for ; Fri, 11 Sep 2015 16:25:25 +0200 (CEST) Received: by wicgb1 with SMTP id gb1so64852913wic.1 for ; Fri, 11 Sep 2015 07:25:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zWHxT7hFcAsI29wEkkKZdpy7SP7TIWCTib4L14ZihWo=; b=dgvrq+CQT+LVGUKJQfYl1jjI0uKQufskWfxIJrC4aySmxutz0+jDOH//Tpr+gUXqxA 40pQvmuO9BMplOF3jXOPax7GaKLFiFYRlCU8O0qVxHVE3P7bk6EwxpYlkzKV2Z0ZwJU+ 6NsQkXrjM+sVJA/MzdAqZLn3P8daJdcJIToZha/xlN3V8InZAetjbUcQeefAzLA3dPPf tAeF4A+OS6YPh1jHCaV0wZ7IgxiZ8e6hT1kI6MtjQeUoRx/fxuKhaf1qv8OS5O7fdtl+ Lh5Se4d9e/w0phK9l+eg2ugm1lFIwVktcrGaqdJQGy9mZYvqJf2xmbNrtjrGBfihWmWD xhUg== X-Gm-Message-State: ALoCoQnTJxUns3OP7KawxREkBDZBjkUvr9JPtIP7JW+VE101QAxct1azwmaSi0dqNXxceFurfmSq X-Received: by 10.194.81.169 with SMTP id b9mr82448017wjy.3.1441981525576; Fri, 11 Sep 2015 07:25:25 -0700 (PDT) Received: from [10.16.0.123] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id ry1sm633582wjb.24.2015.09.11.07.25.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Sep 2015 07:25:24 -0700 (PDT) Message-ID: <55F2E448.1070602@6wind.com> Date: Fri, 11 Sep 2015 16:25:12 +0200 From: "didier.pallard" Organization: 6WIND User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Vlad Zolotarov , "Zhang, Helin" References: <1439489195-31553-1-git-send-email-vladz@cloudius-systems.com> <55CD7EA5.6060100@cloudius-systems.com> <6A0DE07E22DDAD4C9103DF62FEBC0909D3E116@shsmsx102.ccr.corp.intel.com> <55DCB975.2030000@cloudius-systems.com> In-Reply-To: <55DCB975.2030000@cloudius-systems.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598 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: Fri, 11 Sep 2015 14:25:25 -0000 On 08/25/2015 08:52 PM, Vlad Zolotarov wrote: > > Helin, the issue has been seen on x540 devices. Pls., see a chapter > 7.2.1.1 of x540 devices spec: > > A packet (or multiple packets in transmit segmentation) can span any > number of > buffers (and their descriptors) up to a limit of 40 minus WTHRESH > minus 2 (see > Section 7.2.3.3 for Tx Ring details and section Section 7.2.3.5.1 for > WTHRESH > details). For best performance it is recommended to minimize the > number of buffers > as possible. > > Could u, pls., clarify why do u think that the maximum number of data > buffers is limited by 8? > > thanks, > vlad Hi vlad, Documentation states that a packet (or multiple packets in transmit segmentation) can span any number of buffers (and their descriptors) up to a limit of 40 minus WTHRESH minus 2. Shouldn't there be a test in transmit function that drops properly the mbufs with a too large number of segments, while incrementing a statistic; otherwise transmit function may be locked by the faulty packet without notification. thanks didier