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

[Christoph Paasch <christoph.paasch@uclouvain.be>]

On 07/05/14 - 16:48:59, David Miller wrote:
> From: Octavian Purdila <octavian.purdila@intel.com>
> Date: Wed, 7 May 2014 10:30:23 +0300
> 
> > On Wed, May 7, 2014 at 8:38 AM, David Miller <davem@davemloft.net> wrote:
> >>
> >> From: Octavian Purdila <octavian.purdila@intel.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