From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id EB8F72B84 for ; Fri, 21 Apr 2017 00:25:18 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 61A19207E2; Thu, 20 Apr 2017 18:25:18 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 20 Apr 2017 18:25:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=w17ybonCRBbfb07 A24XcSjjgTVLAxDfZC81TbVep140=; b=QQAaXdyMoTSWoWx74u6iURL1FBRf58w sMvqAfkvDy5UlbSXZNttOguMwuNeLqLzGTR3aVL24QmdHCJ1qIfezPDyCAgFqqzH 7TodlGwQpX2jH/yG399dEP25c2ypoiy1Q4IgkqB8slcZsIg46NvBqWULi+GPTc/j TUOGaJycRjkg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=w17ybonCRBbfb07A24XcSjjgTVLAxDfZC81TbVep140=; b=b1EjafRY 75AQbnnZ5hQgcBT1SCjgTjE396LVYQZPZmLxylceYgULiYFYNNI/yKaspiZs+2Mh drmBgUkFKx9LIFfTpseLKsl0J67JTBlA7jZqjtnsC56/b7yQycddzQ6K4Fr8EWHC jyR1zFkePqiGAgu4kAh8t6ToKP3Rb2FG4+Tg+wB6UvtDeXHBg/ESxK+Oc818EduG wX1sVkswlS76LudycO2Na9Mis7lBsIGjl+3GKgKZUwN+hT+LeAqGxLqFgRgZenRM PooTnHE+cwIBB75j+tNHwUiEnDKaH2mp2JzZChHlqpNwNiPKAhfHscpLzTsLsX9O kuREsGd/szosxQ== X-ME-Sender: X-Sasl-enc: VqIU+aIY7WMBTonKAM1Q7VUFjsUzaP+ustTHoqZnI+YF 1492727118 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 136357E0EE; Thu, 20 Apr 2017 18:25:18 -0400 (EDT) From: Thomas Monjalon To: Andriy Berestovskyy , Bruce Richardson Cc: dev@dpdk.org Date: Fri, 21 Apr 2017 00:25:17 +0200 Message-ID: <2079307.yoZvx5qzNF@xps> In-Reply-To: <40c13c68-aadf-1665-a301-7d74be3017cd@caviumnetworks.com> References: <1490288768-8114-1-git-send-email-Andriy.Berestovskyy@cavium.com> <2875009.PBUn9ZmEvk@xps13> <40c13c68-aadf-1665-a301-7d74be3017cd@caviumnetworks.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3] ether: use a default for max Rx frame size in configure() X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 22:25:19 -0000 07/04/2017 17:27, Andriy Berestovskyy: > Hey Thomas, > > On 07.04.2017 16:47, Thomas Monjalon wrote: > >> What if we add to the max_rx_pkt_len description: "the effective maximum > >> RX frame size depends on PMD, please refer the PMD guide for the > >> details"? > > > > I think the problem is not in the documentation but in the implementations > > which should be more consistent. > > The hardware is different, there is not much we can do about it. We can return an error if the max_rx_pkt_len cannot be set in the NIC. > Nevertheless, we can fix the false comment and have a default for the > jumbos, which is beneficial for the apps/examples. The examples are using a hardcoded value, so they need to be fixed anyway. > > If I understand well, the inconsistency between drivers was already an > > issue before your patch. > > Your patch fixes an inconsistency in ethdev without fixing the drivers. > > We need to know if it is a good first step and if the drivers can be > > fixed later. > > Thomas, some of the examples use a hard-coded jumbo frame size, which is > too big for the underlaying PMDs, so those examples fail. The plan was > to fix them all with this commit in ethdev but I am not sure now you are > to accept the change. This ethdev patch is about a behaviour change of the API. It is about considering 0 as a request for default value and return an error if a value cannot be set. It will require more agreements and changes in the drivers for returning an error where appropriate. > It is important for us to have those examples working in the upcoming > release, do you think it is better to send fixes for those examples > instead of this commit then? The examples can be improved independently of this patch.