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:ajos...@caviumnetworks.com] > Sent: Monday, November 13, 2017 7:25 PM > To: Nicolau, Radu <radu.nico...@intel.com>; Anoob Joseph > <anoob.jos...@cavium.com>; Akhil Goyal <akhil.go...@nxp.com>; > Doherty, Declan <declan.dohe...@intel.com>; Gonzalez Monroy, Sergio > <sergio.gonzalez.mon...@intel.com> > Cc: narayanaprasad.athr...@cavium.com; > jerin.jacobkollanukka...@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
