DPDK patches and discussions
 help / color / mirror / Atom feed
From: Chaoyong He <chaoyong.he@corigine.com>
To: Ferruh Yigit <ferruh.yigit@amd.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: oss-drivers <oss-drivers@corigine.com>, Long Wu <Long.Wu@nephogine.com>
Subject: RE: [PATCH 1/2] ethdev: add Rx packet type offload control flag
Date: Tue, 24 Sep 2024 02:03:44 +0000	[thread overview]
Message-ID: <SJ0PR13MB55450E25BFDC4F69327CC9629E682@SJ0PR13MB5545.namprd13.prod.outlook.com> (raw)
In-Reply-To: <b3fa3ec1-aaa6-400a-b5ea-5024658dad3a@amd.com>

> On 6/19/2024 11:11 AM, Chaoyong He wrote:
> > From: Long Wu <long.wu@corigine.com>
> >
> > The Rx packet type offload feature may affect the performance, so add
> > a control flag for applications to turn it on or off.
> >
> > Signed-off-by: Long Wu <long.wu@corigine.com>
> > ---
> >  lib/ethdev/rte_ethdev.h | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index
> > 548fada1c7..be86983e24 100644
> > --- a/lib/ethdev/rte_ethdev.h
> > +++ b/lib/ethdev/rte_ethdev.h
> > @@ -1555,6 +1555,7 @@ struct rte_eth_conf {  #define
> > RTE_ETH_RX_OFFLOAD_OUTER_UDP_CKSUM  RTE_BIT64(18)
> >  #define RTE_ETH_RX_OFFLOAD_RSS_HASH         RTE_BIT64(19)
> >  #define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT     RTE_BIT64(20)
> > +#define RTE_ETH_RX_OFFLOAD_PTYPES           RTE_BIT64(21)
> >
> >  #define RTE_ETH_RX_OFFLOAD_CHECKSUM
> (RTE_ETH_RX_OFFLOAD_IPV4_CKSUM | \
> >  				 RTE_ETH_RX_OFFLOAD_UDP_CKSUM | \
> 
> Hi Chaoyong,
> 
> Instead of having an offload for ptypes, we have APIs for this,
> 
> First one is 'rte_eth_dev_get_supported_ptypes()' that application can learn
> the supported packet types.
> 
> Second one is more related to above flag, it is 'rte_eth_dev_set_ptypes()'
> which application can set which pytpes is required, it can be set to disable all
> packet type parsing, can be similar to not requesting
> 'RTE_ETH_RX_OFFLOAD_PTYPES'.
> 
> With above two APIs, do we still need the offload flag?
> 

At present, the purpose of the ops 'rte_eth_dev_set_ptypes()' is to set the range of packet types to handle.
Of course, we can maintain a flag for each application and driver based on the return value of this ops;
but this is a bit troublesome.
So, we hope to follow the example of RSS, in addition to
'rte_eth_dev_rss_hash_update()' and 'rte_eth_dev_rss_hash_conf_get()', we also want to set a flag for
the ptype function similar to RTE_ETH_RX_OFFLOAD_RSS_HASH.

> 
> Another concern with adding new offload flag is backward compatibility, all
> existing drivers that support packet type parsing should be updated to list this
> offload flag as capability. Also they need to be updated to configure packet
> parsing based on user requested offload configuration.
> 

If you agree with this design suggestion, we will adapt all the related code to ptypes for each PMDs and 'test-pmd' applications in the next patch.
Do you think this okay?

> Briefly, we can't just introduce a new offload flag for an existing capability and
> update only one driver, all drivers needs to be updated.

  reply	other threads:[~2024-09-24  2:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-19 10:11 [PATCH 0/2] " Chaoyong He
2024-06-19 10:11 ` [PATCH 1/2] ethdev: " Chaoyong He
2024-09-22 22:41   ` Ferruh Yigit
2024-09-24  2:03     ` Chaoyong He [this message]
2024-09-25 19:33       ` Ferruh Yigit
2024-09-26  2:15         ` Chaoyong He
2024-06-19 10:11 ` [PATCH 2/2] net/nfp: implement the device packet type set interface Chaoyong He
2024-09-26  7:16 ` [PATCH v2] " Chaoyong He
2024-09-27  0:49   ` Ferruh Yigit
2024-09-27  3:10   ` [PATCH v3] " Chaoyong He
2024-09-27 23:50     ` 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=SJ0PR13MB55450E25BFDC4F69327CC9629E682@SJ0PR13MB5545.namprd13.prod.outlook.com \
    --to=chaoyong.he@corigine.com \
    --cc=Long.Wu@nephogine.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=oss-drivers@corigine.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).