From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Shahaf Shuler <shahafs@mellanox.com>,
Olivier Matz <olivier.matz@6wind.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
Thomas Monjalon <thomas@monjalon.net>,
Bruce Richardson <bruce.richardson@intel.com>,
Andrew Rybchenko <arybchenko@solarflare.com>
Subject: Re: [dpdk-dev] questions about new offload ethdev api
Date: Thu, 8 Mar 2018 15:45:08 +0000 [thread overview]
Message-ID: <717bd36b-a99b-e9f7-2603-f018f61a583f@intel.com> (raw)
In-Reply-To: <VI1PR05MB31493CB772F5C787680B910FC3E30@VI1PR05MB3149.eurprd05.prod.outlook.com>
On 1/23/2018 2:34 PM, Shahaf Shuler wrote:
> Tuesday, January 23, 2018 3:53 PM, Olivier Matz:
>> Hi,
<...>
>> 2/ meaning of rxmode.jumbo_frame, rxmode.enable_scatter,
>> rxmode.max_rx_pkt_len
>>
>> While it's not related to the new API, it is probably a good opportunity to
>> clarify the meaning of these flags. I'm not able to find a good documentation
>> about them.
>>
>> Here is my understanding, the configuration only depends on:
>> - the maximum rx frame length
>> - the amount of data available in a mbuf (minus headroom)
>>
>> Flags to set in rxmode (example):
>> +---------------+----------------+----------------+-----------------+
>> | |mbuf_data_len=1K|mbuf_data_len=2K|mbuf_data_len=16K|
>> +---------------+----------------+----------------+-----------------+
>> |max_rx_len=1500|enable_scatter | | |
>> +---------------+----------------+----------------+-----------------+
>> |max_rx_len=9000|enable_scatter, |enable_scatter, |jumbo_frame |
>> | |jumbo_frame |jumbo_frame | |
>> +---------------+----------------+----------------+-----------------+
>>
>> If this table is correct, the flag jumbo_frame would be equivalent to check if
>> max_rx_pkt_len is above a threshold.
>>
>> And enable_scatter could be deduced from the mbuf size of the given rxq
>> (which is a bit harder but maybe doable).
>
> I glad you raised this subject. We had a lot of discussion on it internally in Mellanox.
>
> I fully agree.
> All application needs is to specify the maximum packet size it wants to receive.
>
> I think also the lack of documentation is causing PMDs to use those flags wrongly. For example - some PMDs set the jumbo_frame flag internally without it being set by the application.
>
> I would like to add one more item : MTU.
> What is the relation (if any) between setting MTU and the max_rx_len ?
> I know MTU stands for Max Transmit Unit, however at least in Linux it is the same for the Send and the receive.
Hi Shahaf, Olivier,
Agree to clarify the meaning of these flags.
As Shahaf mentioned, I believe one of the confusion is between mtu and
max_rx_pkt_len. max_rx_pkt_len and jumbo_frame used is rte_eth_dev_configure()
[1] and according comment in rte_ethdev.h max_rx_pkt_len is only valid when
jumbo_frame is set [2].
But max_rx_pkt_len is also used in rte_eth_dev_get_mtu(), and for that case
there is not jumbo_frame arg passed. And if max_rx_pkt_len > ETHER_MAX_LEN, PMD
sets the jumbo_frame itself, as it is the real intention I think that is OK [3].
I am thinking if we can remove max_rx_pkt_len completely and just use MTU? And
let PMD set the jumbo_frame based on provided MTU.
Also there is max_rx_pktlen field in rte_eth_dev_info [4], which is, as far as I
understand, PMD preferred packet len value. At least it needs to be renamed to
use same name :) max_rx_pktlen -> max_rx_pkt_len
But if max_rx_pkt_len is going, this can also go.
For the enable_scatter, I wonder if user wants to have control over here. Even
for the jumbo_frame is enabled and mbuf_data_len=2K case, perhaps user don't
want to use enable_scatter and prefer packets to be dropped? If so we may want
to keep that flag and PMD should behave according what has been provided.
[1]
rte_ethdev.c, rte_eth_dev_configure():
if jumbo_frame == 1
if rxmode.max_rx_pkt_len > dev_info.max_rx_pktlen
return -EINVAL;
if rxmode.max_rx_pkt_len < ETHER_MIN_LEN
return -EINVAL;
else
if max_rx_pkt_len < ETHER_MIN_LEN || max_rx_pkt_len > ETHER_MAX_LEN
max_rx_pkt_len = ETHER_MAX_LEN
[2]
rte_ethdev.h, struct rte_eth_rxmode:
uint32_t max_rx_pkt_len; /**< Only used if jumbo_frame enabled. */
[3]
ixgbe, ixgbe_dev_mtu_set():
frame_size = mtu + ETHER_HDR_LEN + ETHER_CRC_LEN
if mtu < ETHER_MIN_MTU) || frame_size > dev_info.max_rx_pktlen
return -EINVAL
if frame_size > ETHER_MAX_LEN
jumbo_frame = 1
else
jumbo_frame = 0
max_rx_pkt_len = frame_size
i40e, i40e_dev_mtu_set():
frame_size = mtu + I40E_ETH_OVERHEAD
if mtu < ETHER_MIN_MTU) || frame_size > I40E_FRAME_SIZE_MAX
return -EINVAL
if frame_size > ETHER_MAX_LEN
jumbo_frame = 1
else
jumbo_frame = 0
max_rx_pkt_len = frame_size
[4]
rte_ethdev.h, struct rte_eth_dev_info:
uint32_t max_rx_pktlen; /**< Maximum configurable length of RX pkt. */
next prev parent reply other threads:[~2018-03-08 15:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-23 13:53 Olivier Matz
2018-01-23 14:34 ` Shahaf Shuler
2018-03-08 15:45 ` Ferruh Yigit [this message]
2019-12-10 18:07 ` Ferruh Yigit
2019-12-16 8:39 ` Andrew Rybchenko
2019-12-27 13:54 ` Olivier Matz
2019-12-27 14:23 ` Ananyev, Konstantin
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=717bd36b-a99b-e9f7-2603-f018f61a583f@intel.com \
--to=ferruh.yigit@intel.com \
--cc=arybchenko@solarflare.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@intel.com \
--cc=olivier.matz@6wind.com \
--cc=shahafs@mellanox.com \
--cc=thomas@monjalon.net \
/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).