All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olivier Matz <olivier.matz@6wind.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org, Ajit Khaparde <ajit.khaparde@broadcom.com>,
	Jerin Jacob <jerin.jacob@caviumnetworks.com>,
	Shijith Thotton <shijith.thotton@cavium.com>,
	Santosh Shukla <santosh.shukla@caviumnetworks.com>,
	Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>,
	John Daley <johndale@cisco.com>,
	Wenzhuo Lu <wenzhuo.lu@intel.com>,
	Konstantin Ananyev <konstantin.ananyev@intel.com>,
	Beilei Xing <beilei.xing@intel.com>,
	Qi Zhang <qi.z.zhang@intel.com>,
	Jingjing Wu <jingjing.wu@intel.com>,
	Adrien Mazarguil <adrien.mazarguil@6wind.com>,
	Nelio Laranjeiro <nelio.laranjeiro@6wind.com>,
	Yongseok Koh <yskoh@mellanox.com>,
	Shahaf Shuler <shahafs@mellanox.com>,
	Tomasz Duszynski <tdu@semihalf.com>,
	Jianbo Liu <jianbo.liu@arm.com>,
	Alejandro Lucero <alejandro.lucero@netronome.com>,
	Hemant Agrawal <hemant.agrawal@nxp.com>,
	Shreyansh Jain <shreyansh.jain@nxp.com>,
	Harish Patil <harish.patil@cavium
Subject: Re: Survey for final decision about per-port offload API
Date: Wed, 11 Apr 2018 16:42:42 +0200	[thread overview]
Message-ID: <20180411144242.rkiavbycil3drwc2@platinum> (raw)
In-Reply-To: <2759953.P7QpFFSjiU@xps>

On Fri, Mar 30, 2018 at 03:47:55PM +0200, Thomas Monjalon wrote:
> There are some discussions about a specific part of the offload API:
> 	"To enable per-port offload, the offload should be set on both
> 	device configuration and queue setup."
> 
> It means the application must repeat the port offload flags
> in rte_eth_conf.[rt]xmode.offloads and rte_eth_[rt]xconf.offloads,
> when calling respectively rte_eth_dev_configure() and
> rte_eth_[rt]x_queue_setup for each queue.
> 
> The PMD must check if there is mismatch, i.e. a port offload not
> repeated in queue setup.
> There is a proposal to do this check at ethdev level:
> 	http://dpdk.org/ml/archives/dev/2018-March/094023.html
> 
> It was also proposed to relax the API and allow "forgetting" port
> offloads in queue offloads:
> 	http://dpdk.org/ml/archives/dev/2018-March/092978.html
> 
> It would mean the offloads applied to a queue result of OR operation:
> 	rte_eth_conf.[rt]xmode.offloads | rte_eth_[rt]xconf.offloads
> 
> 1/ Do you agree with above API change?

yes

> If we agree with this change, we need to update the documentation
> and remove the checks in PMDs.
> Note: no matter what is decided here, 18.05-rc1 should have all PMDs
> switched to the API which was defined in 17.11.
> Given that API is new and not yet adopted by the applications,
> the sonner it is fixed, the better.
> 
> 2/ Should we do this change in 18.05-rc2?

yes

> At the same time, we want to make clear that an offload enabled at
> port level, cannot be disabled at queue level.
> 
> 3/ Do you agree with above statement (to be added in the doc)?

yes

> There is the same kind of confusion in the offload capabilities:
> 	rte_eth_dev_info.[rt]x_offload_capa
> 	rte_eth_dev_info.[rt]x_queue_offload_capa
> The queue capabilities must be a subset of port capabilities,
> i.e. every queue capabilities must be reported as port capabilities.
> But the port capabilities should be reported at queue level
> only if it can be applied to a specific queue.
> 
> 4/ Do you agree with above statement (to be added in the doc)?

yes

  parent reply	other threads:[~2018-04-11 14:42 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-30 13:47 Survey for final decision about per-port offload API Thomas Monjalon
2018-03-30 15:13 ` Andrew Rybchenko
2018-03-30 15:46   ` Thomas Monjalon
2018-04-01  1:51 ` Zhang, Qi Z
2018-04-02 15:44   ` Thomas Monjalon
2018-04-01  4:44 ` Shahaf Shuler
2018-04-02 15:53   ` Thomas Monjalon
2018-04-03  5:19     ` Shahaf Shuler
2018-04-02  1:27 ` Lu, Wenzhuo
2018-04-02  3:18 ` Xing, Beilei
2018-04-02 17:23 ` Wu, Jingjing
2018-04-02 17:39 ` Patil, Harish
2018-04-02 20:10   ` Thomas Monjalon
2018-04-02 20:45     ` Patil, Harish
2018-04-03  0:53 ` Zhang, Qi Z
2018-04-03 19:59 ` John Daley (johndale)
2018-04-04  0:25 ` Yongseok Koh
2018-04-11 14:42 ` Olivier Matz [this message]
2018-04-11 15:17 ` Alejandro Lucero
2018-04-12  5:41 ` Jerin Jacob
2018-04-12  7:03 ` Maxime Coquelin
2018-04-12  9:08 ` Shreyansh Jain
2018-04-24 10:39 ` Ferruh Yigit
2018-04-24 11:08   ` Ananyev, Konstantin
2018-04-24 12:27     ` Ferruh Yigit
2018-04-24 15:20       ` Ananyev, Konstantin
2018-04-24 16:18         ` Ferruh Yigit
2018-04-24 12:56   ` Shahaf Shuler
2018-04-24 22:00   ` Thomas Monjalon
2018-04-25 13:32     ` Ferruh Yigit
2018-04-25 15:21       ` Thomas Monjalon
2018-04-25 16:45       ` 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=20180411144242.rkiavbycil3drwc2@platinum \
    --to=olivier.matz@6wind.com \
    --cc=adrien.mazarguil@6wind.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=alejandro.lucero@netronome.com \
    --cc=beilei.xing@intel.com \
    --cc=dev@dpdk.org \
    --cc=harish.patil@cavium \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=jianbo.liu@arm.com \
    --cc=jingjing.wu@intel.com \
    --cc=johndale@cisco.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=nelio.laranjeiro@6wind.com \
    --cc=qi.z.zhang@intel.com \
    --cc=rahul.lakkireddy@chelsio.com \
    --cc=santosh.shukla@caviumnetworks.com \
    --cc=shahafs@mellanox.com \
    --cc=shijith.thotton@cavium.com \
    --cc=shreyansh.jain@nxp.com \
    --cc=tdu@semihalf.com \
    --cc=thomas@monjalon.net \
    --cc=wenzhuo.lu@intel.com \
    --cc=yskoh@mellanox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.