[dpdk-dev] Survey for final decision about per-port offload API

[dpdk-dev] Survey for final decision about per-port offload API

[Thomas Monjalon]

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?


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?


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)?


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)?


Please give your opinion on questions 1, 2, 3 and 4.
Answering by yes/no may be sufficient in most cases :)
Thank you

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Andrew Rybchenko]

On 03/30/2018 04:47 PM, 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, may be it would be good to be more precise what "can be applied" mean.
As I understand it is "can be enabled on queue when it is disabled on 
port level".

Andrew.

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Thomas Monjalon]

30/03/2018 17:13, Andrew Rybchenko:
> On 03/30/2018 04:47 PM, Thomas Monjalon wrote:
> > 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, may be it would be good to be more precise what "can be applied" mean.
> As I understand it is "can be enabled on queue when it is disabled on 
> port level".

Yes, "can be applied to a specific queue" means
"can be enabled on queue when it is disabled on port level".

Thanks for answering the survey.

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Zhang, Qi Z]

Hi Thomas:
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Friday, March 30, 2018 9:48 PM
> To: dev@dpdk.org
> Cc: 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>; Lu,
> Wenzhuo <wenzhuo.lu@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; Xing, Beilei <beilei.xing@intel.com>; Zhang,
> Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <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.com>; Rasesh Mody
> <rasesh.mody@cavium.com>; Andrew Rybchenko
> <arybchenko@solarflare.com>; Shrikrishna Khare <skhare@vmware.com>;
> Maxime Coquelin <maxime.coquelin@redhat.com>; Legacy, Allain (Wind River)
> <allain.legacy@windriver.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; Gaetan Rivet <gaetan.rivet@6wind.com>;
> Olivier Matz <olivier.matz@6wind.com>
> Subject: Survey for final decision about per-port offload API
> 
> 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?
> 
> 
> If we agree with this change, we need to update the documentation and
> remove the checks in PMDs.

Do you mean we will move offload check from PMD to ethdev, 
or just remove specific check in each PMD
or it is not in the scope of this vote?

Thanks
Qi

> 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?

> 
> 
> 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)?
> 
> 
> 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

> 
> 
> Please give your opinion on questions 1, 2, 3 and 4.
> Answering by yes/no may be sufficient in most cases :) Thank you
> 

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Shahaf Shuler]

Friday, March 30, 2018 4:48 PM, Thomas Monjalon:
> Subject: Survey for final decision about per-port offload API
> 
> 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:
> 	https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F
> %2Fdpdk.org%2Fml%2Farchives%2Fdev%2F2018-
> March%2F094023.html&data=02%7C01%7Cshahafs%40mellanox.com%7Cb2a
> e36d768424c9e616308d59644e2a7%7Ca652971c7d2e4d9ba6a4d149256f461b
> %7C0%7C0%7C636580144980414466&sdata=Re2xM9u5jJr4M1PDTn5gE9mp22
> NmBI%2Bwa2GFPmUzq38%3D&reserved=0
> 
> It was also proposed to relax the API and allow "forgetting" port offloads in
> queue offloads:
> 	https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F
> %2Fdpdk.org%2Fml%2Farchives%2Fdev%2F2018-
> March%2F092978.html&data=02%7C01%7Cshahafs%40mellanox.com%7Cb2a
> e36d768424c9e616308d59644e2a7%7Ca652971c7d2e4d9ba6a4d149256f461b
> %7C0%7C0%7C636580144980414466&sdata=xaUM8jcVl9gf3e%2By9geZDPpO
> 1RJ5%2FXWJwA%2BpGp54pNs%3D&reserved=0
> 
> 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.

And to update applications and examples in the tree to set the offloads according to above change. 

> 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?
> 
> 
> 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)?

No. 

The documentation should describe the API from the application side, and not provide guidelines for the PMDs implementation. 
If missing, we should clarify more about what queue and port offload means. Something like:
"When port offload is enabled, the offload applies on the port along with all of its associated queues"  and
"When queue offload is enabled the offload, the offload applies only on the specific queue."

The PMDs then will decide how they report the different offloads they offer. 

> 
> 
> Please give your opinion on questions 1, 2, 3 and 4.
> Answering by yes/no may be sufficient in most cases :) Thank you
> 

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Lu, Wenzhuo]

Hi,

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Friday, March 30, 2018 9:48 PM
> To: dev@dpdk.org
> Cc: 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>; Lu,
> Wenzhuo <wenzhuo.lu@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; Xing, Beilei <beilei.xing@intel.com>;
> Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <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.com>; Rasesh Mody
> <rasesh.mody@cavium.com>; Andrew Rybchenko
> <arybchenko@solarflare.com>; Shrikrishna Khare <skhare@vmware.com>;
> Maxime Coquelin <maxime.coquelin@redhat.com>; Legacy, Allain (Wind
> River) <allain.legacy@windriver.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; Gaetan Rivet <gaetan.rivet@6wind.com>;
> Olivier Matz <olivier.matz@6wind.com>
> Subject: Survey for final decision about per-port offload API
> 
> 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.

> 
> 
> Please give your opinion on questions 1, 2, 3 and 4.
> Answering by yes/no may be sufficient in most cases :) Thank you
> 

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Xing, Beilei]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Friday, March 30, 2018 9:48 PM
> To: dev@dpdk.org
> Cc: 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>; Lu,
> Wenzhuo <wenzhuo.lu@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; Xing, Beilei <beilei.xing@intel.com>;
> Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <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.com>; Rasesh Mody
> <rasesh.mody@cavium.com>; Andrew Rybchenko
> <arybchenko@solarflare.com>; Shrikrishna Khare <skhare@vmware.com>;
> Maxime Coquelin <maxime.coquelin@redhat.com>; Legacy, Allain (Wind
> River) <allain.legacy@windriver.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; Gaetan Rivet <gaetan.rivet@6wind.com>;
> Olivier Matz <olivier.matz@6wind.com>
> Subject: Survey for final decision about per-port offload API
> 
> 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.

> 
> 
> Please give your opinion on questions 1, 2, 3 and 4.
> Answering by yes/no may be sufficient in most cases :) Thank you
> 

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Thomas Monjalon]

01/04/2018 03:51, Zhang, Qi Z:
> > 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?
> > 
> > 
> > If we agree with this change, we need to update the documentation and
> > remove the checks in PMDs.
> 
> Do you mean we will move offload check from PMD to ethdev, 
> or just remove specific check in each PMD
> or it is not in the scope of this vote?

By "remove the checks", I mean removing the checks in each PMD
for the port offloads repeated in queue offloads.

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Thomas Monjalon]

01/04/2018 06:44, Shahaf Shuler:
> > 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)?
> 
> No. 
> 
> The documentation should describe the API from the application side, and not provide guidelines for the PMDs implementation. 
> If missing, we should clarify more about what queue and port offload means. Something like:
> "When port offload is enabled, the offload applies on the port along with all of its associated queues"  and
> "When queue offload is enabled the offload, the offload applies only on the specific queue."
> 
> The PMDs then will decide how they report the different offloads they offer. 

