[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150219.154041.184372158520813993.davem@davemloft.net>
Date: Thu, 19 Feb 2015 15:40:41 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: stephen@...workplumber.org
Cc: Yanjun.Zhu@...driver.com, romieu@...zoreil.com,
netdev@...r.kernel.org, mst@...hat.com, jasowang@...hat.com,
viro@...iv.linux.org.uk, sergei.shtylyov@...entembedded.com,
jonathon.reinhart@...il.com
Subject: Re: [PATCH 1/1] tun: change speed from 10M to dynamically
configured
From: Stephen Hemminger <stephen@...workplumber.org>
Date: Mon, 16 Feb 2015 12:03:45 -0500
> I would like to propose this is as a more complete alternative.
>
> From: Stephen Hemminger <stephen@...workpluber.org>
> Subject: [PATCH] tun: support overriding ethtool information
>
> Extensions to allow masqurade of ethtool info and device statistics.
> This is useful to provide correct information to SNMP and OSPF routing
> daemons when doing hw/sw offload of network device.
>
> Signed-off-by: Stephen Hemminger <stephen@...workplumber.org>
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.
I don't want TUN doing one thing, ipv4 tunnels doing another, etc.
--
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