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 <redacted>
Date: Wed, 7 May 2014 10:30:23 +0300

quoted

On Wed, May 7, 2014 at 8:38 AM, David Miller [off-list ref] wrote:

quoted

From: Octavian Purdila <redacted>
Date: Tue,  6 May 2014 21:05:24 +0300

quoted

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