From: Jesse Brandeburg <jesse.brandeburg@intel.com>
To: Shannon Nelson <shannon.nelson@oracle.com>
Cc: Alexander Duyck <alexander.duyck@gmail.com>,
intel-wired-lan <intel-wired-lan@lists.osuosl.org>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
Steffen Klassert <steffen.klassert@secunet.com>,
Netdev <netdev@vger.kernel.org>,
"Sowmini Varadhan" <sowmini.varadhan@oracle.com>,
jesse.brandeburg@intel.com
Subject: Re: [Intel-wired-lan] [PATCH v2 next-queue 08/10] ixgbe: process the Tx ipsec offload
Date: Fri, 15 Dec 2017 11:20:58 -0800 [thread overview]
Message-ID: <20171215112058.00007963@intel.com> (raw)
In-Reply-To: <7fe36ce0-be09-828d-16e5-776add0a182d@oracle.com>
On Tue, 12 Dec 2017 21:45:13 -0800
Shannon Nelson <shannon.nelson@oracle.com> wrote:
> > Also you are still setting the TCP flag for these packets. I'm
> > wondering if the TCP flag is really needed. I get that your current
> > setup only runs on TCP flows but what about other types of flows?
> > Couldn't UDP be encapsulated via ESP?
>
> That L4T_TCP bit annoys me - if I don't set it, the offload doesn't
> work, whether doing csum offload or not.
>
> The UDP messages can be encapsulated, but they don't seem to go down the
> offload route. I haven't looked into why yet.
L4T_TCP, AFAIK is a control of whether or not the L4 checksum generated
by the offload hardware uses the "never equal 0" logic required by TCP
checksums, but not required by UDP checksums. Not sure if that helps,
or even really applies to the case where you're doing IPSEC offload.
Seems like something else is at play as well (undocumented HW
requirements?)
next prev parent reply other threads:[~2017-12-15 19:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-12 23:36 [PATCH v2 next-queue 00/10] ixgbe: Add ipsec offload Shannon Nelson
2017-12-12 23:36 ` [PATCH v2 next-queue 01/10] ixgbe: clean up ipsec defines Shannon Nelson
2017-12-12 23:36 ` [PATCH v2 next-queue 02/10] ixgbe: add ipsec register access routines Shannon Nelson
2017-12-12 23:36 ` [PATCH v2 next-queue 03/10] ixgbe: add ipsec engine start and stop routines Shannon Nelson
2017-12-12 23:36 ` [PATCH v2 next-queue 04/10] ixgbe: add ipsec data structures Shannon Nelson
2017-12-12 23:36 ` [PATCH v2 next-queue 05/10] ixgbe: add ipsec offload add and remove SA Shannon Nelson
2017-12-12 23:36 ` [PATCH v2 next-queue 06/10] ixgbe: restore offloaded SAs after a reset Shannon Nelson
2017-12-12 23:37 ` [PATCH v2 next-queue 07/10] ixgbe: process the Rx ipsec offload Shannon Nelson
2017-12-12 23:37 ` [PATCH v2 next-queue 08/10] ixgbe: process the Tx " Shannon Nelson
2017-12-13 1:59 ` [Intel-wired-lan] " Alexander Duyck
2017-12-13 5:45 ` Shannon Nelson
2017-12-15 19:20 ` Jesse Brandeburg [this message]
2017-12-15 20:10 ` kbuild test robot
2017-12-15 20:22 ` Shannon Nelson
2017-12-15 21:18 ` kbuild test robot
2017-12-12 23:37 ` [PATCH v2 next-queue 09/10] ixgbe: ipsec offload stats Shannon Nelson
2017-12-12 23:37 ` [PATCH v2 next-queue 10/10] ixgbe: register ipsec offload with the xfrm subsystem Shannon Nelson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171215112058.00007963@intel.com \
--to=jesse.brandeburg@intel.com \
--cc=alexander.duyck@gmail.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jeffrey.t.kirsher@intel.com \
--cc=netdev@vger.kernel.org \
--cc=shannon.nelson@oracle.com \
--cc=sowmini.varadhan@oracle.com \
--cc=steffen.klassert@secunet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).