I don't understand why you want to be free in capabilities implementation.
If the capabilities are not strictly standardized, how can they be used
by the application?

Rewording from application point of view:

All the offload capabilities (port-level and queue-level) are reported in rte_eth_dev_info.[rt]x_offload_capa.
The offloads reported in rte_eth_dev_info.[rt]x_queue_offload_capa can be applied to a specific queue.

Is it OK?

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Wu, Jingjing]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Friday, March 30, 2018 6:48 AM
> To: dev@dpdk.org
> Cc: 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>; Lu, Wenzhuo
> <wenzhuo.lu@intel.com>; Ananyev, Konstantin <konstantin.ananyev@intel.com>; Xing,
> Beilei <beilei.xing@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing
> <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.com>; Rasesh Mody
> <rasesh.mody@cavium.com>; Andrew Rybchenko <arybchenko@solarflare.com>;
> Shrikrishna Khare <skhare@vmware.com>; Maxime Coquelin
> <maxime.coquelin@redhat.com>; Legacy, Allain (Wind River)
> <allain.legacy@windriver.com>; Richardson, Bruce <bruce.richardson@intel.com>;
> Gaetan Rivet <gaetan.rivet@6wind.com>; Olivier Matz <olivier.matz@6wind.com>
> Subject: Survey for final decision about per-port offload API
> 
> 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
 
Thanks
Jingjing

> Please give your opinion on questions 1, 2, 3 and 4.
> Answering by yes/no may be sufficient in most cases :)
> Thank you
> 

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Patil, Harish]

-----Original Message-----
From: Thomas Monjalon <thomas@monjalon.net>
Date: Friday, March 30, 2018 at 6:47 AM
To: "dev@dpdk.org" <dev@dpdk.org>
Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>, "Jacob,  Jerin"
<Jerin.JacobKollanukkaran@cavium.com>, "Thotton, Shijith"
<Shijith.Thotton@cavium.com>, "Shukla, Santosh"
<Santosh.Shukla@cavium.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.com>, "Mody, Rasesh" <Rasesh.Mody@cavium.com>, Andrew
Rybchenko <arybchenko@solarflare.com>, Shrikrishna Khare
<skhare@vmware.com>, Maxime Coquelin <maxime.coquelin@redhat.com>, Allain
Legacy <allain.legacy@windriver.com>, Bruce Richardson
<bruce.richardson@intel.com>, Gaetan Rivet <gaetan.rivet@6wind.com>,
Olivier Matz <olivier.matz@6wind.com>
Subject: Survey for final decision about per-port offload API

>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. But pls confirm that this would still work properly if RX supports
port-only based offloads and doesn’t support queue based offloads at all,
as advertised in dev_infos_get().

dev_info->rx_queue_offload_capa = 0 and
dev_info->rx_offload_capa = (DEV_RX_OFFLOAD_IPV4_CKSUM | ...);


>
>
>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
>
>
>Please give your opinion on questions 1, 2, 3 and 4.
>Answering by yes/no may be sufficient in most cases :)
>Thank you
>
>

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Thomas Monjalon]

02/04/2018 19:39, Patil, Harish:
> >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. But pls confirm that this would still work properly if RX supports
> port-only based offloads and doesn’t support queue based offloads at all,
> as advertised in dev_infos_get().
> 
> dev_info->rx_queue_offload_capa = 0 and
> dev_info->rx_offload_capa = (DEV_RX_OFFLOAD_IPV4_CKSUM | ...);

Yes, of course, no queue offload at all is possible.

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Patil, Harish]

-----Original Message-----
From: Thomas Monjalon <thomas@monjalon.net>
Date: Monday, April 2, 2018 at 1:10 PM
To: Harish Patil <Harish.Patil@cavium.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Ajit Khaparde
<ajit.khaparde@broadcom.com>, "Jacob,  Jerin"
<Jerin.JacobKollanukkaran@cavium.com>, "Thotton, Shijith"
<Shijith.Thotton@cavium.com>, "Shukla, Santosh"
<Santosh.Shukla@cavium.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>, "Mody, Rasesh"
<Rasesh.Mody@cavium.com>, Andrew Rybchenko <arybchenko@solarflare.com>,
Shrikrishna Khare <skhare@vmware.com>, Maxime Coquelin
<maxime.coquelin@redhat.com>, Allain Legacy <allain.legacy@windriver.com>,
Bruce Richardson <bruce.richardson@intel.com>, Gaetan Rivet
<gaetan.rivet@6wind.com>, Olivier Matz <olivier.matz@6wind.com>
Subject: Re: Survey for final decision about per-port offload API

>02/04/2018 19:39, Patil, Harish:
>> >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. But pls confirm that this would still work properly if RX supports
>> port-only based offloads and doesn’t support queue based offloads at
>>all,
>> as advertised in dev_infos_get().
>> 
>> dev_info->rx_queue_offload_capa = 0 and
>> dev_info->rx_offload_capa = (DEV_RX_OFFLOAD_IPV4_CKSUM | ...);
>
>Yes, of course, no queue offload at all is possible.
>
Okay, thanks.
>

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Zhang, Qi Z]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Friday, March 30, 2018 9:48 PM
> To: dev@dpdk.org
> Cc: 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>; Lu,
> Wenzhuo <wenzhuo.lu@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; Xing, Beilei <beilei.xing@intel.com>; Zhang,
> Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <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.com>; Rasesh Mody
> <rasesh.mody@cavium.com>; Andrew Rybchenko
> <arybchenko@solarflare.com>; Shrikrishna Khare <skhare@vmware.com>;
> Maxime Coquelin <maxime.coquelin@redhat.com>; Legacy, Allain (Wind River)
> <allain.legacy@windriver.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; Gaetan Rivet <gaetan.rivet@6wind.com>;
> Olivier Matz <olivier.matz@6wind.com>
> Subject: Survey for final decision about per-port offload API
> 
> 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, 
looks like a also good chance to move offload check into ethdev layer, 
the common logic no need to be repeated in each PMD

> 
> 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
> 
> Please give your opinion on questions 1, 2, 3 and 4.
> Answering by yes/no may be sufficient in most cases :) Thank you
> 

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Shahaf Shuler]

Monday, April 2, 2018 6:54 PM, Thomas Monjalon:
> 01/04/2018 06:44, Shahaf Shuler:
> > > 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)?
> >
> > No.
> >
> > The documentation should describe the API from the application side, and
> not provide guidelines for the PMDs implementation.
> > If missing, we should clarify more about what queue and port offload
> means. Something like:
> > "When port offload is enabled, the offload applies on the port along
> > with all of its associated queues"  and "When queue offload is enabled the
> offload, the offload applies only on the specific queue."
> >
> > The PMDs then will decide how they report the different offloads they
> offer.
> 
> I don't understand why you want to be free in capabilities implementation.
> If the capabilities are not strictly standardized, how can they be used by the
> application?

They are standardize, according to the API. the rules of the APIs are:
1. port offload is applied to the port and all of its queues.
2. queue offload is applied only to the specific queue. 

