[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140506164546.GB20536@cloud>
Date: Tue, 6 May 2014 09:45:46 -0700
From: josh@...htriplett.org
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: David Miller <davem@...emloft.net>, andi@...stfloor.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
tom.zanussi@...ux.intel.com, ak@...ux.intel.com
Subject: Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 09:39:19AM -0700, Eric Dumazet wrote:
> On Tue, 2014-05-06 at 08:57 -0700, josh@...htriplett.org wrote:
>
> > A NAK isn't going to cut it, here; tiny Linux systems are going to
> > exist, and they shouldn't have to maintain a long-term out-of-tree fork
> > or use crazy things like LWIP.
>
> What's wrong with user space implementations of networking stacks ?
What's wrong with the kernel implementation?
> For many usages, it can bring 10 times the performance of having user
> application and kernel sockets.
Sounds like we have some optimization to do, then; there's no
fundamental unfixable reason for that delta.
> In any cases, we do not model kernel implementations to 'compete' with
> user space.
>
> We simply can not compete with user space, as a programmer is free to
> keep what he really wants/needs.
The kernel can do the same. Consider the idea of analyzing a set of
userspace programs, determining what kernel functionality they do and
don't need, feeding that information into the kernel build process, and
automatically dropping unused bits of the kernel.
Ideally, that kind of process would support eliminating kernel config
options that just select userspace-visible interfaces, leaving only the
kernel config options that change how those interfaces behave
(size/performance/feature tradeoffs).
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists