From: David Miller <davem@davemloft.net>
To: aduyck@mirantis.com
Cc: herbert@gondor.apana.org.au, tom@herbertland.com,
jesse@kernel.org, alexander.duyck@gmail.com, edumazet@google.com,
netdev@vger.kernel.org
Subject: Re: [net-next PATCH v2 0/5] GRO Fixed IPv4 ID support and GSO partial support
Date: Thu, 14 Apr 2016 16:24:00 -0400 (EDT) [thread overview]
Message-ID: <20160414.162400.576736312272421011.davem@davemloft.net> (raw)
In-Reply-To: <20160411013855.11189.56567.stgit@ahduyck-xeon-server>
From: Alexander Duyck <aduyck@mirantis.com>
Date: Sun, 10 Apr 2016 21:44:38 -0400
> This patch series sets up a few different things.
>
> First it adds support for GRO of frames with a fixed IP ID value. This
> will allow us to perform GRO for frames that go through things like an IPv6
> to IPv4 header translation.
>
> The second item we add is support for segmenting frames that are generated
> this way. Most devices only support an incrementing IP ID value, and in
> the case of TCP the IP ID can be ignored in many cases since the DF bit
> should be set. So we can technically segment these frames using existing
> TSO if we are willing to allow the IP ID to be mangled. As such I have
> added a matching feature for the new form of GRO/GSO called TCP IPv4 ID
> mangling. With this enabled we can assemble and disassemble a frame with
> the sequence number fixed and the only ill effect will be that the IPv4 ID
> will be altered which may or may not have any noticeable effect. As such I
> have defaulted the feature to disabled.
>
> The third item this patch series adds is support for partial GSO
> segmentation. Partial GSO segmentation allows us to split a large frame
> into two pieces. The first piece will have an even multiple of MSS worth
> of data and the headers before the one pointed to by csum_start will have
> been updated so that they are correct for if the data payload had already
> been segmented. By doing this we can do things such as precompute the
> outer header checksums for a frame to be segmented allowing us to perform
> TSO on devices that don't support tunneling, or tunneling with outer header
> checksums.
>
> This patch set is based on the net-next tree, but I included "net: remove
> netdevice gso_min_segs" in my tree as I assume it is likely to be applied
> before this patch set will and I wanted to avoid a merge conflict.
>
> v2: Fixed items reported by Jesse Gross
> fixed missing GSO flag in MPLS check
> adding DF check for MANGLEID
> Moved extra GSO feature checks into gso_features_check
> Rebased batches to account for "net: remove netdevice gso_min_segs"
>
> Driver patches from the first patch set should still be compatible. However
> I do have a few changes in them so I will submit a v2 of those to Jeff
> Kirsher once these patches are accepted into net-next.
>
> Example driver patches for i40e, ixgbe, and igb:
> https://patchwork.ozlabs.org/patch/608221/
> https://patchwork.ozlabs.org/patch/608224/
> https://patchwork.ozlabs.org/patch/608225/
Series applied, thanks Alexander.
prev parent reply other threads:[~2016-04-14 20:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-11 1:44 [net-next PATCH v2 0/5] GRO Fixed IPv4 ID support and GSO partial support Alexander Duyck
2016-04-11 1:44 ` [net-next PATCH v2 1/5] ethtool: Add support for toggling any of the GSO offloads Alexander Duyck
2016-04-11 1:44 ` [net-next PATCH v2 2/5] GSO: Add GSO type for fixed IPv4 ID Alexander Duyck
2016-04-11 1:44 ` [net-next PATCH v2 3/5] GRO: Add support for TCP with fixed IPv4 ID field, limit tunnel IP ID values Alexander Duyck
2016-04-11 1:45 ` [net-next PATCH v2 4/5] GSO: Support partial segmentation offload Alexander Duyck
2016-04-11 1:45 ` [net-next PATCH v2 5/5] Documentation: Add documentation for TSO and GSO features Alexander Duyck
2016-04-14 20:24 ` David Miller [this message]
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=20160414.162400.576736312272421011.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=aduyck@mirantis.com \
--cc=alexander.duyck@gmail.com \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=jesse@kernel.org \
--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).