netdev - Re: [RFC] tcp: add support for scheduling TCP options on TCP sockets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1399476728.15399.146.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Wed, 07 May 2014 08:32:08 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Octavian Purdila <octavian.purdila@...el.com>
Cc:	Christoph Paasch <christoph.paasch@...ouvain.be>,
	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC] tcp: add support for scheduling TCP options on TCP sockets

On Wed, 2014-05-07 at 18:17 +0300, Octavian Purdila wrote:

> 
> That would require adding a new field to sk_buff to keep track of how
> much we need to copy in pskb_copy. Fortunately it seems it has some
> holes we could use.
> 
> David, does that seem reasonable?

MPTCP and/or Minion could be implemented in user land, with a generic
infrastructure in the kernel to directly pass raw packets once demux
has been done by the kernel.

Large CDN cant always assume multi paths to hit a particular destination
can all originate from a single host in the datacenter.

MPTCP has this hard assumption from day one.

Our team try to focus on making TCP better, we believe all these
experimental features do not belong to the kernel yet.

--
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