From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by dpdk.org (Postfix) with ESMTP id 7EE348DA8 for ; Fri, 11 Sep 2015 19:48:23 +0200 (CEST) Received: by wiclk2 with SMTP id lk2so66651721wic.1 for ; Fri, 11 Sep 2015 10:48:23 -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=n8qhScZ162GUMuWTCDFTTKBzIFmLuJDtwhe6tcZtqhM=; b=epgMpwkTK56hKKi2VWVTBxpxv74WC1TsVtr1QC6talKx4/FnVag/Upf/MAQnHmtHKW mBkg27PRoKZfb0D020LJfP9R/tUyvCBBqzxpLzZ2P4aipmfTtHberJ+e4ddiSqRnp952 r7l3ZO5HXKC0HwHf2u/Zr/CCwkUL5ksnL7P24jz5mgyk8bCcvD49FNX4KPihvgDC+4b7 84Vm+ZFqq13dt2DowJ4oOaQ5ZCy9KCl4uGIu8B6CxN8RT5d07zc3I/QZvHSAlwNdS2wj Up+/ispWOuI8u84m/y9CSCEOuat/tbj6st2RwKENiYGEgKtcx+ldjNmUCnUfWFEklQL3 TE+Q== X-Gm-Message-State: ALoCoQm7Z2YOqKvPhiDSb2O49olNAWfzUC7K0UyPdWXAHSCB+UGHWNoTu5XTgT3hzJOGLUDUvPqE X-Received: by 10.180.37.33 with SMTP id v1mr6820524wij.88.1441993703350; Fri, 11 Sep 2015 10:48:23 -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 d1sm243657wiz.0.2015.09.11.10.48.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Sep 2015 10:48:21 -0700 (PDT) To: Thomas Monjalon , Vladislav Zolotarov , "didier.pallard" References: <1439489195-31553-1-git-send-email-vladz@cloudius-systems.com> <55F2F6A9.6080405@cloudius-systems.com> <3734976.j9Azrvq6io@xps13> From: Avi Kivity Message-ID: <55F313E4.2080300@cloudius-systems.com> Date: Fri, 11 Sep 2015 20:48:20 +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: <3734976.j9Azrvq6io@xps13> Content-Type: text/plain; charset=windows-1252; 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 17:48:23 -0000 On 09/11/2015 07:08 PM, Thomas Monjalon wrote: > 2015-09-11 18:43, Avi Kivity: >> On 09/11/2015 06:12 PM, Vladislav Zolotarov wrote: >>> On Sep 11, 2015 5:55 PM, "Thomas Monjalon" >> > wrote: >>>> 2015-09-11 17:47, Avi Kivity: >>>>> On 09/11/2015 05:25 PM, didier.pallard wrote: >>>>>> 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. >>>> More than a check, it should be exposed as a capability of the port. >>>> Anyway, if the application sends too much segments, the driver must >>>> drop it to avoid hang, and maintain a dedicated statistic counter to >>>> allow easy debugging. >>> I agree with Thomas - this should not be optional. Malformed packets >>> should be dropped. In the icgbe case it's a very simple test - it's a >>> single branch per packet so i doubt that it could impose any >>> measurable performance degradation. >> A drop allows the application no chance to recover. The driver must >> either provide the ability for the application to know that it cannot >> accept the packet, or it must fix it up itself. > I have the feeling that everybody agrees on the same thing: > the application must be able to make a well formed packet by checking > limitations of the port. What about a field rte_eth_dev_info.max_tx_segs? It is not generic enough. i40e has a limit that it imposes post-TSO. > In case the application fails in its checks, the driver must drop it and > notify the user via a stat counter. > The driver can also remove the hardware limitation by gathering the segments > but it may be hard to implement and would be a slow operation. I think that to satisfy both the 64b full line rate applications and the more complicated full stack applications, this must be made optional. In particular, and application that only forwards packets will never hit a NIC's limits, so it need not take any action. That's why I think a verification function is ideal; a forwarding application can ignore it, and a complex application can call it, and if it fails the packet, it can linearize it itself, removing complexity from dpdk itself.