[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <26D9FDECA4FBDD4AADA65D8E2FC68A4A1D310D70@FMSMSX152.amr.corp.intel.com>
Date: Mon, 22 Oct 2018 19:39:28 +0000
From: "Bowers, AndrewX" <andrewx.bowers@...el.com>
To: "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [Intel-wired-lan] [PATCH] ixgbe: allow IPsec Tx offload in VEPA
mode
> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@...osl.org] On
> Behalf Of Shannon Nelson
> Sent: Thursday, October 4, 2018 4:29 PM
> To: intel-wired-lan@...ts.osuosl.org; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@...el.com>
> Cc: netdev@...r.kernel.org
> Subject: [Intel-wired-lan] [PATCH] ixgbe: allow IPsec Tx offload in VEPA
> mode
>
> When it's possible that the PF might end up trying to send a packet to one of
> its own VFs, we have to forbid IPsec offload because the device drops the
> packets into a black hole.
> See commit 47b6f50077e6 ("ixgbe: disallow IPsec Tx offload when in SR-IOV
> mode") for more info.
>
> This really is only necessary when the device is in the default VEB mode. If
> instead the device is running in VEPA mode, the packets will go through the
> encryption engine and out the MAC/PHY as normal, and get "hairpinned" as
> needed by the switch.
>
> So let's not block IPsec offload when in VEPA mode. To get there with the
> ixgbe device, use the handy 'bridge' command:
> bridge link set dev eth1 hwmode vepa
>
> Signed-off-by: Shannon Nelson <shannon.nelson@...cle.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Tested-by: Andrew Bowers <andrewx.bowers@...el.com>
Powered by blists - more mailing lists