From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 334A1A0C4F;
	Tue, 13 Jul 2021 16:08:00 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id A7C31410F0;
	Tue, 13 Jul 2021 16:07:59 +0200 (CEST)
Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113])
 by mails.dpdk.org (Postfix) with ESMTP id CB0C9410DC
 for <dev@dpdk.org>; Tue, 13 Jul 2021 16:07:57 +0200 (CEST)
Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17])
 (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 107ED7F502;
 Tue, 13 Jul 2021 17:07:57 +0300 (MSK)
DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 107ED7F502
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru;
 s=default; t=1626185277;
 bh=wCreXDTaRvmjSoI60P2LZXjxwYfTXYELzrf0lARhzf0=;
 h=Subject:To:Cc:References:From:Date:In-Reply-To;
 b=X2k968ziDgSF+6WZDawnpP2AZZKZB8/UVNBFF9LNPgmTuL54ik2mJp9gI6m9j8BeX
 6D7XAtahhiJ7iOMzsVH4K1511N8tGt41JKRL4gA4uvjDOjkPpH1eBWyIOQER/C5m0Z
 eIg/Nd2Mx8FTNp18gQOMeF10CYGl500v4Sn+wBF8=
To: Ferruh Yigit <ferruh.yigit@intel.com>, Jerin Jacob <jerinj@marvell.com>,
 Xiaoyun Li <xiaoyun.li@intel.com>, Ajit Khaparde
 <ajit.khaparde@broadcom.com>, Somnath Kotur <somnath.kotur@broadcom.com>,
 Igor Russkikh <igor.russkikh@aquantia.com>,
 Pavel Belous <pavel.belous@aquantia.com>,
 Somalapuram Amaranath <asomalap@amd.com>, Rasesh Mody <rmody@marvell.com>,
 Shahed Shaikh <shshaikh@marvell.com>, Chas Williams <chas3@att.com>,
 "Min Hu (Connor)" <humin29@huawei.com>,
 Nithin Dabilpuram <ndabilpuram@marvell.com>,
 Kiran Kumar K <kirankumark@marvell.com>, Sunil Kumar Kori
 <skori@marvell.com>, Satha Rao <skoteshwar@marvell.com>,
 Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>,
 Hemant Agrawal <hemant.agrawal@nxp.com>,
 Sachin Saxena <sachin.saxena@oss.nxp.com>,
 Haiyue Wang <haiyue.wang@intel.com>, Marcin Wojtas <mw@semihalf.com>,
 Michal Krawczyk <mk@semihalf.com>, Guy Tzalik <gtzalik@amazon.com>,
 Evgeny Schemeilin <evgenys@amazon.com>, Igor Chauskin <igorch@amazon.com>,
 Gagandeep Singh <g.singh@nxp.com>, John Daley <johndale@cisco.com>,
 Hyong Youb Kim <hyonkim@cisco.com>, Gaetan Rivet <grive@u256.net>,
 Qi Zhang <qi.z.zhang@intel.com>, Xiao Wang <xiao.w.wang@intel.com>,
 Ziyang Xuan <xuanziyang2@huawei.com>,
 Xiaoyun Wang <cloud.wangxiaoyun@huawei.com>,
 Guoyang Zhou <zhouguoyang@huawei.com>, Yisen Zhuang
 <yisen.zhuang@huawei.com>, Lijun Ou <oulijun@huawei.com>,
 Beilei Xing <beilei.xing@intel.com>, Jingjing Wu <jingjing.wu@intel.com>,
 Qiming Yang <qiming.yang@intel.com>, Andrew Boyer <aboyer@pensando.io>,
 Rosen Xu <rosen.xu@intel.com>, Matan Azrad <matan@nvidia.com>,
 Shahaf Shuler <shahafs@nvidia.com>,
 Viacheslav Ovsiienko <viacheslavo@nvidia.com>, Zyta Szpak <zr@semihalf.com>,
 Liron Himi <lironh@marvell.com>, Heinrich Kuhn
 <heinrich.kuhn@netronome.com>, Harman Kalra <hkalra@marvell.com>,
 Nalla Pradeep <pnalla@marvell.com>,
 Radha Mohan Chintakuntla <radhac@marvell.com>,
 Veerasenareddy Burru <vburru@marvell.com>,
 Devendra Singh Rawat <dsinghrawat@marvell.com>,
 Maciej Czekaj <mczekaj@marvell.com>, Jiawen Wu <jiawenwu@trustnetic.com>,
 Jian Wang <jianwang@trustnetic.com>,
 Maxime Coquelin <maxime.coquelin@redhat.com>,
 Chenbo Xia <chenbo.xia@intel.com>, Yong Wang <yongwang@vmware.com>,
 Konstantin Ananyev <konstantin.ananyev@intel.com>,
 Radu Nicolau <radu.nicolau@intel.com>, Akhil Goyal <gakhil@marvell.com>,
 David Hunt <david.hunt@intel.com>, John McNamara <john.mcnamara@intel.com>,
 Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org
References: <20210709172923.3369846-1-ferruh.yigit@intel.com>
 <20210709172923.3369846-4-ferruh.yigit@intel.com>
From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Organization: OKTET Labs
Message-ID: <d1da3b3b-e5d1-43dd-709b-e04e582a33d0@oktetlabs.ru>
Date: Tue, 13 Jul 2021 17:07:56 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <20210709172923.3369846-4-ferruh.yigit@intel.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH 4/4] ethdev: remove jumbo offload flag
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
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 7/9/21 8:29 PM, Ferruh Yigit wrote:
> Removing 'DEV_RX_OFFLOAD_JUMBO_FRAME' offload flag.
> 
> Instead of drivers announce this capability, application can deduct the
> capability by checking reported 'dev_info.max_mtu' or
> 'dev_info.max_rx_pktlen'.
> 
> And instead of application explicitly set this flag to enable jumbo
> frames, this can be deducted by driver by comparing requested 'mtu' to
> 'RTE_ETHER_MTU'.

I can imagine the case when app wants to enable jumbo MTU in
run-time, but enabling requires to know it in advance in order
to configure HW correctly (i.e. offload is needed).
I think it may be ignored. Driver should either reject MTU
set in started state or do restart automatically on request.

However, driver maintainers should keep it in mind reviewing
the patch.

> 
> Removing this additional configuration for simplification.
> 
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>

ethdev part:

Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>

[snip]

> diff --git a/drivers/net/e1000/e1000_ethdev.h b/drivers/net/e1000/e1000_ethdev.h
> index 3b4d9c3ee6f4..1ae78fe71f02 100644
> --- a/drivers/net/e1000/e1000_ethdev.h
> +++ b/drivers/net/e1000/e1000_ethdev.h
> @@ -468,8 +468,8 @@ void eth_em_rx_queue_release(void *rxq);
>  void em_dev_clear_queues(struct rte_eth_dev *dev);
>  void em_dev_free_queues(struct rte_eth_dev *dev);
>  
> -uint64_t em_get_rx_port_offloads_capa(struct rte_eth_dev *dev);
> -uint64_t em_get_rx_queue_offloads_capa(struct rte_eth_dev *dev);
> +uint64_t em_get_rx_port_offloads_capa(void);
> +uint64_t em_get_rx_queue_offloads_capa(void);

I'm not sure that it is a step in right direction.
May be it is better to keep dev unused.
net/e1000 maintainers should decide.