netdev - Re: [RFC PATCH 9/9] ixgbe/ixgbevf: Add support for GSO partial

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEh+42hwfx6EEbE9pf6RFdL9xkcc60CbguSFm+c+QDa63UMymA@mail.gmail.com>
Date:	Fri, 18 Mar 2016 19:05:43 -0700
From:	Jesse Gross <jesse@...nel.org>
To:	Alexander Duyck <aduyck@...antis.com>
Cc:	Edward Cree <ecree@...arflare.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Alexander Duyck <alexander.duyck@...il.com>,
	Tom Herbert <tom@...bertland.com>
Subject: Re: [RFC PATCH 9/9] ixgbe/ixgbevf: Add support for GSO partial

On Fri, Mar 18, 2016 at 4:25 PM, Alexander Duyck <aduyck@...antis.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@...antis.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?