On Mon, Jan 14, 2019 at 08:47:37AM +, Raed Salem wrote:
> > -Original Message-
> > From: Steffen Klassert [mailto:steffen.klass...@secunet.com]
> >
> > I'm thinking about removing the no_policy flag from the IPsec protocols to
> > actually do the inbound policy check for these protocol
> Subject: Re: [PATCH ipsec] xfrm: fix non-GRO codepath for IPsec hardware
> offloading
>
> On Mon, Jan 07, 2019 at 09:53:31AM +, Raed Salem wrote:
> >
> > tested based on kernel v4.20-rc7 with the patch it works when configured
> with hw offload and without gro:
> &g
On Mon, Jan 07, 2019 at 09:53:31AM +, Raed Salem wrote:
>
> tested based on kernel v4.20-rc7 with the patch it works when configured with
> hw offload and without gro:
> topology used:
> Server A (192.168.8.2) <--> GW C <---> GW D <--> Server B (192.168.9.4):
> Server A (vm) connected to gate
ubject: Re: [PATCH ipsec] xfrm: fix non-GRO codepath for IPsec hardware
> offloading
>
> On Fri, Jan 04, 2019 at 11:17:33AM +, Raed Salem wrote:
> > >
> > > I guess this works because of transport mode, here we don't have
> > > different inner and outer
> -Original Message-
> From: Steffen Klassert [mailto:steffen.klass...@secunet.com]
> Sent: Friday, January 04, 2019 1:22 PM
>
> On Fri, Jan 04, 2019 at 11:17:33AM +, Raed Salem wrote:
> > >
> > > I guess this works because of transport mode, here we don't have
> > > different inner
On Fri, Jan 04, 2019 at 11:17:33AM +, Raed Salem wrote:
> >
> > I guess this works because of transport mode, here we don't have different
> > inner and outer IP headers. Can you please test this with some tunnel mode
> > configurations?
> Sure,
> Works with the following SA and policy DB:
> i
> -Original Message-
> From: Steffen Klassert [mailto:steffen.klass...@secunet.com]
> Sent: Friday, January 04, 2019 12:55 PM>
> On Fri, Jan 04, 2019 at 10:49:55AM +, Raed Salem wrote:
> > > -Original Message-
> > > From: Steffen Klassert [mailto:steffen.klass...@secunet.com
On Fri, Jan 04, 2019 at 10:49:55AM +, Raed Salem wrote:
> > -Original Message-
> > From: Steffen Klassert [mailto:steffen.klass...@secunet.com]
> > > >
> > > > We currently don't support IPsec hardware offload without GRO enabled.
> > > > This is because the IPsec hardware offload does
uary 04, 2019 8:34 AM
> > > To: Raed Salem
> > > Cc: Boris Pismenny ; Yossi Kuperman
> > > ; netdev@vger.kernel.org;
> > > herb...@gondor.apana.org.au; da...@davemloft.net
> > > Subject: Re: [PATCH ipsec] xfrm: fix non-GRO codepath for IPsec
> > >
uperman
> > ; 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 +, Raed Salem wrote:
> > > I
ubject: Re: [PATCH ipsec] xfrm: fix non-GRO codepath for IPsec hardware
> offloading
>
> On Thu, Dec 27, 2018 at 01:32:14PM +, Raed Salem wrote:
> > In xfrm_input() when called with IPsec hardware offload done and
> > without GRO, encap_type == 0, we end up skipping esp_inp
On Thu, Dec 27, 2018 at 01:32:14PM +, 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
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
Fixes: d77e38e612a0 ("xfrm:
13 matches
Mail list logo
