From: Akhil Goyal <akhil.goyal@nxp.com>
To: Anoob Joseph <anoobj@marvell.com>
Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
Narayana Prasad Raju Athreya <pathreya@marvell.com>,
"dev@dpdk.org" <dev@dpdk.org>,
Konstantin Ananyev <konstantin.ananyev@intel.com>,
Hemant Agrawal <hemant.agrawal@nxp.com>,
Fan Zhang <roy.fan.zhang@intel.com>,
Fiona Trahe <fiona.trahe@intel.com>,
Ferruh Yigit <ferruh.yigit@intel.com>,
John McNamara <john.mcnamara@intel.com>,
Marko Kovacevic <marko.kovacevic@intel.com>
Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] doc: add inline protocol in feature list
Date: Wed, 12 Feb 2020 10:25:26 +0000 [thread overview]
Message-ID: <VE1PR04MB6639A1F80473DC389204E14DE61B0@VE1PR04MB6639.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <MN2PR18MB2877A9793D572207DF615225DF190@MN2PR18MB2877.namprd18.prod.outlook.com>
Hi Anoob,
> > >>
> > >> Hi Anoob,
> > >>
> > >> What is the difference between "Inline crypto" in that document and
> > >> this "Inline protocol"? Both seems providing same outpout.
> > >
> > > [Anoob] Yes. It is partly because the description of "inline crypto" is not
> > accurate. The feature, "inline crypto" is not ipsec aware but would do crypto
> > operation in the ipsec. This summary points to the security documentation
> > for further details and that doc clearly explains the difference between both
> > modes.
> > >
> > >> Is there a way to differentiate them more clearly?
> > >
> > > [Anoob] There are two options I can think of, 1. Update the feature
> > > list to describe the difference between the two. Have a line like,
> > > "As compared to inline crypto, inline protocol will handle the entire
> > protocol offload in addition to the crypto operation."
> > > 2. Both inline crypto and inline protocol falls under security. So could even
> > rename "Inline crypto" to "Inline security offload" and we should be good to
> > go. Also, under inline protocol, there are various protocols possible. Say,
> > tomorrow when we add MACSEC support, the same question would arise (as
> > in whether it's a new feature or would it be under "inline protocol").
Please re-phrase the description of inline crypto as well so that there is a clear
Differentiation between the two modes. Referring to rte_security is not enough.
It can be something like
For Inline crypto: An operation defined in rte_security lib to perform only crypto
Operations of the security protocol while the packet is received at NIC. NIC is not aware
of the protocol operations. See Security library and PMD documentation for more details.
For Inline protocol : An operation defined in rte_security lib to perform protocol processing for
the security protocol (e.g. IPSEC, MACSEC) while the packet is received at the NIC. The NIC is capable
to understand the security protocol operations. See Security library and PMD documentation for more details.
> >
> > Hi Anoob,
> >
> > These seems security related and I don't know enough to comment if this is
> > correct thing to do. I have cc'ed a few more people for comment.
> >
> > @Akhil, would you mind if I assign this to you?
> >
> > Thanks,
> > ferruh
> >
> > >
> > >>
> > >>>
> > >>> Thanks,
> > >>> Anoob
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: dev <dev-bounces@dpdk.org> On Behalf Of Anoob Joseph
> > >>>> Sent: Tuesday, December 10, 2019 12:23 PM
> > >>>> To: John McNamara <john.mcnamara@intel.com>; Marko Kovacevic
> > >>>> <marko.kovacevic@intel.com>; Ferruh Yigit <ferruh.yigit@intel.com>
> > >>>> Cc: Anoob Joseph <anoobj@marvell.com>; Jerin Jacob Kollanukkaran
> > >>>> <jerinj@marvell.com>; Narayana Prasad Raju Athreya
> > >>>> <pathreya@marvell.com>; dev@dpdk.org
> > >>>> Subject: [dpdk-dev] [PATCH] doc: add inline protocol in feature
> > >>>> list
> > >>>>
> > >>>> Update feature list to include inline protocol offload.
> > >>>>
> > >>>> Signed-off-by: Anoob Joseph <anoobj@marvell.com>
> > >>>> ---
> > >>>> doc/guides/nics/features.rst | 18 ++++++++++++++++++
> > >>>> doc/guides/nics/features/default.ini | 1 +
> > >>>> 2 files changed, 19 insertions(+)
> > >>>>
> > >>>> diff --git a/doc/guides/nics/features.rst
> > >>>> b/doc/guides/nics/features.rst index
> > >>>> 8394a65..f4eb2a9 100644
> > >>>> --- a/doc/guides/nics/features.rst
> > >>>> +++ b/doc/guides/nics/features.rst
> > >>>> @@ -433,6 +433,24 @@ Supports inline crypto processing (e.g. inline
> > >>>> IPsec). See Security library and
> > >>>> ``mbuf.ol_flags:PKT_TX_SEC_OFFLOAD``,
> > >>>> ``mbuf.ol_flags:PKT_RX_SEC_OFFLOAD_FAILED``.
> > >>>>
> > >>>>
> > >>>> +.. _nic_features_inline_protocol_doc:
> > >>>> +
> > >>>> +Inline protocol
> > >>>> +---------------
> > >>>> +
> > >>>> +Supports inline protocol processing (e.g. inline IPsec). See
> > >>>> +Security library and
> > >>>> PMD documentation for more details.
> > >>>> +
> > >>>> +* **[uses] rte_eth_rxconf,rte_eth_rxmode**:
> > >>>> ``offloads:DEV_RX_OFFLOAD_SECURITY``,
> > >>>> +* **[uses] rte_eth_txconf,rte_eth_txmode**:
> > >>>> ``offloads:DEV_TX_OFFLOAD_SECURITY``.
> > >>>> +* **[implements] rte_security_ops**: ``session_create``,
> > >>>> +``session_update``,
> > >>>> + ``session_stats_get``, ``session_destroy``,
> > >>>> +``set_pkt_metadata``, ``get_userdata``,
> > >>>> + ``capabilities_get``.
> > >>>> +* **[provides] rte_eth_dev_info**:
> > >>>>
> > >>
> > +``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_SECURITY``,
> > >>>> +
> > >>
> > ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_SECURITY``.
> > >>>> +* **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_SEC_OFFLOAD``,
> > >>>> + ``mbuf.ol_flags:PKT_TX_SEC_OFFLOAD``,
> > >>>> ``mbuf.ol_flags:PKT_RX_SEC_OFFLOAD_FAILED``.
> > >>>> +
> > >>>> +
> > >>>> .. _nic_features_crc_offload:
> > >>>>
> > >>>> CRC offload
> > >>>> diff --git a/doc/guides/nics/features/default.ini
> > >>>> b/doc/guides/nics/features/default.ini
> > >>>> index 91ec619..4d0ad32 100644
> > >>>> --- a/doc/guides/nics/features/default.ini
> > >>>> +++ b/doc/guides/nics/features/default.ini
> > >>>> @@ -42,6 +42,7 @@ Flow API =
> > >>>> Rate limitation =
> > >>>> Traffic mirroring =
> > >>>> Inline crypto =
> > >>>> +Inline protocol =
> > >>>> CRC offload =
> > >>>> VLAN offload =
> > >>>> QinQ offload =
> > >>>> --
> > >>>> 2.7.4
> > >>>
> > >
next prev parent reply other threads:[~2020-02-12 10:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-10 6:53 [dpdk-dev] " Anoob Joseph
2020-01-21 5:40 ` Anoob Joseph
2020-01-21 16:12 ` Ferruh Yigit
2020-01-22 9:47 ` [dpdk-dev] [EXT] " Anoob Joseph
2020-02-04 14:35 ` Ferruh Yigit
2020-02-10 5:44 ` Anoob Joseph
2020-02-12 10:25 ` Akhil Goyal [this message]
2020-02-12 13:30 ` Ferruh Yigit
2020-02-12 13:48 ` Akhil Goyal
2020-02-12 13:53 ` Ferruh Yigit
2020-02-12 14:10 ` Akhil Goyal
2020-02-17 15:22 ` [dpdk-dev] [PATCH v2] " Anoob Joseph
2020-02-17 15:39 ` [dpdk-dev] [PATCH v3] " Anoob Joseph
2020-02-18 7:40 ` Akhil Goyal
2020-02-18 9:28 ` Ferruh Yigit
2020-02-18 10:02 ` 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=VE1PR04MB6639A1F80473DC389204E14DE61B0@VE1PR04MB6639.eurprd04.prod.outlook.com \
--to=akhil.goyal@nxp.com \
--cc=anoobj@marvell.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=fiona.trahe@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=jerinj@marvell.com \
--cc=john.mcnamara@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=marko.kovacevic@intel.com \
--cc=pathreya@marvell.com \
--cc=roy.fan.zhang@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).