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? <Snip>
