From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v3] ether: use a default for max Rx frame size in configure() Date: Fri, 21 Apr 2017 00:25:17 +0200 Message-ID: <2079307.yoZvx5qzNF@xps> 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org To: Andriy Berestovskyy , Bruce Richardson 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) In-Reply-To: <40c13c68-aadf-1665-a301-7d74be3017cd@caviumnetworks.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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.