[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKgT0UceXx6xHqpxZMqhn+Ftf-=NNLtZSjOduSMZL=jyHnQ5Ug@mail.gmail.com>
Date: Sat, 5 Dec 2015 11:34:29 -0800
From: Alexander Duyck <alexander.duyck@...il.com>
To: Tom Herbert <tom@...bertland.com>
Cc: David Miller <davem@...emloft.net>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
John Linville <linville@...driver.com>,
Jesse Gross <jesse@...nel.org>,
Anjali Singhai Jain <anjali.singhai@...el.com>,
Netdev <netdev@...r.kernel.org>,
Kiran Patil <kiran.patil@...el.com>
Subject: Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload
On Sat, Dec 5, 2015 at 9:53 AM, Tom Herbert <tom@...bertland.com> wrote:
>> Keep in mind I don't represent one of the hardware vendors here
>> anymore. I am approaching this from the customer point of view. I
>> would like to have the performance I can get out of the parts I have.
>
> Trying enabling UDP checksum, GRO/GSO, and Remote Checksum Offload in
> VXLAN. Assuming you have a NIC that at least provides UDP checksum
> offload and RSS for UDP (may need to be enabled) you can get good
> VXLAN performance across a varietyof legacy "dumb" NICs.
VXLAN offload support is already there so I can make use of that in
hardware. I assume we aren't talking about introducing a performance
regression by removing the VXLAN Rx port notification code.
Setting up any given environment I have to work with the hand I am
dealt. If I can make use of the work you did to do offloading with
standard NICs then I will, but more solutions for the performance with
tunnels is always better.
- Alex
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists