[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEh+42jyh0EWwaOAu3KNSQKEv3NRgjPT_4QRYUmLRSXtsMgWJw@mail.gmail.com>
Date: Thu, 7 Apr 2016 20:22:57 -0300
From: Jesse Gross <jesse@...nel.org>
To: Alexander Duyck <aduyck@...antis.com>
Cc: herbert@...dor.apana.org.au, Tom Herbert <tom@...bertland.com>,
Alexander Duyck <alexander.duyck@...il.com>,
edumazet@...gle.com,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>
Subject: Re: [RFC PATCH 07/11] GENEVE: Add option to mangle IP IDs on inner
headers when using TSO
On Thu, Apr 7, 2016 at 7:32 PM, Alexander Duyck <aduyck@...antis.com> wrote:
> This patch adds support for a feature I am calling IP ID mangling. It is
> basically just another way of saying the IP IDs that are transmitted by the
> tunnel may not match up with what would normally be expected. Specifically
> what will happen is in the case of TSO the IP IDs on the headers will be a
> fixed value so a given TSO will repeat the same inner IP ID value gso_segs
> number of times.
>
> Signed-off-by: Alexander Duyck <aduyck@...antis.com>
If I'm understanding this correctly, enabling IP ID mangling will help
performance on ixgbe since it will allow it to do GSO partial instead
of plain GSO but it will hurt performance on i40e since it will drop
from TSO to plain GSO.
Assuming that's right, it seems like it will make it hard to chose the
right setting without knowledge of which hardware is in use. I guess
what we really want is "I care about nicely incrementing IP IDs" vs.
"I don't care as long as the DF bit is set". That second case is
really what this flag is trying to say but it seems like it is
enforcing too much in the i40e case - I don't think anyone wants to go
out of their way to make IP IDs jump around if incrementing is faster.
Powered by blists - more mailing lists