On Fri, Jan 04, 2019 at 10:43:45AM +0000, Raed Salem wrote: > > > > -----Original Message----- > > From: Steffen Klassert [mailto:steffen.klass...@secunet.com] > > Sent: Friday, January 04, 2019 8:34 AM > > To: Raed Salem <ra...@mellanox.com> > > Cc: Boris Pismenny <bor...@mellanox.com>; Yossi Kuperman > > <yoss...@mellanox.com>; netdev@vger.kernel.org; > > herb...@gondor.apana.org.au; da...@davemloft.net > > Subject: Re: [PATCH ipsec] xfrm: fix non-GRO codepath for IPsec hardware > > offloading > > > > On Thu, Dec 27, 2018 at 01:32:14PM +0000, Raed Salem wrote: > > > In xfrm_input() when called with IPsec hardware offload done and > > > without GRO, encap_type == 0, we end up skipping esp_input_tail as > > > crypto_done is set only within GRO code path, fix by move out > > > crypto_done assignment from the GRO code path and change code > > > accordingly > > > > We currently don't support IPsec hardware offload without GRO enabled. > > This is because the IPsec hardware offload does not decapsulate the packet. > > So the reverse policy check is done on the outer header instead of the inner > > header for tunnel mode. This means that the reverse policy check will fail > > for > > almost all tunnel mode configurations. The packet must be decapsulated > > before we do the policy check, and that's not the case without GRO. > > > > How did you test this? > Used the iproute to configure IPsec hardware offload in transport mode with > gro off, > Running traffic using ping
How does your SA and policy database look like?
