From: Akhil Goyal <gakhil@marvell.com>
To: Srujana Challa <schalla@marvell.com>
Cc: "roy.fan.zhang@intel.com" <roy.fan.zhang@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
Nithin Kumar Dabilpuram <ndabilpuram@marvell.com>,
Anoob Joseph <anoobj@marvell.com>,
"david.marchand@redhat.com" <david.marchand@redhat.com>,
"bruce.richardson@intel.com" <bruce.richardson@intel.com>,
"konstantin.v.ananyev@yandex.ru" <konstantin.v.ananyev@yandex.ru>,
Thomas Monjalon <thomas@monjalon.net>,
"matan@nvidia.com" <matan@nvidia.com>,
"honnappa.nagarahalli@arm.com" <honnappa.nagarahalli@arm.com>
Subject: RE: [EXT] Re: [RFC PATCH] cryptodev: add return parameter to callback process API
Date: Fri, 30 Sep 2022 19:17:01 +0000 [thread overview]
Message-ID: <CO6PR18MB4484C4CD57B57A0D2E01440DD8569@CO6PR18MB4484.namprd18.prod.outlook.com> (raw)
In-Reply-To: <BYAPR18MB2791CA3BA26504A923430CBFA04D9@BYAPR18MB2791.namprd18.prod.outlook.com>
> > 24/06/2022 14:12, Srujana Challa:
> > > Adds a return parameter "uint16_t qp_id" to the functions
> > > rte_cryptodev_pmd_callback_process and rte_cryptodev_cb_fn.
> > > The new parameter is used to return queue pair ID to the application
> > > when it gets error interrupt, so that application can disable and
> > > enable the queue pair, to bring the queue back to normal state.
> >
> > What about other events?
> >
> > > + * @param qp_id Return parameter from driver to the application.
> > Driver
> > > + * returns queue pair ID when it gets HW error
> > interrupt.
> > > + * The application can release and setup the queue
> > > + * again, to bring the HW queue back to normal state.
> >
> > What will it mean if the event is not related to queues?
> >
> > > * @param event Crypto device event to register for notification of.
> > > * @param cb_arg User specified parameter to be passed as to passed
> > to
> > > * users callback function.
> >
> > Are you going to add a new callback parameter each time the application
> > needs info about a new event?
> >
> > In my opinion, it is a very bad idea.
> > As done in ethdev, you should add a query function specific to the event.
> >
> > Example: https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__git.dpdk.org_dpdk_commit_-3Fid-
> > 3Dbc70e5594838&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=Fj4OoD5hcK
> > FpANhTWdwQzjT1Jpf7veC5263T47JVpnc&m=SUn-
> > UVCQXX4KwyuDDcIb_PvE4MwkLTimQ3ox7hHcKW7wCq6BzW2849tn1nq2dO
> > S1&s=aSpFxjeE4xjxZadI9wxc5AqInIvinSvFfa0NEeRrxBA&e=
> > Here, when a threshold is reached, an event
> > RTE_ETH_EVENT_RX_AVAIL_THRESH is fired, and the application can get
> > more info about what happened by calling the function
> > rte_eth_rx_avail_thresh_query().
> > Look at the parameters description:
> > "
> > @param[inout] queue_id
> > On input starting Rx queue index to search from.
> > If the queue_id is bigger than maximum queue ID of the port, search is
> > started from 0. So that application can keep calling this function to handle all
> > pending events with a simple increment of queue_id on the next call.
> > On output if return value is 1, Rx queue index with the event pending.
> > @param[out] avail_thresh
> > Location for available descriptors threshold of the found Rx queue.
> > "
> >
> Agree with your comment. Will work on to implement query API for events. But
> as of now we only have single error event.
There is a deprecation notice for this patch. Since the patch is dropped can we remove that notice?
prev parent reply other threads:[~2022-09-30 19:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-24 12:12 Srujana Challa
2022-07-17 10:46 ` Thomas Monjalon
2022-09-19 12:38 ` [EXT] " Srujana Challa
2022-09-30 19:17 ` Akhil Goyal [this message]
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=CO6PR18MB4484C4CD57B57A0D2E01440DD8569@CO6PR18MB4484.namprd18.prod.outlook.com \
--to=gakhil@marvell.com \
--cc=anoobj@marvell.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=honnappa.nagarahalli@arm.com \
--cc=jerinj@marvell.com \
--cc=konstantin.v.ananyev@yandex.ru \
--cc=matan@nvidia.com \
--cc=ndabilpuram@marvell.com \
--cc=roy.fan.zhang@intel.com \
--cc=schalla@marvell.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).