From: Jerin Jacob <jerinjacobk@gmail.com>
To: "Naga Harish K, S V" <s.v.naga.harish.k@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"Jayatheerthan, Jay" <jay.jayatheerthan@intel.com>
Subject: Re: [PATCH v2] eventdev/eth_rx: update adapter create APIs
Date: Thu, 10 Aug 2023 13:37:07 +0530 [thread overview]
Message-ID: <CALBAE1Ocvv9mySqbr6FwJP=gWz3aeJdYcJH5eByB=_BL4d8wGQ@mail.gmail.com> (raw)
In-Reply-To: <DM6PR11MB3868187FED91C34EB12DD246A113A@DM6PR11MB3868.namprd11.prod.outlook.com>
On Thu, Aug 10, 2023 at 1:09 PM Naga Harish K, S V
<s.v.naga.harish.k@intel.com> wrote:
>
> Hi Jerin,
> As per DPDK Guidelines, API changes or ABI breakage is allowed during LTS releases
> (https://doc.dpdk.org/guides/contributing/abi_policy.html#abi-breakages)
Yes. Provided if depreciation notice has sent, approved and changes
absolutely needed.
>
> Also, there are previous instances where API changes happened, some of them are mentioned below.
These are not the cases where existing APIs removed and changed
prototype to cover up the removed function.
>
> In DPDK 22.11, the cryptodev library had undergone the following API changes.
> * rte_cryptodev_sym_session_create() and rte_cryptodev_asym_session_create() API parameters changed.
> rte_cryptodev_sym_session_free() and rte_cryptodev_asym_session_free() API parameters changed.
> rte_cryptodev_sym_session_init() and rte_cryptodev_asym_session_init() APIs are removed.
>
> * eventdev: The function ``rte_event_crypto_adapter_queue_pair_add`` was updated
> to accept configuration of type ``rte_event_crypto_adapter_queue_conf``
> instead of ``rte_event``,
> similar to ``rte_event_eth_rx_adapter_queue_add`` signature.
> Event will be one of the configuration fields,
> together with additional vector parameters.
>
> Applications have to change to accommodate the above API changes.
>
> As discussed earlier, fewer adapter-create APIs are useful for the application design.
> Please let us know your thoughts on the same.
mempool have different variants of create API. IMO, Different variants
of _create API is OK and application
can pick the correct one based on the needed.
It is OK to break the API prototype if absolutely needed, in this case
it is not.
next prev parent reply other threads:[~2023-08-10 8:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-01 9:40 [RFC] " Naga Harish K S V
2023-08-01 10:28 ` Jerin Jacob
2023-08-01 13:51 ` [PATCH v2] " Naga Harish K S V
2023-08-01 15:23 ` Jerin Jacob
2023-08-02 14:19 ` Naga Harish K, S V
2023-08-02 16:12 ` Jerin Jacob
2023-08-10 7:38 ` Naga Harish K, S V
2023-08-10 8:07 ` Jerin Jacob [this message]
2023-08-10 11:58 ` Naga Harish K, S V
2023-08-10 13:25 ` Jerin Jacob
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='CALBAE1Ocvv9mySqbr6FwJP=gWz3aeJdYcJH5eByB=_BL4d8wGQ@mail.gmail.com' \
--to=jerinjacobk@gmail.com \
--cc=dev@dpdk.org \
--cc=jay.jayatheerthan@intel.com \
--cc=s.v.naga.harish.k@intel.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 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).