From: David Ahern <dsahern@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>,
David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, jiri@resnulli.us, cphealy@gmail.com,
andrew@lunn.ch, jakub.kicinski@netronome.com, decot@googlers.com,
jhs@mojatatu.com, xiyou.wangcong@gmail.com, daniel@iogearbox.net,
nikolay@cumulusnetworks.com, ast@fb.com,
roopa@cumulusnetworks.com, vyasevich@gmail.com,
jonas@southpole.se, maheshb@google.com,
stephen@networkplumber.org, ishkamiel@gmail.com, fw@strlen.de,
arvind.yadav.cs@gmail.com, avagin@openvz.org, mingo@kernel.org,
lucien.xin@gmail.com, mschiffer@universe-factory.net,
jbenc@redhat.com, linux-kernel@vger.kernel.org
Subject: lightweight netdevs Jan 2018 edition [Re: [PATCH net-next v2] net: core: Expose number of link up/down transitions]
Date: Mon, 22 Jan 2018 15:16:19 -0700 [thread overview]
Message-ID: <03a12c50-3cdb-c494-9713-748f1b1ccb70@gmail.com> (raw)
In-Reply-To: <c9e5c051-b8b8-6319-cde9-41165ad8b37e@gmail.com>
On 1/22/18 1:46 PM, Florian Fainelli wrote:
>>
>> Like David Ahern I am strongly against the proliferation of sysfs files
>> attached to network devices and the per-netdevice costs associated with
>> that.
>>
>> However, dealing with that is a longer term issue that nobody has a clear
>> plan for. Therefore I cannot reject this change on that basis alone.
>>
>> The information is useful, so applied, thanks.
>
> Thanks! David A, do you have any plans to revive your LWD/LWT devices
> patches, AFAIR you were allowing a knob disabling the creation of sysfs
> attributes.
>
At the moment (and for the next few months) I am focusing on route
scalability:
http://vger.kernel.org/netconf2017_files/nexthop-objects.pdf
I do think about the lightweight netdevice need from time to time. If
anyone has the time and wants to pick it up, the patches are on github:
https://github.com/dsahern/linux net/lwt-dev
https://github.com/dsahern/iproute2 lwt-dev
As a refresher on the concept, the intention is that users can *opt in*
to skipping the overhead of standard netdevs by adding a flag during the
link create.
Virtual devices such as vlan, macvlan, ipvlan, vrf, dummy are great
candidates for this flag, and potentially bonds and bridges if the
deployment use case is ok with what the lightweight moniker means which is:
1. no sysfs files for the device
2. no separate sysctl tree for the device (default settings are used)
3. delayed network protocol (IPv4, IPv6, MPLS) initializations
The last one dove tails with the need for L2 only devices and suggests a
the need for a separate control flag. If you dig further into the
protocol initializations one could easily justify flags for a finer
granularity on what is skipped (e.g., do protocol init, but skip netconf
(use default values) and skip snmp stats).
Slide 9 in
https://www.netdevconf.org/1.1/proceedings/slides/ahern-aleksandrov-prabhu-scaling-network-cumulus.pdf
shows the memory allocations. 40+kB / netdev is a killer. Using the lwt
tag, that can be shrunk from ~44k to ~4k - a big gain. e.g., 4k VRFs
(yes, I have been asked about that) would go from ~160MB to just ~16MB.
As I recall the kernel patch is not complete, only shows the intent and
what the flag offers (pain is worth the gain). During the last
discussion on this the idea of a net_dev_common was suggested. After
looking into it I believe it is the wrong direction -- an unnecessary
churn on the code base when the only intention is to omit / bypass
existing code paths. The common would come in handy in trying to reduce
the size of 'struct net_device' which is driven by 'struct device' and
similar h/w entries.
prev parent reply other threads:[~2018-01-22 22:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-18 17:59 [PATCH net-next v2] net: core: Expose number of link up/down transitions Florian Fainelli
2018-01-22 20:43 ` David Miller
2018-01-22 20:46 ` Florian Fainelli
2018-01-22 22:16 ` David Ahern [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=03a12c50-3cdb-c494-9713-748f1b1ccb70@gmail.com \
--to=dsahern@gmail.com \
--cc=andrew@lunn.ch \
--cc=arvind.yadav.cs@gmail.com \
--cc=ast@fb.com \
--cc=avagin@openvz.org \
--cc=cphealy@gmail.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=decot@googlers.com \
--cc=f.fainelli@gmail.com \
--cc=fw@strlen.de \
--cc=ishkamiel@gmail.com \
--cc=jakub.kicinski@netronome.com \
--cc=jbenc@redhat.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=jonas@southpole.se \
--cc=linux-kernel@vger.kernel.org \
--cc=lucien.xin@gmail.com \
--cc=maheshb@google.com \
--cc=mingo@kernel.org \
--cc=mschiffer@universe-factory.net \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=roopa@cumulusnetworks.com \
--cc=stephen@networkplumber.org \
--cc=vyasevich@gmail.com \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®