All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shahaf Shuler <shahafs@mellanox.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	"dev@dpdk.org" <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>,
	"Nélio Laranjeiro" <nelio.laranjeiro@6wind.com>,
	"Yongseok Koh" <yskoh@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>
Subject: Re: Survey for final decision about per-port offload API
Date: Tue, 24 Apr 2018 12:56:10 +0000	[thread overview]
Message-ID: <DB7PR05MB442682EBF81C42B6FC535693C3880@DB7PR05MB4426.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <ea9ff099-75a0-e10a-191e-ba8696996a25@intel.com>

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]


  parent reply	other threads:[~2018-04-24 12:56 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-30 13:47 Survey for final decision about per-port offload API Thomas Monjalon
2018-03-30 15:13 ` Andrew Rybchenko
2018-03-30 15:46   ` Thomas Monjalon
2018-04-01  1:51 ` Zhang, Qi Z
2018-04-02 15:44   ` Thomas Monjalon
2018-04-01  4:44 ` Shahaf Shuler
2018-04-02 15:53   ` Thomas Monjalon
2018-04-03  5:19     ` Shahaf Shuler
2018-04-02  1:27 ` Lu, Wenzhuo
2018-04-02  3:18 ` Xing, Beilei
2018-04-02 17:23 ` Wu, Jingjing
2018-04-02 17:39 ` Patil, Harish
2018-04-02 20:10   ` Thomas Monjalon
2018-04-02 20:45     ` Patil, Harish
2018-04-03  0:53 ` Zhang, Qi Z
2018-04-03 19:59 ` John Daley (johndale)
2018-04-04  0:25 ` Yongseok Koh
2018-04-11 14:42 ` Olivier Matz
2018-04-11 15:17 ` Alejandro Lucero
2018-04-12  5:41 ` Jerin Jacob
2018-04-12  7:03 ` Maxime Coquelin
2018-04-12  9:08 ` Shreyansh Jain
2018-04-24 10:39 ` Ferruh Yigit
2018-04-24 11:08   ` Ananyev, Konstantin
2018-04-24 12:27     ` Ferruh Yigit
2018-04-24 15:20       ` Ananyev, Konstantin
2018-04-24 16:18         ` Ferruh Yigit
2018-04-24 12:56   ` Shahaf Shuler [this message]
2018-04-24 22:00   ` Thomas Monjalon
2018-04-25 13:32     ` Ferruh Yigit
2018-04-25 15:21       ` Thomas Monjalon
2018-04-25 16:45       ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB7PR05MB442682EBF81C42B6FC535693C3880@DB7PR05MB4426.eurprd05.prod.outlook.com \
    --to=shahafs@mellanox.com \
    --cc=adrien.mazarguil@6wind.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=alejandro.lucero@netronome.com \
    --cc=beilei.xing@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=harish.patil@cavium.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=jianbo.liu@arm.com \
    --cc=jingjing.wu@intel.com \
    --cc=johndale@cisco.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=nelio.laranjeiro@6wind.com \
    --cc=qi.z.zhang@intel.com \
    --cc=rahul.lakkireddy@chelsio.com \
    --cc=santosh.shukla@caviumnetworks.com \
    --cc=shijith.thotton@cavium.com \
    --cc=shreyansh.jain@nxp.com \
    --cc=tdu@semihalf.com \
    --cc=thomas@monjalon.net \
    --cc=wenzhuo.lu@intel.com \
    --cc=yskoh@mellanox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.