netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH] veth: keep peers MTU values synchronized
@ 2014-04-03 21:33 Ilya V. Matveychikov
  2014-04-04 14:25 ` David Miller
  0 siblings, 1 reply; 5+ messages in thread
From: Ilya V. Matveychikov @ 2014-04-03 21:33 UTC (permalink / raw)
  To: netdev; +Cc: i.matveychikov

Keep peers MTU values synchronized. That prevent dropping packets while
forwarding as diffirent MTU values prevent skb moving from one peer's 
device to another (is_skb_forwardable returns false).

Signed-off-by: Ilya V. Matveychikov <i.matveychikov@securitycode.ru>
---
  drivers/net/veth.c | 16 +++++++++++++++-
  1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index c0e7c64..a975226 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -227,10 +227,24 @@ static int is_valid_veth_mtu(int new_mtu)

  static int veth_change_mtu(struct net_device *dev, int new_mtu)
  {
+	int err, old_mtu;
+	struct veth_priv *priv = netdev_priv(dev);
+	struct net_device *peer = rtnl_dereference(priv->peer);
+
+	if (!peer)
+		return -ENOTCONN;
+
  	if (!is_valid_veth_mtu(new_mtu))
  		return -EINVAL;
+
+	old_mtu = dev->mtu;
  	dev->mtu = new_mtu;
-	return 0;
+
+	err = dev_set_mtu(peer, new_mtu);
+	if (err)
+		dev->mtu = old_mtu;
+
+	return err;
  }

  static int veth_dev_init(struct net_device *dev)
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [RFC PATCH] veth: keep peers MTU values synchronized
  2014-04-03 21:33 [RFC PATCH] veth: keep peers MTU values synchronized Ilya V. Matveychikov
@ 2014-04-04 14:25 ` David Miller
  2014-04-04 14:42   ` Ilya V. Matveychikov
  0 siblings, 1 reply; 5+ messages in thread
From: David Miller @ 2014-04-04 14:25 UTC (permalink / raw)
  To: matvejchikov; +Cc: netdev, i.matveychikov

From: "Ilya V. Matveychikov" <matvejchikov@gmail.com>
Date: Fri, 04 Apr 2014 01:33:04 +0400

> Keep peers MTU values synchronized. That prevent dropping packets
> while
> forwarding as diffirent MTU values prevent skb moving from one peer's
> device to another (is_skb_forwardable returns false).
> 
> Signed-off-by: Ilya V. Matveychikov <i.matveychikov@securitycode.ru>

Such side effects on another device when changing the configuration
of one are strongly discouraged.

Furthermore, when the veth peer is created, no attempt is made to
synchronize the MTUs.

Let it therefore be the admins responsibility to keep them in sync
just as it would be on a real network.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC PATCH] veth: keep peers MTU values synchronized
  2014-04-04 14:25 ` David Miller
@ 2014-04-04 14:42   ` Ilya V. Matveychikov
  2014-04-04 14:49     ` David Miller
  0 siblings, 1 reply; 5+ messages in thread
From: Ilya V. Matveychikov @ 2014-04-04 14:42 UTC (permalink / raw)
  To: David Miller, matvejchikov; +Cc: netdev

On 04.04.2014 18:25, David Miller wrote:
> From: "Ilya V. Matveychikov" <matvejchikov@gmail.com>
> Date: Fri, 04 Apr 2014 01:33:04 +0400
> 
>> Keep peers MTU values synchronized. That prevent dropping packets
>> while
>> forwarding as diffirent MTU values prevent skb moving from one peer's
>> device to another (is_skb_forwardable returns false).
>>
>> Signed-off-by: Ilya V. Matveychikov <i.matveychikov@securitycode.ru>
> 
> Such side effects on another device when changing the configuration
> of one are strongly discouraged.
> 

Devices are paired. It means that one depends on another. Is there any case
where this "side" effect wouldn't be helpful?

> Furthermore, when the veth peer is created, no attempt is made to
> synchronize the MTUs.

Peers are created at once and ether_setup used for the configuration so MTU
values equals.

> 
> Let it therefore be the admins responsibility to keep them in sync
> just as it would be on a real network.
> 
> 

Different MTU values for the veth pairs are meaningless as if so we can't do the
communication between the namespaces at all. So, is it correct to shift all the
configuration problems to admins?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC PATCH] veth: keep peers MTU values synchronized
  2014-04-04 14:42   ` Ilya V. Matveychikov
@ 2014-04-04 14:49     ` David Miller
  2014-04-04 15:04       ` Ilya V. Matveychikov
  0 siblings, 1 reply; 5+ messages in thread
From: David Miller @ 2014-04-04 14:49 UTC (permalink / raw)
  To: i.matveychikov; +Cc: matvejchikov, netdev

From: "Ilya V. Matveychikov" <i.matveychikov@securitycode.ru>
Date: Fri, 4 Apr 2014 18:42:29 +0400

> Peers are created at once and ether_setup used for the configuration so MTU
> values equals.

If an IFLA_MTU value is specified for the peer it will be honored.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC PATCH] veth: keep peers MTU values synchronized
  2014-04-04 14:49     ` David Miller
@ 2014-04-04 15:04       ` Ilya V. Matveychikov
  0 siblings, 0 replies; 5+ messages in thread
From: Ilya V. Matveychikov @ 2014-04-04 15:04 UTC (permalink / raw)
  To: David Miller; +Cc: matvejchikov, netdev

On 04.04.2014 18:49, David Miller wrote:
> From: "Ilya V. Matveychikov" <i.matveychikov@securitycode.ru>
> Date: Fri, 4 Apr 2014 18:42:29 +0400
> 
>> Peers are created at once and ether_setup used for the configuration so MTU
>> values equals.
> 
> If an IFLA_MTU value is specified for the peer it will be honored.
> 
> 

OK, I see it. Does that mean that the patch needs to be updated or the proposed
behavior is incorrect and must not be in kernel?

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2014-04-04 15:04 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-04-03 21:33 [RFC PATCH] veth: keep peers MTU values synchronized Ilya V. Matveychikov
2014-04-04 14:25 ` David Miller
2014-04-04 14:42   ` Ilya V. Matveychikov
2014-04-04 14:49     ` David Miller
2014-04-04 15:04       ` Ilya V. Matveychikov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).