The two above are enough for the PMDs to understand how they should set the offloads.
We don't need to describe in the API that every queue offload is a port offload (maybe there is some unreasonable limitation to some PMD to do so). 

> 
> Rewording from application point of view:
> 
> All the offload capabilities (port-level and queue-level) are reported in
> rte_eth_dev_info.[rt]x_offload_capa.
> The offloads reported in rte_eth_dev_info.[rt]x_queue_offload_capa can
> be applied to a specific queue.
> 
> Is it OK?

I think all we need is statements 1 and 2 above. However, I will not insist about this one too much. 

As a general statement, for any API that we will do, we should have a clear distinction between "API definition" and "PMD guidelines for implementation" 
The API definition should have the most exact rules for the **application** to understand how to work. 

On the example above, the application doesn't care every port offload is queue offload (this is PMD guideline). It only cares about 1 and 2. This is what defines to it how to use the offloads API. 


> 

Re: [dpdk-dev] Survey for final decision about per-port offload API

[John Daley (johndale)]

Hi,
Inline.
Thanks,
John

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Friday, March 30, 2018 6:48 AM
> To: dev@dpdk.org
> Cc: 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) <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.com>; Rasesh Mody
> <rasesh.mody@cavium.com>; Andrew Rybchenko
> <arybchenko@solarflare.com>; Shrikrishna Khare <skhare@vmware.com>;
> Maxime Coquelin <maxime.coquelin@redhat.com>; Allain Legacy
> <allain.legacy@windriver.com>; Bruce Richardson
> <bruce.richardson@intel.com>; Gaetan Rivet <gaetan.rivet@6wind.com>;
> Olivier Matz <olivier.matz@6wind.com>
> Subject: Survey for final decision about per-port offload API
> 
> 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
> 
> 
> Please give your opinion on questions 1, 2, 3 and 4.
> Answering by yes/no may be sufficient in most cases :) Thank you
> 

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Yongseok Koh]

> On Mar 30, 2018, at 6:47 AM, Thomas Monjalon <thomas@monjalon.net> 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:
> 	https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdpdk.org%2Fml%2Farchives%2Fdev%2F2018-March%2F094023.html&data=02%7C01%7Cyskoh%40mellanox.com%7Cb2ae36d768424c9e616308d59644e2a7%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636580144979633174&sdata=pGxkC6H78h%2BaSVOYRjMguOu%2B1xIrzW7YbCfohmE8uvs%3D&reserved=0
> 
> It was also proposed to relax the API and allow "forgetting" port
> offloads in queue offloads:
> 	https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdpdk.org%2Fml%2Farchives%2Fdev%2F2018-March%2F092978.html&data=02%7C01%7Cyskoh%40mellanox.com%7Cb2ae36d768424c9e616308d59644e2a7%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636580144979633174&sdata=MrHYsw6MRliU1IfBulcNxvKNX1JNrOrcs1NVIuK72ec%3D&reserved=0
> 
> 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


Thanks,
Yongseok

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Olivier Matz]

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

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Alejandro Lucero]

Hi

On Fri, Mar 30, 2018 at 3:47 PM, Thomas Monjalon <thomas@monjalon.net>
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


>
> Please give your opinion on questions 1, 2, 3 and 4.
> Answering by yes/no may be sufficient in most cases :)
> Thank you
>
>
>
Thanks

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Jerin Jacob]

-----Original Message-----
> Date: Fri, 30 Mar 2018 15:47:55 +0200
> From: Thomas Monjalon <thomas@monjalon.net>
> To: dev@dpdk.org
> Cc: 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.com>, Rasesh Mody <rasesh.mody@cavium.com>, Andrew
>  Rybchenko <arybchenko@solarflare.com>, Shrikrishna Khare
>  <skhare@vmware.com>, Maxime Coquelin <maxime.coquelin@redhat.com>, Allain
>  Legacy <allain.legacy@windriver.com>, Bruce Richardson
>  <bruce.richardson@intel.com>, Gaetan Rivet <gaetan.rivet@6wind.com>,
>  Olivier Matz <olivier.matz@6wind.com>
> Subject: Survey for final decision about per-port offload API
> 
> 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

> 
> 
> Please give your opinion on questions 1, 2, 3 and 4.
> Answering by yes/no may be sufficient in most cases :)
> Thank you
> 
> 

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Maxime Coquelin]

Hi Thomas,

On 03/30/2018 03:47 PM, 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


> Please give your opinion on questions 1, 2, 3 and 4.
> Answering by yes/no may be sufficient in most cases :)
> Thank you
> 
> 


Thanks,
Maxime

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Shreyansh Jain]

On Friday 30 March 2018 07:17 PM, 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
> 

With respect to DPAA and DPAA2 PMDs:

> 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

> 
> 
> Please give your opinion on questions 1, 2, 3 and 4.
> Answering by yes/no may be sufficient in most cases :)
> Thank you
> 
> 

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Ferruh Yigit]

On 3/30/2018 2:47 PM, 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?

There is a detail of ability to disabling queue level offloads in queue_setup()
function, I want to discuss here.

Prolog:
port level offload: An offload only can be applied port level, to all queues.
queue level offload: An offload can be applied into individual queues of the port

PMD reports port offload capability: port level offload + queue level offload
PMD reports queue offload capability: queue level offload


Above suggested change to API:
- Application will be limited in configure() to set only an offload within "port
offload capability"
- Application will be limited in queue_setup() to set only an offload within
"queue offload capability"


This doesn't say much about disabling an offload in queue_setup(), as a rule:
- An "port level offload" can't be disabled in queue_setup()


There are two cases of disable:
1- Disabling a "queue level offload" enabled queue_setup() previously
2- Disabling a "queue level offload" enabled in configure()

If second is not supported, to disable the offload, applications should
stop->re-configure()->re-queue_setup()->start the port. But having this
capability makes the offloading parameters more confusing for applications.


I suggest adding disable support to fist one but not second one.

According this,
application:
- In configure() set offload within "port offload capability"
- In queue_setup() set offload within "queue offload capability". Offloads are
incremental to ones in configure()

PMDs:
- In configure() verify the offload against "port offload capability"
- In queue_setup() verify the offload against "queue offload capability"
- In queue_setup() if requested offload is not enabled already, enable it for queue
- In queue_setup() if an offload value cleared in requested offload that is set
in port_offload, return error.
- In queue_setup() if an offload value cleared in requested offload that is not
set in port_offload but set in queue_offload, disable it for that queue.


Samples according initial suggestion + disable support:

Sample 1:
port level offload: A, B
queue level offload: C, D
port offload capability: A, B, C, D
queue offload capability: C, D

