[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CAE6737@AcuExch.aculab.com>
Date: Fri, 20 Feb 2015 10:01:10 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'David Miller' <davem@...emloft.net>,
"stephen@...workplumber.org" <stephen@...workplumber.org>
CC: "Yanjun.Zhu@...driver.com" <Yanjun.Zhu@...driver.com>,
"romieu@...zoreil.com" <romieu@...zoreil.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"mst@...hat.com" <mst@...hat.com>,
"jasowang@...hat.com" <jasowang@...hat.com>,
"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
"sergei.shtylyov@...entembedded.com"
<sergei.shtylyov@...entembedded.com>,
"jonathon.reinhart@...il.com" <jonathon.reinhart@...il.com>
Subject: RE: [PATCH 1/1] tun: change speed from 10M to dynamically configured
From: David Miller
...
> We need a consistent policy regarding link attributes of encapsulating
> "software" devices.
>
> I see three realistic options:
>
> 1) Create a link state indication which means "I am a software device,
> so I don't really have a link state in the traditional sense"
>
> 2) Don't implement the link set/get operations at all on software
> devices.
>
> People can use ETHTOOL_GLINK to see if the thing is "up"
>
> 3) Propagate the ultimate physical transport parameters into what
> the software device advertises.
>
> It's important to carefully pick one of these, and consistently apply
> it to all of our software devices.
You also need to be careful to not break existing 'stuff'.
We've connected a single USB ethernet port into a 'bond' (with
nothing else) in order to get a stable interface and IP address
that doesn't bounce on transient USB errors.
If the absence of the physical interface caused the state of bond0
to change and that got propagated through the routing tables then
we'd get TCP disconnects reported for things that would only see
recovered packet loss.
David
--
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