Hi Ori, Please see inline.
Thanks, Anoob > -----Original Message----- > From: Ori Kam <[email protected]> > Sent: Thursday, January 16, 2020 7:08 PM > To: Anoob Joseph <[email protected]>; Medvedkin, Vladimir > <[email protected]>; Ananyev, Konstantin > <[email protected]>; Akhil Goyal <[email protected]>; Adrien > Mazarguil <[email protected]>; Doherty, Declan > <[email protected]>; Yigit, Ferruh <[email protected]>; Jerin > Jacob > Kollanukkaran <[email protected]>; Thomas Monjalon > <[email protected]> > Cc: Ankur Dwivedi <[email protected]>; Hemant Agrawal > <[email protected]>; Matan Azrad <[email protected]>; Nicolau, > Radu <[email protected]>; Shahaf Shuler <[email protected]>; > Narayana Prasad Raju Athreya <[email protected]>; [email protected] > Subject: RE: [dpdk-dev] [EXT] Re: [PATCH] ethdev: allow multiple security > sessions to use one rte flow > > Just one more question inline. > > > -----Original Message----- > > From: dev <[email protected]> On Behalf Of Anoob Joseph > > Sent: Thursday, January 16, 2020 2:03 PM > > To: Ori Kam <[email protected]>; Medvedkin, Vladimir > > <[email protected]>; Ananyev, Konstantin > > <[email protected]>; Akhil Goyal <[email protected]>; > > Adrien Mazarguil <[email protected]>; Doherty, Declan > > <[email protected]>; Yigit, Ferruh <[email protected]>; > > Jerin Jacob Kollanukkaran <[email protected]>; Thomas Monjalon > > <[email protected]> > > Cc: Ankur Dwivedi <[email protected]>; Hemant Agrawal > > <[email protected]>; Matan Azrad <[email protected]>; > Nicolau, > > Radu <[email protected]>; Shahaf Shuler <[email protected]>; > > Narayana Prasad Raju Athreya <[email protected]>; [email protected] > > Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] ethdev: allow multiple > > security sessions to use one rte flow > > > > Hi Ori, > > > > Please see inline. > > > > Thanks, > > Anoob > > > > > -----Original Message----- > > > From: dev <[email protected]> On Behalf Of Ori Kam > > > Sent: Thursday, January 16, 2020 5:06 PM > > > To: Anoob Joseph <[email protected]>; Medvedkin, Vladimir > > > <[email protected]>; Ananyev, Konstantin > > > <[email protected]>; Akhil Goyal <[email protected]>; > > Adrien > > > Mazarguil <[email protected]>; Doherty, Declan > > > <[email protected]>; Yigit, Ferruh <[email protected]>; > > > Jerin > > Jacob > > > Kollanukkaran <[email protected]>; Thomas Monjalon > > > <[email protected]> > > > Cc: Ankur Dwivedi <[email protected]>; Hemant Agrawal > > > <[email protected]>; Matan Azrad <[email protected]>; > > Nicolau, > > > Radu <[email protected]>; Shahaf Shuler <[email protected]>; > > > Narayana Prasad Raju Athreya <[email protected]>; [email protected] > > > Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] ethdev: allow multiple > > > security sessions to use one rte flow > > > > > > > > > > > > > -----Original Message----- > > > > From: dev <[email protected]> On Behalf Of Anoob Joseph > > > > Sent: Tuesday, January 14, 2020 11:28 AM > > > > To: Ori Kam <[email protected]>; Medvedkin, Vladimir > > > > <[email protected]>; Ananyev, Konstantin > > > > <[email protected]>; Akhil Goyal <[email protected]>; > > > > Adrien Mazarguil <[email protected]>; Doherty, Declan > > > > <[email protected]>; Yigit, Ferruh > > > > <[email protected]>; Jerin Jacob Kollanukkaran > > > > <[email protected]>; Thomas Monjalon <[email protected]> > > > > Cc: Ankur Dwivedi <[email protected]>; Hemant Agrawal > > > > <[email protected]>; Matan Azrad <[email protected]>; > > > Nicolau, > > > > Radu <[email protected]>; Shahaf Shuler > > <[email protected]>; > > > > Narayana Prasad Raju Athreya <[email protected]>; [email protected] > > > > Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] ethdev: allow multiple > > > > security sessions to use one rte flow > > > > > > > > Hi Ori, > > > > > > > > Please see inline. > > > > > > > > Thanks, > > > > Anoob > > > > > > > > > -----Original Message----- > > > > > From: Ori Kam <[email protected]> > > > > > Sent: Thursday, January 9, 2020 1:06 PM > > > > > To: Medvedkin, Vladimir <[email protected]>; Ananyev, > > > > > Konstantin <[email protected]>; Anoob Joseph > > > > > <[email protected]>; Akhil Goyal <[email protected]>; Adrien > > > > > Mazarguil <[email protected]>; Doherty, Declan > > > > > <[email protected]>; Yigit, Ferruh > > > > > <[email protected]>; Jerin Jacob Kollanukkaran > > > > > <[email protected]>; Thomas Monjalon <[email protected]> > > > > > Cc: Ankur Dwivedi <[email protected]>; Hemant Agrawal > > > > > <[email protected]>; Matan Azrad <[email protected]>; > > > Nicolau, > > > > > Radu <[email protected]>; Shahaf Shuler > > <[email protected]>; > > > > > Narayana Prasad Raju Athreya <[email protected]>; > > [email protected] > > > > > Subject: RE: [dpdk-dev] [EXT] Re: [PATCH] ethdev: allow multiple > > > > > security sessions to use one rte flow > > > > > > > > > > Hi > > > > > sorry for jumping in late. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: dev <[email protected]> On Behalf Of Medvedkin, > > Vladimir > > > > > > Sent: Wednesday, January 8, 2020 4:30 PM > > > > > > To: Ananyev, Konstantin <[email protected]>; Anoob > > > > Joseph > > > > > > <[email protected]>; Akhil Goyal <[email protected]>; > > > > > > Adrien Mazarguil <[email protected]>; Doherty, Declan > > > > > > <[email protected]>; Yigit, Ferruh > > > > > > <[email protected]>; > > > > Jerin > > > > > > Jacob Kollanukkaran <[email protected]>; Thomas Monjalon > > > > > > <[email protected]> > > > > > > Cc: Ankur Dwivedi <[email protected]>; Hemant Agrawal > > > > > > <[email protected]>; Matan Azrad > > <[email protected]>; > > > > > > Nicolau, Radu <[email protected]>; Shahaf Shuler > > > > > > <[email protected]>; Narayana Prasad Raju Athreya > > > > > > <[email protected]>; [email protected] > > > > > > Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] ethdev: allow > > > > > > multiple security sessions to use one rte flow > > > > > > > > > > > > Hi Anoob, > > > > > > > > > > > > On 23/12/2019 13:34, Ananyev, Konstantin wrote: > > > > > > > > > > > > > >>>>>>>>>>>>>> The rte_security API which enables inline > > > > > protocol/crypto > > > > > > >>>>>>>>>>>>>> feature mandates that for every security > > > > > > >>>>>>>>>>>>>> session > > an > > > > > > rte_flow > > > > > > >>>>>>>>>>>>>> is > > > > > > >>>>> created. > > > > > > >>>>>>>>>>>>>> This would internally translate to a rule in > > > > > > >>>>>>>>>>>>>> the > > > > hardware > > > > > > >>>>>>>>>>>>>> which would do packet classification. > > > > > > >>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>> In rte_securty, one SA would be one security > > session. > > > > > And > > > > > > if > > > > > > >>>>>>>>>>>>>> an rte_flow need to be created for every > > > > > > >>>>>>>>>>>>>> session, the > > > > > > number > > > > > > >>>>>>>>>>>>>> of SAs supported by an inline implementation > > would > > > > be > > > > > > >>>>>>>>>>>>>> limited by the number of rte_flows the PMD > > would be > > > > > > able to > > > > > > >>> support. > > > > > > >>>>>>>>>>>>>> If the fields SPI & IP addresses are allowed to > > > > > > >>>>>>>>>>>>>> be a > > > > > range, > > > > > > >>>>>>>>>>>>>> then this limitation can be overcome. Multiple > > > > > > >>>>>>>>>>>>>> flows > > > > will > > > > > > be > > > > > > >>>>>>>>>>>>>> able to use one rule for SECURITY processing. > > > > > > >>>>>>>>>>>>>> In this > > > > > case, > > > > > > >>>>>>>>>>>>>> the security session provided as conf would be > > NULL. > > > > > > > > > > Why is that? > > > > > If the rte flow can have a range then this means that we need > > > > > one security_session for the entire range, Am I missing > > > > > something? As it is stated in the rte_fow.h security_session > > > > can > > > > > be used for multiple flows. > > > > > > > > [Anoob] One SA would mean one security_session. So if we have one > > > > security_session for the entire range, then it will be like having > > > > single SA for a range of IP & SPI. Do you think we should allow that? > > > > > > > [Ori] I'm less familiar with security, but this is what I understand > > > you are > > trying to > > > do right? > > > > [Anoob] Not exactly. In our implementation, h/w can index into a table > > which would hold security_sessions. So we can have one rte_flow rule, > > which will enable the packet steering in the hardware. Which session > > need to be used will be determined by the SPI. > > > > > > > > > Also, the intent of the patch is to minimize the number of > > > > rte_flow rules required for inline ipsec processing. Since the > > > > security session is per SA, and if we need multiple SPIs to use > > > > same rte_flow rule, then the security_session field in the rte_flow rule > need to be NULL. > > > > Having a non-zero security_session when SPI is a range would be > > incorrect. > > > > > > > [Ori] I'm all in favor decreasing number of flows. > > > Sorry for the basic question, what is the security_session /SA > > > dependent > > on? > > > > [Anoob] No prob! In case of unicast IPsec, every SA would have a unique SPI. > > So we cannot have multiple SPI's referring to the same SA. And one SA > > would mean one security_session. > > > > > Can one SA include number of different SPI? > > > > [Anoob] No. > > > > May be we need to reimagine this. > > > > Currently, an rte_flow with SECURITY enables ipsec processing with a > > specific security_session on the packet. This is enabled on a specific > > IP/SPI specified in the rule. > > > > My proposal: an rte_flow with SECURITY (and session = NULL), would > > enable ipsec processing on a range and SPI from the packet can be used > > by the h/w to further figure out the security_session. > > O.K. so SPI can't be shared between SA (Security_session) while IP can right? > Other why to ask my question is what is allowed to be in range to allow the > same security_session? [Anoob] With a single IP system, SPI is enough to uniquely identify an SA. So for such cases, DST_IP can be a range, and session can be non_null. In other words, in single IP systems, SPI would mean one tunnel and so DST_IP is not required to be looked up. Whether to do lookup on SPI only or DST_IP+SPI is determined by the configuration, and so it makes sense to allow such with rte_flow framework.
