From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id EB992A052A; Thu, 26 Nov 2020 13:34:57 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 75F44C940; Thu, 26 Nov 2020 13:34:55 +0100 (CET) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id E1AC3C93E for <dev@dpdk.org>; Thu, 26 Nov 2020 13:34:53 +0100 (CET) IronPort-SDR: Fzn/ArMKlwSwllrpf6VroPljQVLxziBpE73jAta5VAPXlRk1OlP3VdVfEKgI2EaQm6cpa6wQUP o68fIr3ifKdA== X-IronPort-AV: E=McAfee;i="6000,8403,9816"; a="151536595" X-IronPort-AV: E=Sophos;i="5.78,372,1599548400"; d="scan'208";a="151536595" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Nov 2020 04:34:50 -0800 IronPort-SDR: cKKUjImvVi09Pok2YFP7RKjrJY7IUTwo7r2pWsYOP9A+6nOMf64Rl1J5Zt8IGr52kYNhIeItBi 2L+t/AimfoPA== X-IronPort-AV: E=Sophos;i="5.78,372,1599548400"; d="scan'208";a="333364107" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.229.67]) ([10.213.229.67]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Nov 2020 04:34:47 -0800 To: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>, Ray Kinsella <mdr@ashroe.eu>, Neil Horman <nhorman@tuxdriver.com>, Konstantin Ananyev <konstantin.ananyev@intel.com> Cc: dev@dpdk.org, Konstantin Ananyev <konstantin.ananyev@intel.com>, Thomas Monjalon <thomas@monjalon.net>, Andrew Rybchenko <arybchenko@solarflare.com>, Matan Azrad <matan@nvidia.com>, Olivier Matz <olivier.matz@6wind.com>, Jerin Jacob <jerinj@marvell.com> References: <20201020120305.1516513-1-ferruh.yigit@intel.com> <20201124173628.1057348-1-ferruh.yigit@intel.com> <aa1cfa17-0937-519a-2e03-cb14f4d47125@oktetlabs.ru> From: Ferruh Yigit <ferruh.yigit@intel.com> Message-ID: <0d4de425-6a39-0743-2367-230c34c6cca2@intel.com> Date: Thu, 26 Nov 2020 12:34:44 +0000 MIME-Version: 1.0 In-Reply-To: <aa1cfa17-0937-519a-2e03-cb14f4d47125@oktetlabs.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [RFC v2] doc: announce max Rx packet len field deprecation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> On 11/26/2020 11:28 AM, Andrew Rybchenko wrote: > On 11/24/20 8:36 PM, Ferruh Yigit wrote: >> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com> >> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com> > > A couple of questions below, but anyway: > > Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru> > >> --- >> Cc: Thomas Monjalon <thomas@monjalon.net> >> Cc: Andrew Rybchenko <arybchenko@solarflare.com> >> Cc: Konstantin Ananyev <konstantin.ananyev@intel.com> >> Cc: Matan Azrad <matan@nvidia.com> >> Cc: Olivier Matz <olivier.matz@6wind.com> >> Cc: Jerin Jacob <jerinj@marvell.com> >> >> v2: >> * ``uint32_t mtu`` moved to ``struct rte_eth_conf`` >> * The "Driver is responsible from updating ``(struct >> rte_eth_dev)->data->mtu``" updated because ethdev layer also can do >> this. The intention there was both APIs should update the variable. >> >> Another open question is from Andrew, if we can remove the ``uint32_t >> max_rx_pkt_len`` completely from the ``rte_eth_dev_configure()``. >> This may force applications to have one more additional >> ``rte_eth_dev_set_mtu()`` call for device initialization, but if >> applications are OK with the default values most of times, agree that >> removing is easier solution, please comment. > > Still valid Yep, waiting for more comments for it. > plus I'd remove JUMBO_FRAME offload since > it is redundant. We have max_mtu and max_rx_pktlen in dev_info. > Right, I missed that 'max_mtu' & 'max_rx_pktlen' can be used to detect jumbo frame capability. +1 to remove JUMBO_FRAME offload. I don't know if should it be part of this deprecation notice, or a separate one. It is related, but logically not exactly part of this deprecation notice.