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 0568CA0C45; Wed, 6 Oct 2021 00:08:16 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 89E7841297; Wed, 6 Oct 2021 00:08:16 +0200 (CEST) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) by mails.dpdk.org (Postfix) with ESMTP id 3756540688 for ; Wed, 6 Oct 2021 00:08:15 +0200 (CEST) Received: by mail-io1-f50.google.com with SMTP id r75so656294iod.7 for ; Tue, 05 Oct 2021 15:08:15 -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=xbRRzkPD9J2GYqDmn+GCIjmF9g5AcXITJxSaC0swkGc=; b=dfFFxSCfg0vFeNra0d5uVWh2zYxOnkfS8NyBMLJ9ie00pr2a9YvOAMuBSOJA7/oDwd ApaHLEVDydOd8wwuYo1g0vwA6dJi8PS24G/96XvCwdD7cnJU/PD4fBrz8MnGaAoOU37A pmgwqbhRObPPT9J9/HcpUqZLYE9ZxqBPXcwoo= 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=xbRRzkPD9J2GYqDmn+GCIjmF9g5AcXITJxSaC0swkGc=; b=0PSPcY/ROVu+X3fL2Wh+sR+MoAU1KPR6YdgymFMqTzScZTaEy/IqD7l22NAPc3+HOC LeJzyKengoYn8DBLjVEw3RrzHbnAncAauYA0FFk+dO+JEVXIAU1xewhznFljYbdo57iS LBN/aH0ap87xRoWsWZCt6juun9JpKt6yDLHgNU/X71wXpll6hnTIROMva6g3HBPbH45L lC9btOLbPaPMjDdd7rqAzw7Hqfisv+BE/08TC2L7+/rgrxMChpYOClc9RQFAGM8dvNVs 98QOEnxI21qXFVrFh2dn5Kj8yQ5AGd5I8wlniQzPQwGhnQZLaydytHFvs8Y122M2xJgI bGtg== X-Gm-Message-State: AOAM5312Cb1f3k7dHJ6LVAgimkrIS670YuOoxq9gfrBw2wlj17IyR5zj uoPIzCVQKScaq60e93it4SINQ5CKnFEqyT+aYigHtg== X-Google-Smtp-Source: ABdhPJwKdlJCcBaxV2EqZrSz/P1D+x52CDcYS0cYETah9NKbaVg36nhpIrmL7Di3bwtXo+LJ3aNbOsYRIdbEa+A3sQs= X-Received: by 2002:a6b:8d06:: with SMTP id p6mr4095368iod.111.1633471694407; Tue, 05 Oct 2021 15:08:14 -0700 (PDT) MIME-Version: 1.0 References: <20211001143624.3744505-1-ferruh.yigit@intel.com> <20211005171653.3700067-1-ferruh.yigit@intel.com> In-Reply-To: <20211005171653.3700067-1-ferruh.yigit@intel.com> From: Ajit Khaparde Date: Tue, 5 Oct 2021 15:07:58 -0700 Message-ID: To: Ferruh Yigit Cc: 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 , Somnath Kotur , 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="0000000000001e2bec05cda244db" 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" --0000000000001e2bec05cda244db Content-Type: text/plain; charset="UTF-8" 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 --0000000000001e2bec05cda244db--