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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 8 May 2014 10:32:47 +0200
From:	Christoph Paasch <christoph.paasch@...ouvain.be>
To:	David Miller <davem@...emloft.net>
Cc:	"octavian.purdila@...el.com" <octavian.purdila@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC] tcp: add support for scheduling TCP options on TCP sockets

On 07/05/14 - 16:48:59, David Miller wrote:
> From: Octavian Purdila <octavian.purdila@...el.com>
> Date: Wed, 7 May 2014 10:30:23 +0300
> 
> > On Wed, May 7, 2014 at 8:38 AM, David Miller <davem@...emloft.net> wrote:
> >>
> >> From: Octavian Purdila <octavian.purdila@...el.com>
> >> Date: Tue,  6 May 2014 21:05:24 +0300
> >>
> >> > Pardon the rough patch, but I hope it is enough to get some feedback
> >> > on the overall approach.
> >>
> >> Sorry I don't like this.
> >>
> >> Walking a linked list unnecessary is going to add overhead to every
> >> single packet transmission.  I think more people want our TCP stack to
> >> be fast (everyone) than those who want option processing to be
> >> abstracted enough to be modular (you).
> >>
> >> Just make the intrusive changes, they are necessary as they force you
> >> to think fully about how one option might interact with another.
> >>
> > 
> > Unfortunately skb_tcp_cb does not have enough space to hold
> > information for new large options. To work around that, the MPTCP
> > implementation is pushing the option data in the skb and then
> > occasionally uses the following when the pskb_copy is used:
> 
> Why not deal with the problem directly by trying to find a way to
> compress the existing use of skb_tcp_cb() so that there is actually
> the amount of space you need?

It might be possible to replace accesses to end_seq by calculating (seq + len + fin/syn)
That way, we gain 4 bytes. Would this be acceptable?

And union tcp_flags/ip_dsfield as suggested in b82d1bb4fd206 (tcp: unalias
tcp_skb_cb flags and ip_dsfield).



Cheers,
Christoph

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