From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas@monjalon.net>
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com
 [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id EB8F72B84
 for <dev@dpdk.org>; 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: <xms:TjX5WK4hTX53BtFyi6MSTA1YAhYN7TH32ore8A-uuHHhqbNTsAfdRg>
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 <thomas@monjalon.net>
To: Andriy Berestovskyy <Andriy.Berestovskyy@caviumnetworks.com>,
 Bruce Richardson <bruce.richardson@intel.com>
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 <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>
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.