From: Jesse Gross <jesse@kernel.org>
To: Alexander Duyck <aduyck@mirantis.com>
Cc: Edward Cree <ecree@solarflare.com>,
Linux Kernel Network Developers <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>,
Alexander Duyck <alexander.duyck@gmail.com>,
Tom Herbert <tom@herbertland.com>
Subject: Re: [RFC PATCH 9/9] ixgbe/ixgbevf: Add support for GSO partial
Date: Fri, 18 Mar 2016 19:05:43 -0700 [thread overview]
Message-ID: <CAEh+42hwfx6EEbE9pf6RFdL9xkcc60CbguSFm+c+QDa63UMymA@mail.gmail.com> (raw)
In-Reply-To: <20160318232535.14955.19028.stgit@localhost.localdomain>
On Fri, Mar 18, 2016 at 4:25 PM, Alexander Duyck <aduyck@mirantis.com> wrote:
> This patch adds support for partial GSO segmentation in the case of GRE or
> UDP encapsulated frames.
>
> The one bit in this patch that is a bit controversial is the fact that we
> are leaving the inner IPv4 IP ID as a static value in the case of
> segmentation. As per RFC6864 this should be acceptable as TCP frames set
> the DF bit so the IP ID should be ignored. However this is not always the
> case as header compression schemes for PPP and SLIP can end up taking a
> performance hit as they have to record the fact that the ID didn't change
> as expected.
>
> In addition GRO was examining the IP ID field as well. As such on older
> GRO implementations TSO frames from this driver may end up blocking GRO on
> the other end which will likely hurt performance instead of helping it.
>
> Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
I wasn't able to apply this patch, it seems like it might be based on
some Intel driver patches that haven't been merged into net-next yet?
next prev parent reply other threads:[~2016-03-19 2:06 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-18 23:24 [RFC PATCH 0/9] RFC6864 compliant GRO and GSO partial offload Alexander Duyck
2016-03-18 23:24 ` [RFC PATCH 1/9] ipv4/GRO: Allow multiple frames to use the same IP ID Alexander Duyck
2016-03-24 1:43 ` Jesse Gross
2016-03-24 2:21 ` Alexander Duyck
2016-03-28 4:57 ` Jesse Gross
2016-03-18 23:24 ` [RFC PATCH 2/9] gre: Enforce IP ID verification on outer headers Alexander Duyck
2016-03-18 23:24 ` [RFC PATCH 3/9] geneve: " Alexander Duyck
2016-03-18 23:25 ` [RFC PATCH 4/9] vxlan: " Alexander Duyck
2016-03-18 23:25 ` [RFC PATCH 5/9] gue: " Alexander Duyck
2016-03-18 23:25 ` [RFC PATCH 6/9] ethtool: Add support for toggling any of the GSO offloads Alexander Duyck
2016-03-19 0:18 ` Ben Hutchings
2016-03-19 0:30 ` Alexander Duyck
2016-03-19 1:42 ` Ben Hutchings
2016-03-19 2:01 ` Jesse Gross
2016-03-19 2:43 ` Alexander Duyck
2016-03-18 23:25 ` [RFC PATCH 7/9] GSO: Support partial segmentation offload Alexander Duyck
2016-03-22 17:00 ` Edward Cree
2016-03-22 17:47 ` Alexander Duyck
2016-03-22 19:40 ` Edward Cree
2016-03-22 20:11 ` Jesse Gross
2016-03-22 20:17 ` David Miller
2016-03-22 21:38 ` Alexander Duyck
2016-03-23 16:27 ` Edward Cree
2016-03-23 18:06 ` Alexander Duyck
2016-03-23 21:05 ` Edward Cree
2016-03-23 22:36 ` Alexander Duyck
2016-03-23 23:00 ` Edward Cree
2016-03-23 23:15 ` Alexander Duyck
2016-03-24 17:12 ` Edward Cree
2016-03-24 18:43 ` Alexander Duyck
2016-03-24 20:17 ` Edward Cree
2016-03-24 21:50 ` Alexander Duyck
2016-03-24 23:00 ` Edward Cree
2016-03-24 23:35 ` Alexander Duyck
2016-03-25 0:37 ` Edward Cree
2016-03-23 17:09 ` Tom Herbert
2016-03-23 18:19 ` Alexander Duyck
2016-03-24 1:37 ` Jesse Gross
2016-03-24 2:53 ` Alexander Duyck
2016-03-28 5:35 ` Jesse Gross
2016-03-28 5:36 ` Jesse Gross
2016-03-28 16:25 ` Alexander Duyck
2016-03-18 23:25 ` [RFC PATCH 8/9] i40e/i40evf: Add support for GSO partial with UDP_TUNNEL_CSUM and GRE_CSUM Alexander Duyck
2016-03-23 19:35 ` Jesse Gross
2016-03-23 20:21 ` Alexander Duyck
2016-03-18 23:25 ` [RFC PATCH 9/9] ixgbe/ixgbevf: Add support for GSO partial Alexander Duyck
2016-03-19 2:05 ` Jesse Gross [this message]
2016-03-19 2:42 ` Alexander Duyck
2016-03-21 18:50 ` [RFC PATCH 0/9] RFC6864 compliant GRO and GSO partial offload David Miller
2016-03-21 19:46 ` Alexander Duyck
2016-03-21 20:10 ` Jesse Gross
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=CAEh+42hwfx6EEbE9pf6RFdL9xkcc60CbguSFm+c+QDa63UMymA@mail.gmail.com \
--to=jesse@kernel.org \
--cc=aduyck@mirantis.com \
--cc=alexander.duyck@gmail.com \
--cc=davem@davemloft.net \
--cc=ecree@solarflare.com \
--cc=netdev@vger.kernel.org \
--cc=tom@herbertland.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).