configure(A,C): Q1:A,C  Q2:A,C [queue_setup() can't disable A,C after this]
queue_setup(Q1, B): --> Error [Can't enable port level offload in queue_setup()]
queue_setup(Q1, D): Q1:A,C,D
queue_setup(Q1, ""): Q1:A,C [Disabled D]
queue_setup(Q2, "C,D"): Q2:A,C,D
queue_setup(Q2, ""): Q2:A,C
queue_setup(Q2, A): --> Error [A is port_level offload]


Sample 2:
port level offload: A, B, C
queue level offload: ""
port offload capability: A, B, C
queue offload capability: ""   [no way to change offloads in queue level]

configure(A,C): Q1:A,C  Q2:A,C
queue_setup(Q1, B): --> Error
queue_setup(Q1, A): --> Error
queue_setup(Q2, ""): Q2:A,C
queue_setup(Q1, ""): Q1:A,C


Sample 3:
port level offload: ""
queue level offload: A, B, C, D
port offload capability: A, B, C, D
queue offload capability: A, B, C, D

configure(A): Q1:A  Q2:A
queue_setup(Q1, A): Q1:A
queue_setup(Q1, ""): Q1:A
queue_setup(Q1, A,B,C,D): Q1:A,B,C,D
queue_setup(Q1, B): Q1:A,B [Disable C,D]
queue_setup(Q2, C): Q2:A,C
queue_setup(Q1, ""): Q1:A [Disable B]
queue_setup(Q2, ""): Q2:A [Disable C]

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Ananyev, Konstantin]

Hi Ferruh,

> 
> On 3/30/2018 2:47 PM, 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?
> 
> There is a detail of ability to disabling queue level offloads in queue_setup()
> function, I want to discuss here.
> 
> Prolog:
> port level offload: An offload only can be applied port level, to all queues.
> queue level offload: An offload can be applied into individual queues of the port
> 
> PMD reports port offload capability: port level offload + queue level offload
> PMD reports queue offload capability: queue level offload
> 
> 
> Above suggested change to API:
> - Application will be limited in configure() to set only an offload within "port
> offload capability"
> - Application will be limited in queue_setup() to set only an offload within
> "queue offload capability"
> 
> 
> This doesn't say much about disabling an offload in queue_setup(), as a rule:
> - An "port level offload" can't be disabled in queue_setup()
> 
> 
> There are two cases of disable:
> 1- Disabling a "queue level offload" enabled queue_setup() previously
> 2- Disabling a "queue level offload" enabled in configure()
> 
> If second is not supported, to disable the offload, applications should
> stop->re-configure()->re-queue_setup()->start the port. But having this
> capability makes the offloading parameters more confusing for applications.
> 
> 
> I suggest adding disable support to fist one but not second one.

Not sure why to introduce such limitation?
Konstantin

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Ferruh Yigit]

On 4/24/2018 12:08 PM, Ananyev, Konstantin wrote:
> Hi Ferruh,
> 
>>
>> On 3/30/2018 2:47 PM, 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?
>>
>> There is a detail of ability to disabling queue level offloads in queue_setup()
>> function, I want to discuss here.
>>
>> Prolog:
>> port level offload: An offload only can be applied port level, to all queues.
>> queue level offload: An offload can be applied into individual queues of the port
>>
>> PMD reports port offload capability: port level offload + queue level offload
>> PMD reports queue offload capability: queue level offload
>>
>>
>> Above suggested change to API:
>> - Application will be limited in configure() to set only an offload within "port
>> offload capability"
>> - Application will be limited in queue_setup() to set only an offload within
>> "queue offload capability"
>>
>>
>> This doesn't say much about disabling an offload in queue_setup(), as a rule:
>> - An "port level offload" can't be disabled in queue_setup()
>>
>>
>> There are two cases of disable:
>> 1- Disabling a "queue level offload" enabled queue_setup() previously
>> 2- Disabling a "queue level offload" enabled in configure()
>>
>> If second is not supported, to disable the offload, applications should
>> stop->re-configure()->re-queue_setup()->start the port. But having this
>> capability makes the offloading parameters more confusing for applications.
>>
>>
>> I suggest adding disable support to fist one but not second one.
> 
> Not sure why to introduce such limitation?

Not supporting second one?

To differentiate disable request for that case is harder. How can we say to
disable a "queue level offloads" enabled by configure()?

It may be by setting these offloads in queue_setup() as well and when any
offload is missing in queue_setup() it can be taken as disable request. This
forces applications to duplicate/set "queue level offloads" enabled by
configure() in the queue_setup() function by default.

This is an option, but my concern was to this may be harder to manage by
applications.
An application will have to remove "port level offload" from port_offloads and
feed it into each queue_setup().

Also this is closer to existing API but not same, the difference is
queue_setup() doesn't get "port level offload"

We can go with this one if there is a requirement for it.

And if we prefer to go with this option, perhaps we can think twice about
changing exiting API because this will be very close the existing API. Only
logically it is not correct to force application to set some offloads in
queue_setup() for the PMD that doesn't support queue offload at all, this can be
handled in PMD, and saves us of all the trouble of the change.


> Konstantin
> 

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Shahaf Shuler]

Tuesday, April 24, 2018 1:39 PM, Ferruh Yigit:
> Subject: Re: [dpdk-dev] Survey for final decision about per-port offload API
> 
> On 3/30/2018 2:47 PM, 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:
> >
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdpd
> k
> > .org%2Fml%2Farchives%2Fdev%2F2018-
> March%2F094023.html&data=02%7C01%7Cs
> >
> hahafs%40mellanox.com%7C3d6dec1702a344bbfa0708d5a9cfacad%7Ca65297
> 1c7d2
> >
> e4d9ba6a4d149256f461b%7C0%7C0%7C636601631811623875&sdata=LVYRf4B
> i1lh9E
> > u8M9zwgBxdlKI7V0YYsx2%2FvfCim2tU%3D&reserved=0
> >
> > It was also proposed to relax the API and allow "forgetting" port
> > offloads in queue offloads:
> >
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdpd
> k
> > .org%2Fml%2Farchives%2Fdev%2F2018-
> March%2F092978.html&data=02%7C01%7Cs
> >
> hahafs%40mellanox.com%7C3d6dec1702a344bbfa0708d5a9cfacad%7Ca65297
> 1c7d2
> >
> e4d9ba6a4d149256f461b%7C0%7C0%7C636601631811623875&sdata=8V4DdP
> uIIGpxW
> > 8i7AtaB1aB536JC6X6cqdSwaQOMRIo%3D&reserved=0
> >
> > 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?
> 
> There is a detail of ability to disabling queue level offloads in queue_setup()
> function, I want to discuss here.
> 
> Prolog:
> port level offload: An offload only can be applied port level, to all queues.
> queue level offload: An offload can be applied into individual queues of the
> port
> 
> PMD reports port offload capability: port level offload + queue level offload
> PMD reports queue offload capability: queue level offload
> 
> 
> Above suggested change to API:
> - Application will be limited in configure() to set only an offload within "port
> offload capability"
> - Application will be limited in queue_setup() to set only an offload within
> "queue offload capability"
> 
> 
> This doesn't say much about disabling an offload in queue_setup(), as a rule:
> - An "port level offload" can't be disabled in queue_setup()
> 
> 
> There are two cases of disable:
> 1- Disabling a "queue level offload" enabled queue_setup() previously
> 2- Disabling a "queue level offload" enabled in configure()
> 
> If second is not supported, to disable the offload, applications should
> stop->re-configure()->re-queue_setup()->start the port. But having this
> capability makes the offloading parameters more confusing for applications.
> 
> 
> I suggest adding disable support to fist one but not second one.
> 
> According this,
> application:
> - In configure() set offload within "port offload capability"
> - In queue_setup() set offload within "queue offload capability". Offloads are
> incremental to ones in configure()
> 
> PMDs:
> - In configure() verify the offload against "port offload capability"
> - In queue_setup() verify the offload against "queue offload capability"
> - In queue_setup() if requested offload is not enabled already, enable it for
> queue
> - In queue_setup() if an offload value cleared in requested offload that is set
> in port_offload, return error.
> - In queue_setup() if an offload value cleared in requested offload that is not
> set in port_offload but set in queue_offload, disable it for that queue.
> 
> 

