Re: [dpdk-dev] [PATCH] examples/ipsec-secgw: fix usage of incorrect port

["Nicolau, Radu" <radu.nicolau@intel.com>]

Hi,

Please send a v2 with the doc update that describes the new behavior and I will ack it.

Regards,
Radu

> -----Original Message-----
> From: Anoob Joseph [mailto:ajoseph@caviumnetworks.com]
> Sent: Monday, November 13, 2017 7:25 PM
> To: Nicolau, Radu <radu.nicolau@intel.com>; Anoob Joseph
> <anoob.joseph@cavium.com>; Akhil Goyal <akhil.goyal@nxp.com>;
> Doherty, Declan <declan.doherty@intel.com>; Gonzalez Monroy, Sergio
> <sergio.gonzalez.monroy@intel.com>
> Cc: narayanaprasad.athreya@cavium.com;
> jerin.jacobkollanukkaran@cavium.com; dev@dpdk.org
> Subject: Re: [PATCH] examples/ipsec-secgw: fix usage of incorrect port
> 
> Hi,
> 
> Comments below
> 
> 
> On 13-11-2017 22:53, Radu Nicolau wrote:
> > Hi,
> >
> > Comments below
> >
> > On 11/13/2017 4:13 PM, Anoob Joseph wrote:
> >> When security offload is enabled, the packet should be forwarded on
> >> the port configured in the SA. Security session will be configured on
> >> that port only, and sending the packet on other ports could result in
> >> unencrypted packets being sent out.
> > With a properly configured SP, SA and routing rule this will not
> > happen, so we don't need to do this fix to make up for a wrongly
> > written configuration file.
> > I'm almost sure that the app will behave in the same way (i.e. forward
> > unencrypted) for lookaside crypto if the configuration is incorrect.
> The lookaside crypto will ensure encryption, even if the LPM port is different.
> >>
> >> This would have performance improvements too, as the per packet LPM
> >> lookup would be avoided for IPsec packets, in inline mode.
> > Yes, there will be some performance gain, but not sure how much
> > considering that LPM lookup is reasonably fast.
> The 2nd lookup is significant for inline protocol for which I plan to submit
> some patches. In case of inline protocol, the packet need not have final
> headers by the time it is submitted to the ethernet driver.
> For example, in case of ESP in tunnel mode, tunnel IPs from the SA need to
> be used for LPM lookup. So all such cases(tunnel/transport, ipv4 tunnel in
> ipv6 and vice versa etc) need to be valuated and the final addresses need to
> be determined before an LPM lookup can be done, which adds significant
> overhead per packet.
> >
> > So I'm not sure if ack or nack, maybe Sergio can give a second opinion.
> > But if ack, you will have to update the patch to include in the doc
> > this behavior, the port configured in the SA takes precedence over the
> > one in the routing rule.
> >
> > Regards,
> > Radu
> 
> Thanks,
> Anoob