: David Wragg
---
drivers/net/geneve.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 028e387..7097570 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -1039,17 +1039,34 @@ static
Wrong comment style, fixed in v3.
David
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
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
Calculate the maximum MTU taking into account the size of headers
involved in GENEVE encapsulation, as for other tunnel types.
Changes in v2:
- Conform more closely to ip_tunnel_change_mtu
- Exclude GENEVE options from max MTU calculation
Signed-off-by: David Wragg
---
drivers/net/geneve.c
Jesse Gross writes:
> In addition to Tom's comment about taking into account
> dev->hard_header_len, can you please not include
> GENEVE_MAX_OPTIONS_LEN in the MTU calculation based on the discussion
> on the other thread? Otherwise, you are excluding some potentially
> valid configurations.
Addr
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 t
While GENEVE allows variable length options, the maximum length of the
options is 63 * 4 bytes. So we can reasonably set an MTU limit other
than IP_MAX_MTU, as the other tunnel devices do.
Signed-off-by: David Wragg
---
drivers/net/geneve.c | 11 ++-
1 file changed, 6 insertions(+), 5
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
vxlan, and prevented vxlan devices from being able
to take advantage of jumbo frames etc.
The default MTU remains 1500, for compatibility.
Signed-off-by: David Wragg
Acked-by: Roopa Prabhu
---
drivers/net/vxlan.c | 36 +---
1 file changed, 25 insertions(+), 11
maximum (i.e. the maximum IP packet size minus any relevant overhead),
effectively restoring the behaviour prior to 4.3.
Signed-off-by: David Wragg
---
drivers/net/geneve.c | 18 ++
drivers/net/vxlan.c | 11 ---
include/net/ip_tunnels.h | 1 +
net
IP_MAX_MTU is used instead.
Encapsulated packets that are too big for the underlying network will
get dropped on the floor.
Signed-off-by: David Wragg
---
drivers/net/geneve.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
vxlan, and prevented vxlan devices from being able
to take advantage of jumbo frames etc.
The default MTU remains 1500, for compatibility.
Signed-off-by: David Wragg
Acked-by: Roopa Prabhu
---
drivers/net/vxlan.c | 36 +---
1 file changed, 25 insertions(+), 11
and geneve as well
* Use IP_MAX_MTU
Changes in v3:
* Fix block comment style
David Wragg (3):
vxlan: Relax MTU constraints
geneve: Relax MTU constraints
vxlan, gre, geneve: Set a large MTU on ovs-created tunnel devices
drivers/net/geneve.c | 31 +++-
drivers
Sergei Shtylyov writes:
>The networking code formats comments:
>
> /* Like
> * this.
> */
Thanks. And I noticed another silly mistake. Will respin.
David
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
vxlan, and prevented vxlan devices from being able
to take advantage of jumbo frames etc.
The default MTU remains 1500, for compatibility.
Signed-off-by: David Wragg
Acked-by: Roopa Prabhu
---
drivers/net/vxlan.c | 36 +---
1 file changed, 25 insertions(+), 11
IP_MAX_MTU is used instead.
Encapsulated packets that are too big for the underlying network will
get dropped on the floor.
Signed-off-by: David Wragg
---
drivers/net/geneve.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
maximum (i.e. the maximum IP packet size minus any relevant overhead),
effectively restoring the behaviour prior to 4.3.
Signed-off-by: David Wragg
---
drivers/net/geneve.c | 17 +
drivers/net/vxlan.c | 11 ---
include/net/ip_tunnels.h | 1 +
net/ipv4
as well
* Use IP_MAX_MTU
David Wragg (3):
vxlan: Relax the MTU constraints
geneve: Relax MTU constraints
vxlan, gre, geneve: Set a large MTU on ovs-created tunnel devices
drivers/net/geneve.c | 29 +-
drivers/net/vxlan.c | 47
David Miller writes:
>> Considering non-openvswitch scenarios, when using vxlan netdevs
>> directly, a vxlan netdev locked to an underlying device supporting jumbo
>> frames can use a larger MTU. It's only vxlan netdevs without an
>> underlying device that have the limit of 1500 imposed. But why
Jesse Gross writes:
> On Wed, Jan 6, 2016 at 3:25 PM, David Wragg wrote:
>> I'm certainly open to suggestions of better ways to solve the problem.
>
> One option is to simply set the MTU on the device from userspace.
If that worked I wouldn't be submitting a patch.
The
David Miller writes:
>> Prior to 4.3, openvswitch vxlan vports could transmit vxlan packets of
>> any size, constrained only by the ability to transmit the resulting
>> UDP packets. 4.3 introduced vxlan netdevs corresponding to vxlan
>> vports. These netdevs have an MTU, which limits the size of
behaviour prior to 4.3. Although the
vxlan_config struct already had a mtu field for this,
vxlan_dev_configure mostly ignored it; that is also addressed here.
Signed-off-by: David Wragg
---
drivers/net/vxlan.c | 11 ---
net/openvswitch/vport-vxlan.c | 2 ++
2 files changed, 10
vxlan, and prevented such vxlan devices from being able to take
advantage of jumbo frames etc.
The default MTU remains 1500, for compatibility.
Signed-off-by: David Wragg
---
drivers/net/vxlan.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a
), effectively restoring the behaviour prior to 4.3. In order
to accomplish this, the first patch removes the MTU constraint of 1500
for vxlan netdevs without an underlying device.
David Wragg (2):
vxlan: Relax the MTU constraint on vxlan devices
vxlan: Set a large MTU on ovs-created vxlan devices
24 matches
Mail list logo
