From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F0B42A0C45; Wed, 6 Oct 2021 08:08:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AE2D940696; Wed, 6 Oct 2021 08:08:29 +0200 (CEST) Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) by mails.dpdk.org (Postfix) with ESMTP id 8F29D40688 for ; Wed, 6 Oct 2021 08:08:28 +0200 (CEST) Received: by mail-yb1-f170.google.com with SMTP id r1so2806750ybo.10 for ; Tue, 05 Oct 2021 23:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bLHVB/5VzvUktN7QlHNVQpUO5U01XKLrfxXS2BVdWZ8=; b=QwHV+/pziaQH1+fZrbMvKtdwc+lwSAPEIvR92+OOzyT9y8jgG4aCA6KJIfvTNTvFx3 7V+wRt2fRCRYP7AHbJMVAJN92VF01QKVVh6m8RriirGjIbRorIfjRHn88wWnjcWgCjHR T8srunRiHLY4CpsPH8akzjCuWeHbsMQsSxHjM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bLHVB/5VzvUktN7QlHNVQpUO5U01XKLrfxXS2BVdWZ8=; b=o4bnICIe7X02qow1WdKodxodnftmtJgzJD270VntN1KgXjojPULT2THmC95vPRRzWX QLrImWIGF2Nk0MbuVg1DNlW9JZlHT+v6xgvzw20WnKA64Cp688TWeD/UlVbznSI8rjQ3 GSdnbg+Q10bDDcvcR1HJjvmqGa/vskgXcdnHHUupcXt1QBEr1n/pjtqrhMY73dW/CIGn 6snGZxK/Fhp7iiWAUwKydz8JEaFE36ESXtiIW5kj5Nyb775AgKJskixwdqP+UwjmG+AT H2VLM59OHIj0nbltPMY40cfUi9axkJP7DrayAKy7FYHc8Ejli33cMskuiuOjyJOXPQWf asrQ== X-Gm-Message-State: AOAM530oGlSlnmTEtdL2//tgpgNBWTqTTiOQ6K8wuRAF+cxKAyn7NJuN OnVl0QDeJ9lDM1+ewpB5qZwXvtqfpUpIoaw0C5BHiA== X-Google-Smtp-Source: ABdhPJwoUpLtKZgTIybEBlBYPuFbY6oLPDkg8HdOuplVcUjXKOsBumBo3WWJNBa0MjUJvxZ9xeaUVMOIxO74/gA7IGo= X-Received: by 2002:a25:838e:: with SMTP id t14mr28055903ybk.208.1633500507850; Tue, 05 Oct 2021 23:08:27 -0700 (PDT) MIME-Version: 1.0 References: <20211001143624.3744505-1-ferruh.yigit@intel.com> <20211005171653.3700067-1-ferruh.yigit@intel.com> In-Reply-To: From: Somnath Kotur Date: Wed, 6 Oct 2021 11:38:16 +0530 Message-ID: To: Ajit Khaparde Cc: Ferruh Yigit , Jerin Jacob , Xiaoyun Li , Chas Williams , "Min Hu (Connor)" , Hemant Agrawal , Sachin Saxena , Qi Zhang , Xiao Wang , Matan Azrad , Viacheslav Ovsiienko , Harman Kalra , Maciej Czekaj , Ray Kinsella , Bernard Iremonger , Konstantin Ananyev , Kiran Kumar K , Nithin Dabilpuram , David Hunt , John McNamara , Bruce Richardson , Igor Russkikh , Steven Webster , Matt Peters , Somalapuram Amaranath , Rasesh Mody , Shahed Shaikh , Sunil Kumar Kori , Satha Rao , Rahul Lakkireddy , Haiyue Wang , Marcin Wojtas , Michal Krawczyk , Shai Brandes , Evgeny Schemeilin , Igor Chauskin , Gagandeep Singh , John Daley , Hyong Youb Kim , Ziyang Xuan , Xiaoyun Wang , Guoyang Zhou , Yisen Zhuang , Lijun Ou , Beilei Xing , Jingjing Wu , Qiming Yang , Andrew Boyer , Rosen Xu , Shijith Thotton , Srisivasubramanian Srinivasan , Zyta Szpak , Liron Himi , Heinrich Kuhn , Devendra Singh Rawat , Andrew Rybchenko , Keith Wiles , Jiawen Wu , Jian Wang , Maxime Coquelin , Chenbo Xia , Nicolas Chautru , Harry van Haaren , Cristian Dumitrescu , Radu Nicolau , Akhil Goyal , Tomasz Kantecki , Declan Doherty , Pavan Nikhilesh , Kirill Rybalchenko , Jasvinder Singh , Thomas Monjalon , dpdk-dev Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000008784b405cda8f929" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-dev] [PATCH v4 1/6] ethdev: fix max Rx packet length X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" --0000000000008784b405cda8f929 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 6, 2021 at 3:38 AM Ajit Khaparde wrote: > > On Tue, Oct 5, 2021 at 10:31 AM Ferruh Yigit wrote: > > > > There is a confusion on setting max Rx packet length, this patch aims to > > clarify it. > > > > 'rte_eth_dev_configure()' API accepts max Rx packet size via > > 'uint32_t max_rx_pkt_len' field of the config struct 'struct > > rte_eth_conf'. > > > > Also 'rte_eth_dev_set_mtu()' API can be used to set the MTU, and result > > stored into '(struct rte_eth_dev)->data->mtu'. > > > > These two APIs are related but they work in a disconnected way, they > > store the set values in different variables which makes hard to figure > > out which one to use, also having two different method for a related > > functionality is confusing for the users. > > > > Other issues causing confusion is: > > * maximum transmission unit (MTU) is payload of the Ethernet frame. And > > 'max_rx_pkt_len' is the size of the Ethernet frame. Difference is > > Ethernet frame overhead, and this overhead may be different from > > device to device based on what device supports, like VLAN and QinQ. > > * 'max_rx_pkt_len' is only valid when application requested jumbo frame, > > which adds additional confusion and some APIs and PMDs already > > discards this documented behavior. > > * For the jumbo frame enabled case, 'max_rx_pkt_len' is an mandatory > > field, this adds configuration complexity for application. > > > > As solution, both APIs gets MTU as parameter, and both saves the result > > in same variable '(struct rte_eth_dev)->data->mtu'. For this > > 'max_rx_pkt_len' updated as 'mtu', and it is always valid independent > > from jumbo frame. > > > > For 'rte_eth_dev_configure()', 'dev->data->dev_conf.rxmode.mtu' is user > > request and it should be used only within configure function and result > > should be stored to '(struct rte_eth_dev)->data->mtu'. After that point > > both application and PMD uses MTU from this variable. > > > > When application doesn't provide an MTU during 'rte_eth_dev_configure()' > > default 'RTE_ETHER_MTU' value is used. > > > > Additional clarification done on scattered Rx configuration, in > > relation to MTU and Rx buffer size. > > MTU is used to configure the device for physical Rx/Tx size limitation, > > Rx buffer is where to store Rx packets, many PMDs use mbuf data buffer > > size as Rx buffer size. > > PMDs compare MTU against Rx buffer size to decide enabling scattered Rx > > or not. If scattered Rx is not supported by device, MTU bigger than Rx > > buffer size should fail. > > > > Signed-off-by: Ferruh Yigit > > --- > > Cc: Min Hu (Connor) > > > > v2: > > * Converted to explicit checks for zero/non-zero > > * fixed hns3 checks > > * fixed some sample app rxmode.mtu value > > * fixed some sample app max-pkt-len argument and updated doc for it > > > > v3: > > * rebased > > > > v4: > > * fix typos in commit logs > > That's a lot of detail in the log. Thanks > > Acked-by: Ajit Khaparde Acked-by: Somnath Kotur --0000000000008784b405cda8f929--