From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Rohit Raj <rohit.raj@nxp.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Nipun Gupta <nipun.gupta@nxp.com>,
"Hemant Agrawal" <hemant.agrawal@nxp.com>,
Sachin Saxena <sachin.saxena@nxp.com>,
Vanshika Shukla <vanshika.shukla@nxp.com>
Subject: Re: [dpdk-dev] [PATCH v1] examples/l3fwd: fix jumbo packet drop issue
Date: Fri, 13 Aug 2021 09:42:09 +0100 [thread overview]
Message-ID: <79974313-19d2-2d57-636f-669341172b1f@intel.com> (raw)
In-Reply-To: <VE1PR04MB650987F6D77133286FCCD878ECFA9@VE1PR04MB6509.eurprd04.prod.outlook.com>
On 8/13/2021 5:48 AM, Rohit Raj wrote:
>
>
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>> Sent: Wednesday, August 11, 2021 5:01 PM
>> To: Rohit Raj <rohit.raj@nxp.com>
>> Cc: dev@dpdk.org; Nipun Gupta <nipun.gupta@nxp.com>; Hemant Agrawal
>> <hemant.agrawal@nxp.com>; Sachin Saxena <sachin.saxena@nxp.com>;
>> Vanshika Shukla <vanshika.shukla@nxp.com>
>> Subject: Re: [dpdk-dev] [PATCH v1] examples/l3fwd: fix jumbo packet drop
>> issue
>>
>> On 7/27/2021 10:25 AM, rohit.raj@nxp.com wrote:
>>> From: Rohit Raj <rohit.raj@nxp.com>
>>>
>>> l3fwd uses mbufs with 2KB data size. If we enable jumbo packets, it is
>>> not able to store packets with size greater than 2KB, hence these
>>> packets are dropped.
>>>
>>> This patch fixes this issue by enabling scatter for jumbo packet, if
>>> it is supported by NIC.
>>>
>>> If scatter is not supported by NIC and max jumbo packet length is
>>> greater than default mbuf data size, then application exits with
>>> proper error message.
>>>
>>> Fixes: f68aad7904f ("examples/l3fwd: update")
>>>
>>> Signed-off-by: Rohit Raj <rohit.raj@nxp.com>
>>> Signed-off-by: Sachin Saxena <sachin.saxena@nxp.com>
>>> Signed-off-by: Vanshika Shukla <vanshika.shukla@nxp.com>
>>> ---
>>> examples/l3fwd/main.c | 14 ++++++++++++++
>>> 1 file changed, 14 insertions(+)
>>>
>>> diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c index
>>> 4cb800aa15..6aaaa8ecb5 100644
>>> --- a/examples/l3fwd/main.c
>>> +++ b/examples/l3fwd/main.c
>>> @@ -1035,6 +1035,20 @@ l3fwd_poll_resource_setup(void)
>>> "Error during getting device (port %u) info: %s\n",
>>> portid, strerror(-ret));
>>>
>>> + /* Enable Receive side SCATTER, if supported by NIC,
>>> + * when jumbo packet is enabled.
>>> + */
>>> + if (local_port_conf.rxmode.offloads &
>>> + DEV_RX_OFFLOAD_JUMBO_FRAME){
>>> + if (dev_info.rx_offload_capa & DEV_RX_OFFLOAD_SCATTER)
>>> + local_port_conf.rxmode.offloads |=
>>> + DEV_RX_OFFLOAD_SCATTER;
>>> + else if (local_port_conf.rxmode.max_rx_pkt_len >
>>> + RTE_MBUF_DEFAULT_DATAROOM)
>>> + rte_exit(EXIT_FAILURE,
>>> + "Max packet length greater than
>>> + default MBUF size\n");
>>
>> This is a configuration set by application. So application is failing itself because
>> of configuration it sets, seems odd.
>>
>> I guess the jumbo frame can be enabled when user provides '--enable-jumbo'
>> argument. What do you think adding above check where that argument is
>> parsed.
>
> We need to check if hardware supports Rx scatter. To do this, we need to get Rx
> capability. Hence, this is a better place to perform this check.
>
Got it.
There is already a patch [1] that I am trying to update the 'max_rx_pkt_len'
usage and remove OFFLOAD_JUMBO_FRAME flag [2] etc.. Those touch to the same
piece of code, can you please check them?
After those patches, your update can be put into 'config_port_max_pkt_len()' I
think. Can you be OK to wait them to merged first and make you patch on top of it?
[1]
https://patches.dpdk.org/project/dpdk/patch/20210722172113.3236450-1-ferruh.yigit@intel.com/
[2]
https://patches.dpdk.org/project/dpdk/patch/20210722172113.3236450-4-ferruh.yigit@intel.com/
>>
>> Btw, no need to enable scattered Rx if the packets fits into buffer, so above
>> check can be done slightly different:
>>
>> if (max_rx_pkt_len > buffer_size)
>> if (OFFLOAD_SCATTER supported)
>> enable OFFLOAD_SCATTER
>> else
>> fail
>
> Agreed. I will do this in next version of the patch.
>
>>
>>
>>> + }
>>> +
>>> if (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_MBUF_FAST_FREE)
>>> local_port_conf.txmode.offloads |=
>>> DEV_TX_OFFLOAD_MBUF_FAST_FREE;
>>>
>
next prev parent reply other threads:[~2021-08-13 8:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-13 4:48 Rohit Raj
2021-08-13 8:42 ` Ferruh Yigit [this message]
2021-10-19 21:22 ` Ferruh Yigit
-- strict thread matches above, loose matches on Subject: below --
2021-07-27 9:25 rohit.raj
2021-08-11 10:19 ` Singh, Aman Deep
2021-08-11 11:30 ` Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=79974313-19d2-2d57-636f-669341172b1f@intel.com \
--to=ferruh.yigit@intel.com \
--cc=dev@dpdk.org \
--cc=hemant.agrawal@nxp.com \
--cc=nipun.gupta@nxp.com \
--cc=rohit.raj@nxp.com \
--cc=sachin.saxena@nxp.com \
--cc=vanshika.shukla@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).