From: Shahaf Shuler <shahafs@mellanox.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>,
Neil Horman <nhorman@tuxdriver.com>,
John McNamara <john.mcnamara@intel.com>,
"Marko Kovacevic" <marko.kovacevic@intel.com>,
Thomas Monjalon <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2 2/2] ethdev: add new offload flag to keep CRC
Date: Thu, 29 Mar 2018 05:38:02 +0000 [thread overview]
Message-ID: <DB7PR05MB4426A99C0E4907BBF0E24761C3A20@DB7PR05MB4426.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <20180321194730.52068-2-ferruh.yigit@intel.com>
Wednesday, March 21, 2018 9:48 PM, Ferruh Yigit:
> DEV_RX_OFFLOAD_KEEP_CRC offload flag added.
>
> DEV_RX_OFFLOAD_CRC_STRIP flag will remain one more release but default
> behavior in PMDs is to strip the CRC independent from this flag.
>
> Until DEV_RX_OFFLOAD_CRC_STRIP flag is removed:
> - Setting both KEEP_CRC & CRC_STRIP is INVALID
> - Setting only CRC_STRIP PMD should strip the CRC
> - Setting only KEEP_CRC PMD should keep the CRC
> - Not setting both PMD should strip the CRC
We cannot have such default behavior, it may break existing applications.
The API of ethdev offloads says (even though it is not well documented) : DEV_RX_OFFLOAD_CRC_STRIP (emphasis the STRIP).
meaning, if set -> STRIP, if not set -> don't strip. I am aware to at least one application which wants to have the CRC, and for that purpose it naturally don't set the offload flag.
The fact some PMDs lack the ability to toggle the CRC stripping should be exposed in the "limitations" section of their related guide.
Up to here, this is the behavior as defined by the API.
Now, we want to change it, and I think it makes sense. However I think we should take similar approach to what we did with the ethdev offloads API:
1. at first stage a new offload flag is exposed DEV_RX_OFFLOAD_KEEP_CRC and implemented on the PMDs.
2. there is a conversion function on ethdev. Which for example converts ~DEV_RX_OFFLOAD_CRC_STRIP -> DEV_RX_OFFLOAD_KEEP_CRC for the PMDs.
3. deprecation of DEV_RX_OFFLOAD_CRC_STRIP for applications and remove of the conversion functions.
More below,
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> ---
> lib/librte_ether/rte_ethdev.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> index 5e13dca6a..ab1030d42 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -939,6 +939,9 @@ struct rte_eth_conf {
> #define DEV_RX_OFFLOAD_SCATTER 0x00002000
> #define DEV_RX_OFFLOAD_TIMESTAMP 0x00004000
> #define DEV_RX_OFFLOAD_SECURITY 0x00008000
> +/* Invalid to set both DEV_RX_OFFLOAD_CRC_STRIP and
> +DEV_RX_OFFLOAD_KEEP_CRC
> + * No DEV_RX_OFFLOAD_CRC_STRIP flag means stripping CRC */
> +#define DEV_RX_OFFLOAD_KEEP_CRC 0x00010000
Need also comment on DEV_RX_OFFLOAD_CRC_STRIP to say it is deprecated.
> #define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM |
> \
> DEV_RX_OFFLOAD_UDP_CKSUM | \
> DEV_RX_OFFLOAD_TCP_CKSUM)
> --
> 2.13.6
next prev parent reply other threads:[~2018-03-29 5:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-20 11:26 [dpdk-dev] [PATCH] doc: announce ethdev CRC strip flag deprecation Ferruh Yigit
2018-03-20 11:35 ` Thomas Monjalon
2018-03-20 17:23 ` Ferruh Yigit
2018-03-21 19:47 ` [dpdk-dev] [PATCH v2 1/2] " Ferruh Yigit
2018-03-21 19:47 ` [dpdk-dev] [PATCH v2 2/2] ethdev: add new offload flag to keep CRC Ferruh Yigit
2018-03-21 21:05 ` Thomas Monjalon
2018-03-29 5:38 ` Shahaf Shuler [this message]
2018-03-29 7:43 ` Thomas Monjalon
2018-03-29 7:56 ` Shahaf Shuler
2018-03-29 13:32 ` Ferruh Yigit
2018-04-01 7:10 ` Shahaf Shuler
2018-04-16 17:23 ` Ferruh Yigit
2018-04-16 22:13 ` Thomas Monjalon
2018-04-17 13:12 ` [dpdk-dev] [PATCH v3] doc: announce ethdev CRC strip flag deprecation Ferruh Yigit
2018-04-17 13:31 ` Andrew Rybchenko
2018-04-17 13:36 ` Ferruh Yigit
2018-04-17 13:39 ` [dpdk-dev] [PATCH v4] " Ferruh Yigit
2018-04-17 13:47 ` Shahaf Shuler
2018-05-28 1:05 ` Thomas Monjalon
2018-08-01 15:27 ` Maxime Coquelin
2018-08-02 8:50 ` Shahaf Shuler
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=DB7PR05MB4426A99C0E4907BBF0E24761C3A20@DB7PR05MB4426.eurprd05.prod.outlook.com \
--to=shahafs@mellanox.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=john.mcnamara@intel.com \
--cc=marko.kovacevic@intel.com \
--cc=nhorman@tuxdriver.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).