From mboxrd@z Thu Jan  1 00:00:00 1970
From: "didier.pallard" <didier.pallard@6wind.com>
Subject: Re: [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1
 for all NICs but 82598
Date: Fri, 11 Sep 2015 16:25:12 +0200
Message-ID: <55F2E448.1070602@6wind.com>
References: <1439489195-31553-1-git-send-email-vladz@cloudius-systems.com>
 <F35DEAC7BCE34641BA9FAC6BCA4A12E70A8E1AE6@SHSMSX104.ccr.corp.intel.com>
 <55CD7EA5.6060100@cloudius-systems.com>
 <6A0DE07E22DDAD4C9103DF62FEBC0909D3E116@shsmsx102.ccr.corp.intel.com>
 <CAOYyTHaymoNj92+_F1NaP6vPmGO9bdJV7VY7V052RrR_NjRUPw@mail.gmail.com>
 <F35DEAC7BCE34641BA9FAC6BCA4A12E70A8E3E98@SHSMSX104.ccr.corp.intel.com>
 <F35DEAC7BCE34641BA9FAC6BCA4A12E70A8E65FF@SHSMSX104.ccr.corp.intel.com>
 <CAOYyTHZ062SGrshnpFKnm6yap-GiQRdQ2yaB9-UcOotOXqRYjA@mail.gmail.com>
 <F35DEAC7BCE34641BA9FAC6BCA4A12E70A8E6668@SHSMSX104.ccr.corp.intel.com>
 <55DCB975.2030000@cloudius-systems.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "dev@dpdk.org" <dev@dpdk.org>
To: Vlad Zolotarov <vladz@cloudius-systems.com>,
 "Zhang, Helin" <helin.zhang@intel.com>
Return-path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; Fri, 11 Sep 2015 16:25:25 +0200 (CEST)
Received: by wicgb1 with SMTP id gb1so64852913wic.1
 for <dev@dpdk.org>; Fri, 11 Sep 2015 07:25:25 -0700 (PDT)
In-Reply-To: <55DCB975.2030000@cloudius-systems.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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