From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by dpdk.org (Postfix) with ESMTP id C8EBE379E for ; Fri, 11 Sep 2015 16:47:54 +0200 (CEST) Received: by wicgb1 with SMTP id gb1so65681764wic.1 for ; Fri, 11 Sep 2015 07:47:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=lZij5a/zzux1BCIs4zEfkRMjhb8b5AseQYLqRD+B+5g=; b=kU+mEhii71U9tDShGwTos6bXT+SeCdXdQORogz1vVHBjukIaORfa5z931Vvt5R30Yg gbK4d55C0Yf+/vnC0bl1WBEG5c8wb61KvSjwJgY4EAKk76i+bzz+4AGIlgU0fEBCPdDv poeL4x5ekWBxzV/NRcSM7OlTAr162OY1v6pqTp8cYHdlrF9vDgSlL59lA0EX+x+yrmsC dvhxcOfkwq0xt4Iq+ZGeDBXEnZSdfsUwJTVJD5o0lAflFvFgb+LnrNbnyGyNbipjHP8i UQjO2Jser9Vpi1IgodSiuHv6ShqaFZ0vhewbC5S4rDLMUjX/ees8x5JVjNizSW6AQ3+W hPBw== X-Gm-Message-State: ALoCoQmu5gKnTpmC/+VHnY8stMK1jIc01atcgOCwy3y3Xe09m+FXxN+C3ATMVF24gSzGrwwncbep X-Received: by 10.180.75.176 with SMTP id d16mr5343621wiw.75.1441982874708; Fri, 11 Sep 2015 07:47:54 -0700 (PDT) Received: from [10.0.0.4] (bzq-109-64-134-34.red.bezeqint.net. [109.64.134.34]) by smtp.googlemail.com with ESMTPSA id c3sm761340wja.3.2015.09.11.07.47.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Sep 2015 07:47:53 -0700 (PDT) To: "didier.pallard" , 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> <55F2E448.1070602@6wind.com> From: Avi Kivity Message-ID: <55F2E997.5050009@cloudius-systems.com> Date: Fri, 11 Sep 2015 17:47:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55F2E448.1070602@6wind.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:47:54 -0000 On 09/11/2015 05:25 PM, didier.pallard wrote: > 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. > What we proposed is that the pmd expose to dpdk, and dpdk expose to the application, an mbuf check function. This way applications that can generate complex packets can verify that the device will be able to process them, and applications that only generate simple mbufs can avoid the overhead by not calling the function.