In other words - queue configuration can effect queue offloads and port configuration can effect port offloads.

I am OK with that. 


> Samples according initial suggestion + disable support:
> 
> Sample 1:
> port level offload: A, B
> queue level offload: C, D
> port offload capability: A, B, C, D
> queue offload capability: C, D
> 
> configure(A,C): Q1:A,C  Q2:A,C [queue_setup() can't disable A,C after this]
> queue_setup(Q1, B): --> Error [Can't enable port level offload in
> queue_setup()] queue_setup(Q1, D): Q1:A,C,D queue_setup(Q1, ""): Q1:A,C
> [Disabled D] queue_setup(Q2, "C,D"): Q2:A,C,D queue_setup(Q2, ""): Q2:A,C
> queue_setup(Q2, A): --> Error [A is port_level offload]
> 
> 
> Sample 2:
> port level offload: A, B, C
> queue level offload: ""
> port offload capability: A, B, C
> queue offload capability: ""   [no way to change offloads in queue level]
> 
> configure(A,C): Q1:A,C  Q2:A,C
> queue_setup(Q1, B): --> Error
> queue_setup(Q1, A): --> Error
> queue_setup(Q2, ""): Q2:A,C
> queue_setup(Q1, ""): Q1:A,C
> 
> 
> Sample 3:
> port level offload: ""
> queue level offload: A, B, C, D
> port offload capability: A, B, C, D
> queue offload capability: A, B, C, D
> 
> configure(A): Q1:A  Q2:A
> queue_setup(Q1, A): Q1:A
> queue_setup(Q1, ""): Q1:A
> queue_setup(Q1, A,B,C,D): Q1:A,B,C,D
> queue_setup(Q1, B): Q1:A,B [Disable C,D] queue_setup(Q2, C): Q2:A,C
> queue_setup(Q1, ""): Q1:A [Disable B] queue_setup(Q2, ""): Q2:A [Disable
> C]

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Ananyev, Konstantin]

> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Tuesday, April 24, 2018 1:28 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Thomas Monjalon <thomas@monjalon.net>; dev@dpdk.org
> Cc: 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>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Xing, Beilei
> <beilei.xing@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <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.com>; Rasesh Mody <rasesh.mody@cavium.com>; Andrew Rybchenko <arybchenko@solarflare.com>;
> Shrikrishna Khare <skhare@vmware.com>; Maxime Coquelin <maxime.coquelin@redhat.com>; Legacy, Allain (Wind River)
> <allain.legacy@windriver.com>; Richardson, Bruce <bruce.richardson@intel.com>; Gaetan Rivet <gaetan.rivet@6wind.com>; Olivier Matz
> <olivier.matz@6wind.com>
> Subject: Re: [dpdk-dev] Survey for final decision about per-port offload API
> 
> On 4/24/2018 12:08 PM, Ananyev, Konstantin wrote:
> > Hi Ferruh,
> >
> >>
> >> On 3/30/2018 2:47 PM, 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?
> >>
> >> There is a detail of ability to disabling queue level offloads in queue_setup()
> >> function, I want to discuss here.
> >>
> >> Prolog:
> >> port level offload: An offload only can be applied port level, to all queues.
> >> queue level offload: An offload can be applied into individual queues of the port
> >>
> >> PMD reports port offload capability: port level offload + queue level offload
> >> PMD reports queue offload capability: queue level offload
> >>
> >>
> >> Above suggested change to API:
> >> - Application will be limited in configure() to set only an offload within "port
> >> offload capability"
> >> - Application will be limited in queue_setup() to set only an offload within
> >> "queue offload capability"
> >>
> >>
> >> This doesn't say much about disabling an offload in queue_setup(), as a rule:
> >> - An "port level offload" can't be disabled in queue_setup()
> >>
> >>
> >> There are two cases of disable:
> >> 1- Disabling a "queue level offload" enabled queue_setup() previously
> >> 2- Disabling a "queue level offload" enabled in configure()
> >>
> >> If second is not supported, to disable the offload, applications should
> >> stop->re-configure()->re-queue_setup()->start the port. But having this
> >> capability makes the offloading parameters more confusing for applications.
> >>
> >>
> >> I suggest adding disable support to fist one but not second one.
> >
> > Not sure why to introduce such limitation?
> 
> Not supporting second one?
> 
> To differentiate disable request for that case is harder. How can we say to
> disable a "queue level offloads" enabled by configure()?
> 
> It may be by setting these offloads in queue_setup() as well and when any
> offload is missing in queue_setup() it can be taken as disable request. This
> forces applications to duplicate/set "queue level offloads" enabled by
> configure() in the queue_setup() function by default.
> 
> This is an option, but my concern was to this may be harder to manage by
> applications.
> An application will have to remove "port level offload" from port_offloads and
> feed it into each queue_setup().
> 
> Also this is closer to existing API but not same, the difference is
> queue_setup() doesn't get "port level offload"
> 
> We can go with this one if there is a requirement for it.
> 
> And if we prefer to go with this option, perhaps we can think twice about
> changing exiting API because this will be very close the existing API. Only
> logically it is not correct to force application to set some offloads in
> queue_setup() for the PMD that doesn't support queue offload at all, this can be
> handled in PMD, and saves us of all the trouble of the change.

I suppose both ways are possible - though if we don't allow user to disable queue-specific
offload on particular queue, we would end up with most users just not specifying
any queue-specific offloads at configure() at all - just to have an ability to disable it in future
for particular queue.

Konstantin

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Ferruh Yigit]

