All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shahaf Shuler <shahafs@mellanox.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Ajit Khaparde" <ajit.khaparde@broadcom.com>,
	"Jerin Jacob" <jerin.jacob@caviumnetworks.com>,
	"Shijith Thotton" <shijith.thotton@cavium.com>,
	"Santosh Shukla" <santosh.shukla@caviumnetworks.com>,
	"Rahul Lakkireddy" <rahul.lakkireddy@chelsio.com>,
	"John Daley" <johndale@cisco.com>,
	"Wenzhuo Lu" <wenzhuo.lu@intel.com>,
	"Konstantin Ananyev" <konstantin.ananyev@intel.com>,
	"Beilei Xing" <beilei.xing@intel.com>,
	"Qi Zhang" <qi.z.zhang@intel.com>,
	"Jingjing Wu" <jingjing.wu@intel.com>,
	"Adrien Mazarguil" <adrien.mazarguil@6wind.com>,
	"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@cavi>
Subject: Re: Survey for final decision about per-port offload API
Date: Tue, 3 Apr 2018 05:19:35 +0000	[thread overview]
Message-ID: <DB7PR05MB44268579ABFBEB1BD7930DE9C3A50@DB7PR05MB4426.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <3164302.jtqUZe9MAY@xps>

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. 


> 

  reply	other threads:[~2018-04-03  5:19 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 [this message]
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
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=DB7PR05MB44268579ABFBEB1BD7930DE9C3A50@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=harish.patil@cavi \
    --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.