On Thu, Feb 18, 2016 at 8:54 AM, David Wragg wrote:
> Tom Herbert writes:
>> Please implement like in ip_tunnel_change_mtu (or better yet call it),
>> that is the precedent for tunnels.
>
> I've made geneve_change_mtu follow ip_tunnel_change_mtu in v2.
>
> If it were to call it instead, are you s
From: David Wragg
Date: Thu, 18 Feb 2016 16:54:14 +
> Tom Herbert writes:
>> Please implement like in ip_tunnel_change_mtu (or better yet call it),
>> that is the precedent for tunnels.
>
> I've made geneve_change_mtu follow ip_tunnel_change_mtu in v2.
>
> If it were to call it instead, ar
Tom Herbert writes:
> Please implement like in ip_tunnel_change_mtu (or better yet call it),
> that is the precedent for tunnels.
I've made geneve_change_mtu follow ip_tunnel_change_mtu in v2.
If it were to call it instead, are you suggesting just passing in
t_hlen? Or restructuring geneve.c to
On Tue, Feb 16, 2016 at 4:33 AM, David Wragg wrote:
> Jesse Gross writes:
>> On Wed, Feb 10, 2016 at 3:21 PM, Tom Herbert wrote:
>>> On Wed, Feb 10, 2016 at 12:59 PM, Jesse Gross wrote:
On Wed, Feb 10, 2016 at 12:41 PM, David Wragg wrote:
> Tom Herbert writes:
>> The correct thin
Jesse Gross writes:
> On Wed, Feb 10, 2016 at 3:21 PM, Tom Herbert wrote:
>> On Wed, Feb 10, 2016 at 12:59 PM, Jesse Gross wrote:
>>> On Wed, Feb 10, 2016 at 12:41 PM, David Wragg wrote:
Tom Herbert writes:
> The correct thing to do is determine the maximum amount of
> encapsulati
On Wed, Feb 10, 2016 at 3:21 PM, Tom Herbert wrote:
> On Wed, Feb 10, 2016 at 12:59 PM, Jesse Gross wrote:
>> On Wed, Feb 10, 2016 at 12:41 PM, David Wragg wrote:
>>> Tom Herbert writes:
The correct thing to do is determine the maximum amount of
encapsulation overhead that can ever be
On Wed, Feb 10, 2016 at 12:59 PM, Jesse Gross wrote:
> On Wed, Feb 10, 2016 at 12:41 PM, David Wragg wrote:
>> Tom Herbert writes:
>>> The correct thing to do is determine the maximum amount of
>>> encapsulation overhead that can ever be set in a packet and use for
>>> setting the MTU. For insta
On Wed, Feb 10, 2016 at 12:41 PM, David Wragg wrote:
> Tom Herbert writes:
>> The correct thing to do is determine the maximum amount of
>> encapsulation overhead that can ever be set in a packet and use for
>> setting the MTU. For instance, when RCO is enable in GUE, the size of
>> the option is
Tom Herbert writes:
> The correct thing to do is determine the maximum amount of
> encapsulation overhead that can ever be set in a packet and use for
> setting the MTU. For instance, when RCO is enable in GUE, the size of
> the option is included in tunnel->encap_hlen even though it will not
> be
On Tue, Feb 9, 2016 at 5:47 PM, David Wragg wrote:
> Allow the MTU of geneve devices to be set to large values, in order to
> exploit underlying networks with larger frame sizes.
>
> GENEVE does not have a fixed encapsulation overhead (an openvswitch
> rule can add variable length options), so the
Sergei Shtylyov writes:
>The networking code formats comments:
>
> /* Like
> * this.
> */
Thanks. And I noticed another silly mistake. Will respin.
David
On 02/09/2016 07:47 PM, David Wragg wrote:
Allow the MTU of geneve devices to be set to large values, in order to
exploit underlying networks with larger frame sizes.
GENEVE does not have a fixed encapsulation overhead (an openvswitch
rule can add variable length options), so there is no releva
Allow the MTU of geneve devices to be set to large values, in order to
exploit underlying networks with larger frame sizes.
GENEVE does not have a fixed encapsulation overhead (an openvswitch
rule can add variable length options), so there is no relevant maximum
MTU to enforce. A maximum of IP_MA
13 matches
Mail list logo