On 4/24/2018 4:20 PM, Ananyev, Konstantin wrote:
> 
> 
>> -----Original Message-----
>> From: Yigit, Ferruh
>> Sent: Tuesday, April 24, 2018 1:28 PM
>> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Thomas Monjalon <thomas@monjalon.net>; dev@dpdk.org
>> Cc: 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>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Xing, Beilei
>> <beilei.xing@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <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.com>; Rasesh Mody <rasesh.mody@cavium.com>; Andrew Rybchenko <arybchenko@solarflare.com>;
>> Shrikrishna Khare <skhare@vmware.com>; Maxime Coquelin <maxime.coquelin@redhat.com>; Legacy, Allain (Wind River)
>> <allain.legacy@windriver.com>; Richardson, Bruce <bruce.richardson@intel.com>; Gaetan Rivet <gaetan.rivet@6wind.com>; Olivier Matz
>> <olivier.matz@6wind.com>
>> Subject: Re: [dpdk-dev] Survey for final decision about per-port offload API
>>
>> On 4/24/2018 12:08 PM, Ananyev, Konstantin wrote:
>>> Hi Ferruh,
>>>
>>>>
>>>> On 3/30/2018 2:47 PM, 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?
>>>>
>>>> There is a detail of ability to disabling queue level offloads in queue_setup()
>>>> function, I want to discuss here.
>>>>
>>>> Prolog:
>>>> port level offload: An offload only can be applied port level, to all queues.
>>>> queue level offload: An offload can be applied into individual queues of the port
>>>>
>>>> PMD reports port offload capability: port level offload + queue level offload
>>>> PMD reports queue offload capability: queue level offload
>>>>
>>>>
>>>> Above suggested change to API:
>>>> - Application will be limited in configure() to set only an offload within "port
>>>> offload capability"
>>>> - Application will be limited in queue_setup() to set only an offload within
>>>> "queue offload capability"
>>>>
>>>>
>>>> This doesn't say much about disabling an offload in queue_setup(), as a rule:
>>>> - An "port level offload" can't be disabled in queue_setup()
>>>>
>>>>
>>>> There are two cases of disable:
>>>> 1- Disabling a "queue level offload" enabled queue_setup() previously
>>>> 2- Disabling a "queue level offload" enabled in configure()
>>>>
>>>> If second is not supported, to disable the offload, applications should
>>>> stop->re-configure()->re-queue_setup()->start the port. But having this
>>>> capability makes the offloading parameters more confusing for applications.
>>>>
>>>>
>>>> I suggest adding disable support to fist one but not second one.
>>>
>>> Not sure why to introduce such limitation?
>>
>> Not supporting second one?
>>
>> To differentiate disable request for that case is harder. How can we say to
>> disable a "queue level offloads" enabled by configure()?
>>
>> It may be by setting these offloads in queue_setup() as well and when any
>> offload is missing in queue_setup() it can be taken as disable request. This
>> forces applications to duplicate/set "queue level offloads" enabled by
>> configure() in the queue_setup() function by default.
>>
>> This is an option, but my concern was to this may be harder to manage by
>> applications.
>> An application will have to remove "port level offload" from port_offloads and
>> feed it into each queue_setup().
>>
>> Also this is closer to existing API but not same, the difference is
>> queue_setup() doesn't get "port level offload"
>>
>> We can go with this one if there is a requirement for it.
>>
>> And if we prefer to go with this option, perhaps we can think twice about
>> changing exiting API because this will be very close the existing API. Only
>> logically it is not correct to force application to set some offloads in
>> queue_setup() for the PMD that doesn't support queue offload at all, this can be
>> handled in PMD, and saves us of all the trouble of the change.
> 
> I suppose both ways are possible - though if we don't allow user to disable queue-specific
> offload on particular queue, we would end up with most users just not specifying
> any queue-specific offloads at configure() at all - just to have an ability to disable it in future
> for particular queue.

Yes, this has been mentioned as a easier option to go previously.

> 
> Konstantin
> 
> 

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Thomas Monjalon]

Hi,

First, this is my summary after the survey answers and comments:

1/ allow "forgetting" port offloads in queue offloads setup

2/ update documentation, applications and remove checks in PMDs for 18.05-rc2

3/ an offload enabled at port level, cannot be disabled at queue level

4/ 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 enabled on queue when it is disabled on port level.


24/04/2018 12:39, Ferruh Yigit:
> On 3/30/2018 2:47 PM, 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?
> 
> There is a detail of ability to disabling queue level offloads in queue_setup()
> function, I want to discuss here.
> 
> Prolog:
> port level offload: An offload only can be applied port level, to all queues.
> queue level offload: An offload can be applied into individual queues of the port
> 
> PMD reports port offload capability: port level offload + queue level offload
> PMD reports queue offload capability: queue level offload
> 
> 
> Above suggested change to API:
> - Application will be limited in configure() to set only an offload within "port
> offload capability"

"limited" is not the right word, given port offload capability reports also
queue level offload capability.

> - Application will be limited in queue_setup() to set only an offload within
> "queue offload capability"

Yes

> This doesn't say much about disabling an offload in queue_setup(), as a rule:
> - An "port level offload" can't be disabled in queue_setup()

Yes

> There are two cases of disable:
> 1- Disabling a "queue level offload" enabled queue_setup() previously
> 2- Disabling a "queue level offload" enabled in configure()
> 
> If second is not supported, to disable the offload, applications should
> stop->re-configure()->re-queue_setup()->start the port. But having this
> capability makes the offloading parameters more confusing for applications.

I don't understand the last sentence.

> I suggest adding disable support to fist one but not second one.

Yes, it is the item 3 of the survey.

> According this,
> application:
> - In configure() set offload within "port offload capability"
> - In queue_setup() set offload within "queue offload capability". Offloads are
> incremental to ones in configure()
> 
> PMDs:
> - In configure() verify the offload against "port offload capability"
> - In queue_setup() verify the offload against "queue offload capability"

At ethdev level, we should filter out the offloads already enabled at port level,
before calling the queue setup op.

> - In queue_setup() if requested offload is not enabled already, enable it for queue
> - In queue_setup() if an offload value cleared in requested offload that is set
> in port_offload, return error.

No
The item 1 of the survey is about allow "forgetting" port offloads.
If offload is enabled at port level, and not repeated in queue setup,
nothing happen. It stays enabled at port level.

> - In queue_setup() if an offload value cleared in requested offload that is not
> set in port_offload but set in queue_offload, disable it for that queue.

Yes


> Samples according initial suggestion + disable support:
> 
> Sample 1:
> port level offload: A, B
> queue level offload: C, D
> port offload capability: A, B, C, D
> queue offload capability: C, D
> 
> configure(A,C): Q1:A,C  Q2:A,C [queue_setup() can't disable A,C after this]
> queue_setup(Q1, B): --> Error [Can't enable port level offload in queue_setup()]
> queue_setup(Q1, D): Q1:A,C,D
> queue_setup(Q1, ""): Q1:A,C [Disabled D]

Yes we can disable a queue offload.

> queue_setup(Q2, "C,D"): Q2:A,C,D
> queue_setup(Q2, ""): Q2:A,C

Yes we cannot disable a port offload.

> queue_setup(Q2, A): --> Error [A is port_level offload]

No, it is the same as queue_setup(Q2, "C,D").
We can repeat an already enabled port offload in queue setup.


> Sample 2:
> port level offload: A, B, C
> queue level offload: ""
> port offload capability: A, B, C
> queue offload capability: ""   [no way to change offloads in queue level]
> 
> configure(A,C): Q1:A,C  Q2:A,C
> queue_setup(Q1, B): --> Error
> queue_setup(Q1, A): --> Error

No, we can repeat an already enabled port offload in queue setup.

> queue_setup(Q2, ""): Q2:A,C
> queue_setup(Q1, ""): Q1:A,C
> 
> 
> Sample 3:
> port level offload: ""
> queue level offload: A, B, C, D
> port offload capability: A, B, C, D
> queue offload capability: A, B, C, D
> 
> configure(A): Q1:A  Q2:A
> queue_setup(Q1, A): Q1:A
> queue_setup(Q1, ""): Q1:A
> queue_setup(Q1, A,B,C,D): Q1:A,B,C,D
> queue_setup(Q1, B): Q1:A,B [Disable C,D]

Yes

> queue_setup(Q2, C): Q2:A,C
> queue_setup(Q1, ""): Q1:A [Disable B]
> queue_setup(Q2, ""): Q2:A [Disable C]

Yes

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Ferruh Yigit]

On 4/24/2018 11:00 PM, Thomas Monjalon wrote:
> Hi,
> 
> First, this is my summary after the survey answers and comments:
> 
> 1/ allow "forgetting" port offloads in queue offloads setup
> 
> 2/ update documentation, applications and remove checks in PMDs for 18.05-rc2
> 
> 3/ an offload enabled at port level, cannot be disabled at queue level
> 
> 4/ 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 enabled on queue when it is disabled on port level.
> 
> 
> 24/04/2018 12:39, Ferruh Yigit:
>> On 3/30/2018 2:47 PM, 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?
>>
>> There is a detail of ability to disabling queue level offloads in queue_setup()
>> function, I want to discuss here.
>>
>> Prolog:
>> port level offload: An offload only can be applied port level, to all queues.
>> queue level offload: An offload can be applied into individual queues of the port
>>
>> PMD reports port offload capability: port level offload + queue level offload
>> PMD reports queue offload capability: queue level offload
>>
>>
>> Above suggested change to API:
>> - Application will be limited in configure() to set only an offload within "port
>> offload capability"
> 
> "limited" is not the right word, given port offload capability reports also
> queue level offload capability.
> 
>> - Application will be limited in queue_setup() to set only an offload within
>> "queue offload capability"
> 
> Yes
> 
>> This doesn't say much about disabling an offload in queue_setup(), as a rule:
>> - An "port level offload" can't be disabled in queue_setup()
> 
> Yes
> 
>> There are two cases of disable:
>> 1- Disabling a "queue level offload" enabled queue_setup() previously
>> 2- Disabling a "queue level offload" enabled in configure()
>>
>> If second is not supported, to disable the offload, applications should
>> stop->re-configure()->re-queue_setup()->start the port. But having this
>> capability makes the offloading parameters more confusing for applications.
> 
> I don't understand the last sentence.
> 
>> I suggest adding disable support to fist one but not second one.
> 
> Yes, it is the item 3 of the survey.

Yes indeed.

> 
>> According this,
>> application:
>> - In configure() set offload within "port offload capability"
>> - In queue_setup() set offload within "queue offload capability". Offloads are
>> incremental to ones in configure()
>>
>> PMDs:
>> - In configure() verify the offload against "port offload capability"
>> - In queue_setup() verify the offload against "queue offload capability"
> 
> At ethdev level, we should filter out the offloads already enabled at port level,
> before calling the queue setup op.

Above two steps can be moved to ethdev layer, agreed. But I guess you are
talking about something else, can you please detail?

> 
>> - In queue_setup() if requested offload is not enabled already, enable it for queue
>> - In queue_setup() if an offload value cleared in requested offload that is set
>> in port_offload, return error.
> 
> No
> The item 1 of the survey is about allow "forgetting" port offloads.
> If offload is enabled at port level, and not repeated in queue setup,
> nothing happen. It stays enabled at port level.

Right.

> 
>> - In queue_setup() if an offload value cleared in requested offload that is not
>> set in port_offload but set in queue_offload, disable it for that queue.
> 
> Yes

OK, good to agree on this, this was the main topic of this email.

> 
> 
>> Samples according initial suggestion + disable support:
>>
>> Sample 1:
>> port level offload: A, B
>> queue level offload: C, D
>> port offload capability: A, B, C, D
>> queue offload capability: C, D
>>
>> configure(A,C): Q1:A,C  Q2:A,C [queue_setup() can't disable A,C after this]
>> queue_setup(Q1, B): --> Error [Can't enable port level offload in queue_setup()]
>> queue_setup(Q1, D): Q1:A,C,D
>> queue_setup(Q1, ""): Q1:A,C [Disabled D]
> 
> Yes we can disable a queue offload.
> 
>> queue_setup(Q2, "C,D"): Q2:A,C,D
>> queue_setup(Q2, ""): Q2:A,C
> 
> Yes we cannot disable a port offload.
> 
>> queue_setup(Q2, A): --> Error [A is port_level offload]
> 
> No, it is the same as queue_setup(Q2, "C,D").
> We can repeat an already enabled port offload in queue setup.

You are right, no need to return error here, since it is already enabled for queue.

> 
> 
>> Sample 2:
>> port level offload: A, B, C
>> queue level offload: ""
>> port offload capability: A, B, C
>> queue offload capability: ""   [no way to change offloads in queue level]
>>
>> configure(A,C): Q1:A,C  Q2:A,C
>> queue_setup(Q1, B): --> Error
>> queue_setup(Q1, A): --> Error
> 
> No, we can repeat an already enabled port offload in queue setup.

Right.

> 
>> queue_setup(Q2, ""): Q2:A,C
>> queue_setup(Q1, ""): Q1:A,C
>>
>>
>> Sample 3:
>> port level offload: ""
>> queue level offload: A, B, C, D
>> port offload capability: A, B, C, D
>> queue offload capability: A, B, C, D
>>
>> configure(A): Q1:A  Q2:A
>> queue_setup(Q1, A): Q1:A
>> queue_setup(Q1, ""): Q1:A
>> queue_setup(Q1, A,B,C,D): Q1:A,B,C,D
>> queue_setup(Q1, B): Q1:A,B [Disable C,D]
> 
> Yes
> 
>> queue_setup(Q2, C): Q2:A,C
>> queue_setup(Q1, ""): Q1:A [Disable B]
>> queue_setup(Q2, ""): Q2:A [Disable C]
> 
> Yes
> 
> 
> 

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Thomas Monjalon]

25/04/2018 15:32, Ferruh Yigit:
> On 4/24/2018 11:00 PM, Thomas Monjalon wrote:
> > Hi,
> > 
> > First, this is my summary after the survey answers and comments:
> > 
> > 1/ allow "forgetting" port offloads in queue offloads setup
> > 
> > 2/ update documentation, applications and remove checks in PMDs for 18.05-rc2
> > 
> > 3/ an offload enabled at port level, cannot be disabled at queue level
> > 
> > 4/ 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 enabled on queue when it is disabled on port level.
> > 
> > 
> > 24/04/2018 12:39, Ferruh Yigit:
> >> On 3/30/2018 2:47 PM, 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?
> >>
> >> There is a detail of ability to disabling queue level offloads in queue_setup()
> >> function, I want to discuss here.
> >>
> >> Prolog:
> >> port level offload: An offload only can be applied port level, to all queues.
> >> queue level offload: An offload can be applied into individual queues of the port
> >>
> >> PMD reports port offload capability: port level offload + queue level offload
> >> PMD reports queue offload capability: queue level offload
> >>
> >>
> >> Above suggested change to API:
> >> - Application will be limited in configure() to set only an offload within "port
> >> offload capability"
> > 
> > "limited" is not the right word, given port offload capability reports also
> > queue level offload capability.
> > 
> >> - Application will be limited in queue_setup() to set only an offload within
> >> "queue offload capability"
> > 
> > Yes
> > 
> >> This doesn't say much about disabling an offload in queue_setup(), as a rule:
> >> - An "port level offload" can't be disabled in queue_setup()
> > 
> > Yes
> > 
> >> There are two cases of disable:
> >> 1- Disabling a "queue level offload" enabled queue_setup() previously
> >> 2- Disabling a "queue level offload" enabled in configure()
> >>
> >> If second is not supported, to disable the offload, applications should
> >> stop->re-configure()->re-queue_setup()->start the port. But having this
> >> capability makes the offloading parameters more confusing for applications.
> > 
> > I don't understand the last sentence.
> > 
> >> I suggest adding disable support to fist one but not second one.
> > 
> > Yes, it is the item 3 of the survey.
> 
> Yes indeed.
> 
> > 
> >> According this,
> >> application:
> >> - In configure() set offload within "port offload capability"
> >> - In queue_setup() set offload within "queue offload capability". Offloads are
> >> incremental to ones in configure()
> >>
> >> PMDs:
> >> - In configure() verify the offload against "port offload capability"
> >> - In queue_setup() verify the offload against "queue offload capability"
> > 
> > At ethdev level, we should filter out the offloads already enabled at port level,
> > before calling the queue setup op.
> 
> Above two steps can be moved to ethdev layer, agreed. But I guess you are
> talking about something else, can you please detail?

Yes I am adding one more step.
In the case of offload already enabled at port level
and repeated in queue setup,
ethdev can avoid passing it to the PMD queue setup function.
It will make PMD implementation easier: all queue offloads received
at PMD level will require to be really enabled for the queue.


> >> - In queue_setup() if requested offload is not enabled already, enable it for queue
> >> - In queue_setup() if an offload value cleared in requested offload that is set
> >> in port_offload, return error.
> > 
> > No
> > The item 1 of the survey is about allow "forgetting" port offloads.
> > If offload is enabled at port level, and not repeated in queue setup,
> > nothing happen. It stays enabled at port level.
> 
> Right.
> 
> > 
> >> - In queue_setup() if an offload value cleared in requested offload that is not
> >> set in port_offload but set in queue_offload, disable it for that queue.
> > 
> > Yes
> 
> OK, good to agree on this, this was the main topic of this email.

Thanks for confirming, I was not sure about the main topic :)


> >> Samples according initial suggestion + disable support:
> >>
> >> Sample 1:
> >> port level offload: A, B
> >> queue level offload: C, D
> >> port offload capability: A, B, C, D
> >> queue offload capability: C, D
> >>
> >> configure(A,C): Q1:A,C  Q2:A,C [queue_setup() can't disable A,C after this]
> >> queue_setup(Q1, B): --> Error [Can't enable port level offload in queue_setup()]
> >> queue_setup(Q1, D): Q1:A,C,D
> >> queue_setup(Q1, ""): Q1:A,C [Disabled D]
> > 
> > Yes we can disable a queue offload.
> > 
> >> queue_setup(Q2, "C,D"): Q2:A,C,D
> >> queue_setup(Q2, ""): Q2:A,C
> > 
> > Yes we cannot disable a port offload.
> > 
> >> queue_setup(Q2, A): --> Error [A is port_level offload]
> > 
> > No, it is the same as queue_setup(Q2, "C,D").
> > We can repeat an already enabled port offload in queue setup.
> 
> You are right, no need to return error here, since it is already enabled for queue.
> 
> > 
> > 
> >> Sample 2:
> >> port level offload: A, B, C
> >> queue level offload: ""
> >> port offload capability: A, B, C
> >> queue offload capability: ""   [no way to change offloads in queue level]
> >>
> >> configure(A,C): Q1:A,C  Q2:A,C
> >> queue_setup(Q1, B): --> Error
> >> queue_setup(Q1, A): --> Error
> > 
> > No, we can repeat an already enabled port offload in queue setup.
> 
> Right.
> 
> > 
> >> queue_setup(Q2, ""): Q2:A,C
> >> queue_setup(Q1, ""): Q1:A,C
> >>
> >>
> >> Sample 3:
> >> port level offload: ""
> >> queue level offload: A, B, C, D
> >> port offload capability: A, B, C, D
> >> queue offload capability: A, B, C, D
> >>
> >> configure(A): Q1:A  Q2:A
> >> queue_setup(Q1, A): Q1:A
> >> queue_setup(Q1, ""): Q1:A
> >> queue_setup(Q1, A,B,C,D): Q1:A,B,C,D
> >> queue_setup(Q1, B): Q1:A,B [Disable C,D]
> > 
> > Yes
> > 
> >> queue_setup(Q2, C): Q2:A,C
> >> queue_setup(Q1, ""): Q1:A [Disable B]
> >> queue_setup(Q2, ""): Q2:A [Disable C]
> > 
> > Yes

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Ferruh Yigit]

On 4/25/2018 2:32 PM, Ferruh Yigit wrote:
>>> There are two cases of disable:
>>> 1- Disabling a "queue level offload" enabled queue_setup() previously
>>> 2- Disabling a "queue level offload" enabled in configure()
>>>
>>> If second is not supported, to disable the offload, applications should
>>> stop->re-configure()->re-queue_setup()->start the port. But having this
>>> capability makes the offloading parameters more confusing for applications.
>> I don't understand the last sentence.
>>
>>> I suggest adding disable support to fist one but not second one.
>> Yes, it is the item 3 of the survey.
> Yes indeed.

Just to confirm, as far as I can see 2) is supported by Mlx PMD, at least the
verify function doesn't return error for this case [1], which won't be supported
anymore.
Can we get a confirmation from mlx PMD developers that this is OK?


[1]
static int
mlx5_is_rx_queue_offloads_allowed(struct rte_eth_dev *dev, uint64_t offloads)
{
        uint64_t port_offloads = dev->data->dev_conf.rxmode.offloads;
        uint64_t queue_supp_offloads = mlx5_get_rx_queue_offloads(dev);
        uint64_t port_supp_offloads = mlx5_get_rx_port_offloads();

        if ((offloads & (queue_supp_offloads | port_supp_offloads)) !=
            offloads)
                return 0;
        if (((port_offloads ^ offloads) & port_supp_offloads))
                return 0;
        return 1;
}